X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f Message-ID: <0BA32251E589D2118EA60008C70DDCAB025F9192@JNJFRISEXS1.eu.jnj.com> From: "Baribaud, Christophe [JNJFR]" To: "'florian DOT proff DOT schulze AT gmx DOT net'" Cc: "'djgpp AT delorie DOT com'" Subject: TR: LWP and Windows 2000 Date: Thu, 31 Jan 2002 15:27:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AA63.7B8718A0" Reply-To: djgpp AT delorie DOT com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AA63.7B8718A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Message d'origine----- > De : Baribaud, Christophe [JNJFR] =20 > Envoy=E9 : jeudi 31 janvier 2002 14:45 > =C0 : 'florian DOT proff DOT schulze AT gmx DOT net' > Cc : 'djgpp AT delorie DOT com' > Objet : LWP and Windows 2000 >=20 > Hi >=20 > I have just done tests and tried patches to LWP, and I have an idea = why it > doesn't work under Windows 2000. > LWP and Windows are both multi-threading preemptive environments, and = they > do preempt each other mutually. > When LWP preempts Windows, it "unlocks" the stack locked by Windows = into > LWP exe space. If LWP threads turn faster than Windows threads (less = time > between two time slices of the same thread) LWP can wake up the = thread > which was running when Windows preempted the CMD.EXE thread owning = LWP. In > this situation, LWP thread erases the part of its stack containing = Windows > thread context. When Windows preempts LWP to restore this context, it > jumps to chaos, causing LWP process to terminate. >=20 > I am not sure that this explanation is clear, nor true ... but when I = do > not use LWP preemptive multitasking (by not setting irq8 handler) it = works > fine under Windows. > With preemptive multi-threading, errors occur generally during = floating > point operations. I do think that it is because FPU environment is = the > biggest part of context saved into stack. So, when stack contents are > altered, the greatest probability is to alter FPU environment... >=20 > My idea is that LWP should verify that it is inside its Windows = thread > time slice before preempting. One way could be to verify the stack > selector value of the interrupted thread (which should be equal to = djgpp > ds). I haven't succeeded in retreiving this selector ;-( > Another way could be to verify Windows CurrentThreadID, but it is = ugly as > it needs a connection with kernel32.dll ... > Another way is to use Windows NT DPMI extensions (does anyone have = any > information about it ?) >=20 > No other idea ... >=20 >=20 > Regards > CB >=20 > P.S. > I had to repost this message, because it contained so-called = offensive > language. So I replaced (censored) by chaos. > Delorie gateway seem to be not permissive at all ! > For DJ : sorry for my offensive american, I am french !!! ------_=_NextPart_001_01C1AA63.7B8718A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TR: LWP and Windows 2000

 -----Message d'origine-----
De=A0:    = Baribaud, Christophe [JNJFR]  =
Envoy=E9=A0:        jeudi 31 janvier 2002 = 14:45
=C0=A0:     'florian DOT proff DOT schulze AT gmx DOT net'
Cc=A0:    'djgpp AT delorie DOT com'
Objet=A0: LWP and Windows 2000

Hi

I have just done tests and tried = patches to LWP, and I have an idea why it doesn't work under Windows = 2000.
LWP and Windows are both = multi-threading preemptive environments, and they do preempt each other = mutually.
When LWP preempts Windows, it = "unlocks" the stack locked by Windows into LWP exe space. If = LWP threads turn faster than Windows threads (less time between two = time slices of the same thread) LWP can wake up the thread which was = running when Windows preempted the CMD.EXE thread owning LWP. In this = situation, LWP thread erases the part of its stack containing Windows = thread context. When Windows preempts LWP to restore this context, it = jumps to chaos, causing LWP process to terminate.

I am not sure that this explanation is = clear, nor true ... but when I do not use LWP preemptive multitasking = (by not setting irq8 handler) it works fine under Windows.

With preemptive multi-threading, = errors occur generally during floating point operations. I do think = that it is because FPU environment is the biggest part of context saved = into stack. So, when stack contents are altered, the greatest = probability is to alter FPU environment...

My idea is that LWP should verify that = it is inside its Windows thread time slice before preempting. One way = could be to verify the stack selector value of the interrupted thread = (which should be equal to djgpp ds). I haven't succeeded in retreiving = this selector ;-(

Another way could be to verify Windows = CurrentThreadID, but it is ugly as it needs a connection with = kernel32.dll ...
Another way is to use Windows NT DPMI = extensions (does anyone have any information about it ?)

No other idea ...


Regards
CB

P.S.
I had to repost this message, because = it contained so-called offensive language. So I replaced (censored) by = chaos.
Delorie gateway seem to be not = permissive at all !
For DJ : sorry for my offensive = american, I am french !!!

------_=_NextPart_001_01C1AA63.7B8718A0--