RUN issues (again)

[NewsArchive]

Friedrich

Some time ago we had some conversation regarding my unhappiness with error
reporting re. the Run command.. and deciding whether to use the default
operation, or set to use ShellExecute.

Despite a couple of others advising to use ShellExecute, you were adamant
that you did not normally use it in your installations, and also cited that
it allowed less control over execution.

I was swayed by this, and reverted from my position of using ShelExecute,
back to the default.

Unfortunately this now appears to have been a big mistake - we are now
(tonight) distributing my latest upgrade, and are already getting reports
from several stores regarding Run issues - all with the same result!!!

The attached (faxed in by a helpful store) shows this repeating error - no
idea what the numbers mean (which was the source of my complaint last time)

Seems there is 'something going on' with the default Run call on a number
of computers 'out there' in the shops.

I shall be reverting to the use of ShelExecute, to see if I can salvage some
of these upgrade installations. But my advice to users setting up for major
distributions now is to be suspicious of using the default Run call, and to
use ShellExecute on Running
external programs.

Just my (NS)HO, of course
It looks like we are in for a long night....

HTH
Steve

[NewsArchive]

Steve,

> Some time ago we had some conversation regarding my unhappiness with error
> reporting re.

Because your were unhappy with the error reporting, we changed error
handling for "Run Program" and give you access to the Windows return codes
now.

But you did not mention which build you are using. Make sure you have
#2537.

I also have no idea what your return number means. If %_SB_RETURNEX%
returns 0 (that means GetLastError returned 0) and %_SB_ERRORCODE% returns a
value (and the "Wait" option is enabled) then this value comes from
GetExitCodeProcess - in other words, from the executed application itself.

Hope this helps.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

> But my advice to users setting up for major distributions now is to
> be suspicious of using the default Run call, and to use ShellExecute
> on Running external programs.

Just for the record - we are using ShellExecuteEx only when starting an
elevated application from a non-elevated install. For example, in the new
(non-elevated) wucheck.exe. Even the Web Update Client (wupdate.exe) does
*not* use ShellExecute -- it uses CreateProcess. And wupdate.exe is used on
quite a few million machines. We always use CreateProcess in our own
installations and all Script Writing Consulting projects.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Steve,

Perhaps the following happens. FYI, error code -1073741511 (0xC0000139 in
32bit-hex) means:

---

#define STATUS_ENTRYPOINT_NOT_FOUND ((NTSTATUS)0xC0000139L)

The procedure entry point XX could not be located in the dynamic link
library XX.

---

So perhaps you call an .exe that calls a function in a DLL -- but that
function could not be found in a DLL. That's why your application
returns -1073741511 (IMO).

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Friedrich,

Oh yes, I already know that - found out the hard way, by tracking it down!

