Hello,

I've a problem regarding CriticalSections.
It ends in a BlueScreen. :-(

The following behaviour seems to be incorrect:

After calling InitializeCriticalSection(&cs) cs.LockCount is 0x81742f10.
I expected cs.LockCount = 0xffffffff. That's the behaviour with WindowsXP

Are there any known problems within Windows 98 regarding CS?

I hope, someone can help me.


best regards,
Joerg

On Tue, 16 Dec 2003 08:50:11 +0100, Joerg Wienand
<joerg.wienand@gmx.de> wrote:

Have you read Jeffrey Richter's excellent book "Programming
Applications for Windows"? Well, according to him, it seems that the
CRITICAL_SECTION structure is undocumented ... and you shouldn't be
using any of the members directly.

There are big differences between any of the Windows 9x operating
systems and Windows NT/2000/XP. A lot of the Windows header files have
#ifdef guards to prevent calling certain API functions on operating
systems which aren't capable of handling them.

Play by the rules, and you won't get hurt.


--
Bob Hairgrove
NoSpamPlease@Home.com

Bob Hairgrove wrote:

I'm only wondering about the value. But i'm not using it.

After using EnterCriticalSection and LeaveCriticalSection several times, it
ends up in a bluescreen. :-(

In message <3fdf76d8.5013669@news.webshuttle.ch>, Bob Hairgrove
<wouldnt_you_like@to_know.com> writes
The problem that I have this simplistic approach is that some of us have
to develop for the various versions of 32-bit Windows and it would be a
pain, to say the least, if multiple versions of the executables had to
be generated. It would be even more intolerable if those executables
had to be generated on the OS they were being built for.

--
Fenster

Are you using SEH to make sure LeaveCriticalSection is called ?
Are you sure you're calling InitializeCriticalSection only once in the
program ?

Regards,
Marco Era
http://www.marcoera.com

Marco Era schrieb:

Waht do you mean with "SEH"?

Yes.

In the meantime I solved the problem (or let's say I tried it another way).
I'm using CreateSemaphoer for know.

On Wed, 17 Dec 2003 08:18:10 +0000 (UTC), Fenster
<fenster@croctec.co.uk> wrote:

Well, we all do, don't we?

It is a pain. But if you have to have just one executable which runs
on any Windows platform, then unfortunately you are stuck with the
lowest common denominator, which in this case is Windows 9x. Target
that machine instead of anything else, and you will be OK.

There are *lots* of things that work differently on Win9x than on
Win2k, etc. Look at the Win32 API functions for reading and writing
strings to the registry, for example. The only way to do that
correctly is to write two versions of code, one for 9x and another for
NT/2000/XP and query the OS at run time so you can decide which to
call.

Then there's Unicode, too ... which Windows 9x also supports only
minimally, if at all ... but I think you get the idea.


--
Bob Hairgrove
NoSpamPlease@Home.com

"Bob Hairgrove" <wouldnt_you_like@to_know.com> wrote in message
news:3fe0bc92.2625615@news.webshuttle.ch...
How so? The core registry functions work the same way on Win9x and NT. NT
and Win9x each introduce some extra factors (e.g. writing to
HKEY_LOCAL_MACHINE as a user on NT) but they don't force you to write two
sets of code just to read and write strings.

--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/

On Wed, 17 Dec 2003 20:41:12 -0000, "Tim Robinson"
<tim.at.gaat.freeserve.co.uk@invalid.com> wrote:

I know it is so because I got bitten by this once. I wish it weren't
so, and I didn't believe it when I found out, but I wouldn't be
writing this now if it hadn't happened.

There is a difference in that the reported length of the string
returned in the buffer is different: namely, Windows 95 adds 1 to
include the NULL byte, and NT 4 (or perhaps it didn't show up until
Win2k) doesn't. This subtle difference isn't documented in the version
of MSDN which came with Visual Studio 6 SP3, but it is in more recent
versions.

Also, when you write a string with a terminating NULL byte to a
registry value on Windows NT, it will store the entire buffer length
(and possibly even corrupt the registry) by storing the embedded NULL
byte. Windows 95 doesn't care and will only store the string prior to
the NULL byte.

I only have the older version of MSDN here at home, and I'm out of the
office until the week after Christmas, but maybe I can find this
online.


--
Bob Hairgrove
NoSpamPlease@Home.com

At least now I know that I'm not alone:

http://tinyurl.com/2sd8d


--
Bob Hairgrove
NoSpamPlease@Home.com

Wow, that is pretty bad! I'll have to go back and review some of my own
code, then! What I do know is that NT does not allow for a recursive delete
of registry keys, while 9x does. This is clearly documented, by the way,
and is easily solved by writing your own recursive delete function.

--
//.artijn
http://www.sereneconcepts.nl

__try
{
EnterCriticalSection(&cs);
// Access here your shared resource
// ...
}
__finally
{
// Make sure the critical section gets released.
LeaveCriticalSection(&cs);
}

Regards,
Marco Era
http://www.marcoera.com

On Wed, 17 Dec 2003 22:46:59 GMT, wouldnt_you_like@to_know.com (Bob
Hairgrove) wrote:

After some looking around, I have come to the conclusion that the
"documentation" for this "feature" was removed sometime after July
2000 (where it is still mentioned).


--
Bob Hairgrove
NoSpamPlease@Home.com

It is the caller's responsibility to include the NULL byte in the
count when writing the value into the registry. If the caller
forgets to include the NULL byte (passing strlen() instead of
strlen()+1), Windows 95 will "fix" the bug and add 1 for you. NT
doesn't try to fix the buggy app. If the app writes a non-null
terminated string into the registry, then that's what gets read
back.

On Wed, 17 Dec 2003 22:00:38 GMT, wouldnt_you_like@to_know.com
(Bob Hairgrove) wrote:

By the way, this behavior (missing trailing null if string was
written incorrectly to registry) is documented.

http://msdn.microsoft.com/library/de...eryvalueex.asp

"If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type,
the string may not have been stored with the proper
null-terminating characters. Applications should ensure that the
string is properly terminated before using it, otherwise, the
application may fail by overwriting a buffer."

On Sat, 20 Dec 2003 01:56:18 GMT, Raymond Chen
<http://guest@blogs.gotdotnet.com/raymondc/> wrote:

On Sat, 20 Dec 2003 01:57:29 GMT, Raymond Chen
<http://guest@blogs.gotdotnet.com/raymondc/> wrote:

Yes, but the problem is that when *reading* a string from the
registry, the length is reported differently on Win9x than on NT/2000
(don't know about XP).

The MSDN of July 2000 was pretty clear about this difference, although
I didn't see it until I had been bitten. Unfortunately, I don't have
access to this MSDN right now.


--
Bob Hairgrove
NoSpamPlease@Home.com

Right. If the data was written incorrectly, NT/2000 reports the
length as originally written. I.e., it preserves the incorrect
value. Win9x secretly tries to fix incorrect values.


On Sat, 20 Dec 2003 09:53:53 GMT, wouldnt_you_like@to_know.com
(Bob Hairgrove) wrote: