Startup crash in pocrt.dll, version 4.00.43

[Wim Couwenberg]

I'm a new user of PellesC and I must say it looks quite impressive!  Nice job!  Now on to my bug report...

I built a command line exe and a dll that both link to the dynamic runtime pocrt.dll.  Everything compiles and links without problems.  When I start the app, I get an exception in pocrt.dll.  Call stack:

untitled: 00007004
KERNEL32.dll: CloseHandle() + 935
pocrt.dll: __wconcmdln() + 60
pocrt.dll: _wutime() + 740

When linked to the static runtime lib, everything is OK.  The same project runs without problems in the official PellesC release.

Are there some changes in this beta that I should be aware of?

thanks,
Wim

[Pelle]

I'm a new user of PellesC and I must say it looks quite impressive!  Nice job!

Thank you - and welcome!

I built a command line exe and a dll that both link to the dynamic runtime pocrt.dll.  Everything compiles and links without problems.  When I start the app, I get an exception in pocrt.dll.  Call stack:

untitled: 00007004
KERNEL32.dll: CloseHandle() + 935
pocrt.dll: __wconcmdln() + 60
pocrt.dll: _wutime() + 740

When linked to the static runtime lib, everything is OK.  The same project runs without problems in the official PellesC release.

Are there some changes in this beta that I should be aware of?

I have added more Unicode support in v4.0, including new entry-points for wmain() and wWinMain(). There is one change in the startup code for POCRT: I now also initialize a Unicode environment, in case the client will need that later. The stack trace points to this new function.

The strange thing is that it seems to work here (and I can't see anything really wrong with the code). At least I know where to look - will try to fix it to the next Beta version...

Pelle

[Wim Couwenberg]

The strange thing is that it seems to work here (and I can't see anything really wrong with the code). At least I know where to look - will try to fix it to the next Beta version...

For your information: I ran this on a Win98 machine (yes, this is still my development environment, why do you think I need a simple C compiler?)  

Thanks!
Wim

[Pelle]

Thanks for the info - I guessed that.

A better check of the return value from GetEnvironmentStringsW() is a very good idea in this case... ;-)

Pelle

[Wim Couwenberg]

A better check of the return value from GetEnvironmentStringsW() is a very good idea in this case... ;-)

Yep, that's the offending call alright.  I disabled it for the moment (that's what hex editors are for no?) and now my app starts!  I'll wait for the next beta. Are there more Win98 surprises do you think?

Thanks,
Wim

[Pelle]

Yep, that's the offending call alright.  I disabled it for the moment (that's what hex editors are for no?) and now my app starts!  I'll wait for the next beta. Are there more Win98 surprises do you think?

Probably not. It has worked OK on Windows 98 before, and should still do. Development is on Windows XP, but I try to test on other Windows versions too (but this will of course never be as extensive).

This became a problem because I basically copied the Ansi version, changing A to W and char to wchar_t. Older documentation don't mention the possibility of a NULL pointer return from GetEnvironmentStringsA(), so I assumed it always returned something (possibly an empty string). I have now added a NULL-pointer check for both variations (Ansi and Unicode) - just in case.

Pelle