But wouldn't it have been nice if the installer TOLD ME that.... (I still
don't believe its 'that hard')
But at bare minimum there should be URL lookup references for error lists
(for example, where did you get that #define from?)

This is what I have asked for and will continue to ask for in SetupBuilder.


However, I must say that in this case I jumped the gun re. CreateProcess -
this was a 'valid' failure, not a machine-fussy one as I suspected.
So I retract that part - and Createprocess survives in the install script

Now, the real cause - for some unknown reason, SB has only installed 1 of
the 3 DLLs it was scripted to install... and thus the dependent child
process did indeed fail on Run.

I have no answer for why this failure has occurred on multiple machines.
All 3 DLLs weer handled in the same way (see attached) but only *1* has been
installed.

When I try to debug here it works 100%.... I'm stumped.

Steve Bywaters

[NewsArchive]

Steve,

> But wouldn't it have been nice if the installer TOLD ME that.... (I still
> don't believe its 'that hard')
> But at bare minimum there should be URL lookup references for error lists
> (for example, where did you get that #define from?)
>
> This is what I have asked for and will continue to ask for in
> SetupBuilder.

WHAT???????? I have to admit that I am really "not amused" (AGAIN).

You tell us about mysterious error codes, that there are problems with the
default SetupBuilder "Run Program..." function, that you'll have a long
night because of an installer malfunction and that it appears to be a big
mistake you followed my advise to use the default Run option (which makes
use of CreateProcess).

Then on top of that, you make an advice to users setting up for "major
distributions" to be suspicious of using the default Run call.

And now it turns out that the mysterious error code was not mysterious at
all and that the very same default "Run Program..." function was smart
enough to provide you with detailed information about a fatal error in
YOUR OWN application. CreateProcess is very powerful and can get the
correct return value for such a scenario.

Please don't ask me again to provide a built-in SetupBuilder function
that converts return values (e.g. -1073741511) issued by YOUR OWN
application into a "human readable" error message. It's simply not
possible. I really hope this issue in your application tells you why
this is so. Or just let me know how to get the error description for
-1073741511 from the operating system. There are hundreds of 0xC0000000L
(and even thousands of other possible error codes). And then all the
return values you can pass back from the .exe to the installer or from
a DLL to the EXE and then to the installer.

You don't want to see -1073741511 again in the future? No problem.
Call the DLLs dynamically instead of statically from your application
and detect the entry point error. Then pass 12345 back to the installer
and display a "Sorry, entry point not found" message box. But then
there are all the other hundreds and thousands possible Windows error
codes (no human readable text available). So it will not really help.
Do you see what I mean????

And I really hope you did not tell all "the shops" that this error was
caused by a goddamned buggy SetupBuilder product, but a bug in your own
software.

Regards,

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

>Please don't ask me again to provide a built-in SetupBuilder function
> that converts return values (e.g. -1073741511) issued by YOUR OWN
> application into a "human readable" error message. It's simply not

Nice spray - but not quite on point:.


1) When I run the Clarion program (that could not run) - it tells me
explicitly that the "entry point could not be located in the dynamic
library..."
Then in a following program (Clarion) I get a "error 47 - Invalid File
Declaration"
These are helpful error messages.... not just error codes!.

*HOWEVER*, in deference to you I already asked that at - a bare minimum
there should be a reference list of URLS of errorcodes to look up all this
myriad of codes that you mention..
I say again - it should not be necesary to do an extensive search to
decode -123456789 (or whatever)



2) The reason the program failed is because SB failed to install a required
DLL!
I'm still looking into this.. but its real, and so far has happened on 6
machines (But not in any of our testing)

> And I really hope you did not tell all "the shops" that this error was
> caused by a goddamned buggy SetupBuilder product, but a bug in your own
> software.

Your logic is faulty - this was not caused by any bug in *my* software.
See 2, above.

(Or.. if I use the same finger-pointing mode that you have: it failed
because the correct DLL was not installed by YOUR program!)

Steve

[NewsArchive]

> 2) The reason the program failed is because SB failed to install a required
> DLL!

Steve,

AFAIK, there is only one circumstance in which SB would "fail to install" a
DLL on some machines vs others.

That would be if the DLL was "in use".

SB can not replace a file that is in use and it would queue the DLL
installation for completion after a reboot.

If your users do not reboot (or try to run the app without a reboot), then
the effect would be as if the DLL was not installed.


Charles



--
-------------------------------------------------------------------------------------------------------
Charles Edmonds
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

> Nice spray - but not quite on point:.
>
>
> 1) When I run the Clarion program (that could not run) - it tells me
> explicitly that the "entry point could not be located in the dynamic
> library..."
> Then in a following program (Clarion) I get a "error 47 - Invalid File
> Declaration"
> These are helpful error messages.... not just error codes!.

Aha, very interesting. You obviously know what you are talking about.

Okay, let's prove it. We use a Clarion application to RUN() a simple
test.exe. This test.exe calls a "SteveIsCool" function located in test.dll.
Unfortunately, the "SteveIsCool" function does not exist in the test.dll
(entry point not found).

So you are telling us that you'll receive a helpful error message from
Clarion now. Right?

No, WRONG! The Clarion ERRORCODE() will return 300 and ERROR() will give
you "Unknown Error Posted: 300"

SetupBuilder gave you STATUS_ENTRYPOINT_NOT_FOUND ((NTSTATUS)0xC0000139L)
which means "The procedure entry point XX could not be located in the
dynamic link library XX."

So what are your thoughts on this?

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

> (Or.. if I use the same finger-pointing mode that you have: it failed
> because the correct DLL was not installed by YOUR program!)

Yeah, of course.

But what about the following scenario. An installer has to replace "locked"
DLLs and a reboot is required in order to finish the installation. But a
smart programmer disabled the reboot procedure and starts a program that
depends on the new DLLs. The problem is, the new DLLs are not there because
Windows has to reboot the system to replace the locked DLL files.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

"Sledging" aside... I have a question re. SB procedure:

Since it seems that errors and failure can occur on (almost) *all* installer
commands, do you consider it good practice to put a test for
%_SB_ERRORCODE% after (almost) all lines?

For example, as I outlined earlier, I have had 2 DLLs failed to install -
would have been nice to know that at the time (assuming that the Store
operators noticed...) - so "should" I put a test for %_SB_ERRORCODE% after
every "Install File..."?

By the time I cover (almost) all installer lines, that will be a LOT of "if
%_SB_ERRORCODE% then".. lines...
Is that what you consider 'Best Practice' for installation?

Steve

[NewsArchive]

> Since it seems that errors and failure can occur on (almost) *all* installer
> commands, do you consider it good practice to put a test for
> %_SB_ERRORCODE% after (almost) all lines?

I never test for it and never have a problem.

I do test to be sure that the program being updated is closed (in a loop)
and will not go forward with the install unless it is closed.

No files in use means no problems with a file not getting replaced (at
least for all my installs).

I've never had a case where a file appeared to not install ... ever.


Charles


--
-------------------------------------------------------------------------------------------------------
Charles Edmonds
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

Because SetupBuilder is an installation system and the main aim of such a
system is to install files, a failed "Install File(s)" action is always
interpreted as a fatal error and the installation will be aborted
immediately!

So there is no need to handle %_SB_ERRORCODE% after a "Install File(s)"
action because such a statement is never executed if the install function
failed. What you can do is to check if a reboot is required before you
execute your programs. "Get System Information (Reboot Status)" or a set
$SB_RESTARTFLAG$ flag in %_SB_INSTALLERFLAG% provide you with this
information.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Uh... let's see... you ask the installer to spawn a process, that the
installer has absolutely no idea what kind of interfaces the process has,
you execute the program within the 'mystery' process and then when you
executable doesn't report the error appropriately, you blame the installer
because it doesn't provide you with the correct error message... What are
you... NUTS?... You might want to build a bit more error checking and
debugging into your own code, before you start poking fingers in Friedrich's
eye... Just try to do your install under the Microsoft installer and see how
far you get... especially with code that comes from a company that has
INFINITELY more resources than does Lindersoft. No, he's not as perfect as
you, but I can guarantee that he's got more than a few more satisfied
customers than you have... What a loser!

--

Ben E. Brady
Want MASSIVELY OUTRAGEOUS web disk space and bandwidth?
500 GB disk space and 5000 GB transfer per month,
http://www.servage.net/?coupon=CUST13495

www.clariondeveloper.com
www.singularvisionsoftware.com

The information contained in the message above, as expressed by the author,
is copyright 2008 by Ben E. Brady, All rights strictly reserved worldwide.
The information contained in the message above may not be posted on any
other information forum or web site without the express written permission
of the author. All opinions expressed in the message are those of the author
and are not necessarily shared by other members of the newsgroup and may or
may not be in agreement with SoftVelocity, the host of this newsgroup.

[NewsArchive]

Since you've never met me and know absolutely nothing about me or my
circumstances (unlike you, who persists in spreading the minutiae of his
personal life onto the NG...) - I suggest you keep the personal comments
to yourself.

Steve Bywaters

[NewsArchive]

(last post on this.. honest!)

You ask
> So what are your thoughts on this?

Ok , in the end then.. my simplest option/request was this:
"at bare minimum
there should be a reference list of URLS of errorcodes to look up all this
myriad of codes that you mention..
I say again - it should not be necesary to do an extensive search to
decode -123456789 (or whatever)"

I'm done.

Steve Bywaters

[NewsArchive]

> (last post on this.. honest!)
>
> You ask
>> So what are your thoughts on this?
>
> Ok , in the end then.. my simplest option/request was this:
> "at bare minimum there should be a reference list of URLS of
> errorcodes to look up all this myriad of codes that you mention..
> I say again - it should not be necesary to do an extensive search to
> decode -123456789 (or whatever)"
>
> I'm done.

No problem. Just provide me with a link on the Microsoft MSDN site that
lists error codes and explicitly includes "-1073741511". I'll then
immediately add that link to the SetupBuilder documentation.

You had a problem and I invested a not insignificant amount of time to find
out (for you) what -1073741511 is. In the end, I had an idea and converted
"-1073741511" to a 32-bit hex (0xC0000139). After some more investigation,
I found out that it is STATUS_ENTRYPOINT_NOT_FOUND (defined in the Visual
Studio "ntstatus.h" header file).

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

> Nice spray - but not quite on point:.
>
>
> 1) When I run the Clarion program (that could not run) - it tells me
> explicitly that the "entry point could not be located in the dynamic
> library..."
> Then in a following program (Clarion) I get a "error 47 - Invalid File
> Declaration"
> These are helpful error messages.... not just error codes!.
>
> *HOWEVER*, in deference to you I already asked that at - a bare minimum
> there should be a reference list of URLS of errorcodes to look up all this
> myriad of codes that you mention..
> I say again - it should not be necesary to do an extensive search to
> decode -123456789 (or whatever)

I have uploaded small Clarion and SetupBuilder test applications for you:

http://www.lindersoft.com/projects/EntryPointDemo.zip

Unzip the above ZIP into a temporary folder.

Execute "clarion.exe" (developed with Clarion). This will RUN the
"test.exe" Clarion application which calls a non-existing "testme" function
in "test.dll". The Clarion ERRORCODE() will return 300 and ERROR() will
give you "Unknown Error Posted: 300"

Execute "setupbuilder.exe" (developed with SetupBuilder). This will RUN the
"test.exe" Clarion application which calls a non-existing "testme" function
in "test.dll". SetupBuilder will give you the correct -1073741511
(0xC0000139 in 32bit-hex) -> STATUS_ENTRYPOINT_NOT_FOUND ->
((NTSTATUS)0xC0000139L)

If you execute "test.exe" directly, Windows (and not the application
itself!) will display the "The procedure entry point testme could not be
located in the dynamic link library test.dll." error message.

Hope this helps.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

It now seems that *another* program (sharing a DLL) was still running....
It was definitely not the target program being upgraded - so testing if that
was still running would have been pointless.

> What you can do is to check if a reboot is required before you execute
> your programs. "Get System Information (Reboot Status)" or a set
> $SB_RESTARTFLAG$ flag in %_SB_INSTALLERFLAG% provide you with this
> information.

How does this work?
How does it work out how when to set the flag (the help does not give any
info, but lets not go there again)
Does it check the EXEs and all/Dlls to be installed?
Would it have helped in this case, where *another* program (sharing a DLL)
was running?
Any particular position in the script for this command?



STATEMENT OF CONTRITION:
Having got to this point, I must now say that SB IS BLAMELESS FOR ANY OF
THIS DLL STUFF!

I apologise for going over the top the other night... it was 'dramatic'
here, but I should nevertheless have taken a breath before I posted.


Steve

[NewsArchive]

Steve,

How on earth do you expect ANY program to be able to check if all dll's linked in an exe are in use if you only give the exe name ?

Back to earth : you need to check an exe and all dll's are not in use ? add them all to your script
and wether your exe or another one uses any dll then only will you be safe

SB is an excellent tool but it is upto *us* to get it to perform what *we* need

I found all I needed in help and in pdf's but also looking at demos ..generally you can learn faster from demos then from docs (for such pbs at least)

Put it _of course_ BEFORE installing the files - logical Doctor Watson no ? ;)

Cordialement - Best regards
Jean-Pierre GUTSATZ

CGF

DMC - Data Management Center
A tool to let you Migrate Import Export Transfer your Data
www.dmc-fr.com
Certified by Microsoft : "Works with Vista" &
"Works with Windows Server 2008"

[NewsArchive]

Hi Steve,

>> What you can do is to check if a reboot is required before you execute
>> your programs. "Get System Information (Reboot Status)" or a set
>> $SB_RESTARTFLAG$ flag in %_SB_INSTALLERFLAG% provide you with this
>> information.
>
> How does this work?
> How does it work out how when to set the flag (the help does not give any
> info, but lets not go there again)
> Does it check the EXEs and all/Dlls to be installed?
> Would it have helped in this case, where *another* program (sharing a DLL)
> was running?
> Any particular position in the script for this command?

Like Friedrich said you should do that before you start your program. If a
reboot is required the install should reboot the system. Otherwise the
install is NOT complete as it cannot overwrite files that are in use. Yes
it should definitely have helped since the dll was not installed properly
because it was in use. My guess is that in those cases the files that fail
to install are put into temporary storage, a RunOnce stub is added to finish
the install and it runs immediately after the reboot.

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

At least you were man enough to apologize... Good for you. Apology accepted.

--

Ben E. Brady
Want MASSIVELY OUTRAGEOUS web disk space and bandwidth?
500 GB disk space and 5000 GB transfer per month,
http://www.servage.net/?coupon=CUST13495

www.clariondeveloper.com
www.singularvisionsoftware.com

The information contained in the message above, as expressed by the author,
is copyright 2008 by Ben E. Brady, All rights strictly reserved worldwide.
The information contained in the message above may not be posted on any
other information forum or web site without the express written permission
of the author. All opinions expressed in the message are those of the author
and are not necessarily shared by other members of the newsgroup and may or
may not be in agreement with SoftVelocity, the host of this newsgroup.

[NewsArchive]

>> What you can do is to check if a reboot is required before you execute
>> your programs. "Get System Information (Reboot Status)" or a set
>> $SB_RESTARTFLAG$ flag in %_SB_INSTALLERFLAG% provide you with this
>> information.
>
> How does this work?
> How does it work out how when to set the flag (the help does not give any
> info, but lets not go there again)
> Does it check the EXEs and all/Dlls to be installed?
> Would it have helped in this case, where *another* program (sharing a DLL)
> was running?
> Any particular position in the script for this command?

See attached documentation screenshot on how to retrieve specific
information from %_SB_INSTALLERFLAG%.

To replace a "locked" file, a Windows reboot is required in order to finish
the installation. If the installer detected a locked file, it asks for a
reboot at the end of the installation process.

You can check the $SB_RESTARTFLAG$ flag in %_SB_INSTALLERFLAG% to see if a
reboot (for this specific installation) is pending.

So what you can do is to detect a pending reboot before you execute
applications from your installer. If this is the case, do a "Reboot and
Resume" from the installer, let the system reboot and automatically restart
the installer, then skip what has already been processed (before the reboot)
and continue with the install (e.g. execute the application(s)).

And of course, you can use the "Check In-use File" or "Check In-use Folder
Tree" functions before the main installation process starts to make sure all
files can be written/replaced.

HTH,

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Steve,

> For example, as I outlined earlier, I have had 2 DLLs failed to install -
> would have been nice to know that at the time (assuming that the Store
> operators noticed...) - so "should" I put a test for %_SB_ERRORCODE% after
> every "Install File..."?
>
> By the time I cover (almost) all installer lines, that will be a LOT of "if
> %_SB_ERRORCODE% then".. lines...
> Is that what you consider 'Best Practice' for installation?

It really depends. In this case you should IMO test if the program is
running and if it is throw a message indicating that it is and tell the
operator to shut it down. I would not allow a critical install failing
because the program it is updating is running, so I would check for it and
make the install FAIL with a message if the process is running.

Critical operations should be checked for errors, just like in any other
cirtical situation where it can make or break the operation if errors occur.

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

I still stand behind my comments... Fix your lousy code instead of blaming
someone else for your errors.

--

Ben E. Brady
Want MASSIVELY OUTRAGEOUS web disk space and bandwidth?
500 GB disk space and 5000 GB transfer per month,
http://www.servage.net/?coupon=CUST13495

www.clariondeveloper.com
www.singularvisionsoftware.com

The information contained in the message above, as expressed by the author,
is copyright 2008 by Ben E. Brady, All rights strictly reserved worldwide.
The information contained in the message above may not be posted on any
other information forum or web site without the express written permission
of the author. All opinions expressed in the message are those of the author
and are not necessarily shared by other members of the newsgroup and may or
may not be in agreement with SoftVelocity, the host of this newsgroup.

[NewsArchive]

Hi Friedrich,

> out (for you) what -1073741511 is. In the end, I had an idea and converted
> "-1073741511" to a 32-bit hex (0xC0000139). After some more investigation,
> I found out that it is STATUS_ENTRYPOINT_NOT_FOUND (defined in the Visual
> Studio "ntstatus.h" header file).

One thing about the MS headers is that SOME #defines are in hex, some are in
decimal and I think some are in binary and even oct. So digging up those
error codes is no easy task even if you have a good idea where to start<g>

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

>> out (for you) what -1073741511 is. In the end, I had an idea and
>> converted "-1073741511" to a 32-bit hex (0xC0000139). After some
>> more investigation, I found out that it is STATUS_ENTRYPOINT_NOT_FOUND
>> (defined in the Visual Studio "ntstatus.h" header file).
>
> One thing about the MS headers is that SOME #defines are in hex, some
> are in decimal and I think some are in binary and even oct. So digging
> up those error codes is no easy task even if you have a good idea where
> to start<g>

<G> Yes, absolutely. I already have a nice list of "converted" error
codes -- but this "-1073741511" was new to me. Well, you never stop
learning :)

Friedrich

[NewsArchive]

Please feel free *not* to respond to any post of mine, present or future.

Regarding your current abusive, ignorant, unsolicited, unhelpful and
inaccurate comments.. as they say in the UK: 'Foxtrot Oscar'

Steve Bywaters

[NewsArchive]

Yeah.. your code is F%%#Ked and you say I'm making 'inaccurate" comments...
Right...

--

Ben E. Brady
Want MASSIVELY OUTRAGEOUS web disk space and bandwidth?
500 GB disk space and 5000 GB transfer per month,
http://www.servage.net/?coupon=CUST13495

www.clariondeveloper.com
www.singularvisionsoftware.com

The information contained in the message above, as expressed by the author,
is copyright 2008 by Ben E. Brady, All rights strictly reserved worldwide.
The information contained in the message above may not be posted on any
other information forum or web site without the express written permission
of the author. All opinions expressed in the message are those of the author
and are not necessarily shared by other members of the newsgroup and may or
may not be in agreement with SoftVelocity, the host of this newsgroup.