Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Eli Zaretskii , djgpp-workers AT delorie DOT com, Morten Welinder Date: Thu, 11 Jun 1998 14:55:06 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: __dpmi_yield considered harmful (sometimes) References: In-reply-to: Precedence: bulk Eli Zaretskii wrote: > On Tue, 9 Jun 1998, Salvador Eduardo Tropea (SET) wrote: > > > Machine without problems (clean installation): vmm32.vxd 697318 bytes > > 1998-06-04, 12:02 > > Machine with more software installed: vmm32.vxd 710034 1998-05-19 12:21 > > Yes, I also see widely different VxDs. Probably, optional packages come > with their private versions of vmm32.vxd. One particularly nasty fella > I'd suspect is MSIE v4 (did you maybe installed one on the problematic > machine?). Nope. But I think it could be Office or DirectX, I'll try to see if I can find a vmm32.vxd in one of these packages. > > But wait ... that isn't even the original!!! in the .cabs the file is 411132 > > bytes long. > > That's the compressed size, I'd guess. No, that's the size after extracting the file from the cabinet file! I taked a look to the file using abinary editor and isn't compressed. Is very different to the one installed in both systems. It includes a lot of debug messages to show register dumps and similar things. Now I taked a look to a third system, it have: vmm32.vxd 710114 bytes, time 12:22 and it pass the test so looking at the time of creation of the file my conclution is: In the cabinet files the vmm32.vxd have time 11:11 so that's the real vmm32 for W95 v4.00.1111 it have 411Kb. The others are: 697318 time 12:02 => from v4.00.1202 710034 time 12:21 => from v4.00.1221 * 710114 time 12:22 => from v4.00.1222 (*) fails So looks like some applications are distributing an updated version of vmm32.vxd. After all that seems to be part of the kernel, so they distribute upgrades of the OS!! I'll try to use the 1222 in the machine with 1221 and see if it fixes the problem. > > Looks that the problem could be there, but is hard to know how or why the files > > are so different. > > It actuallu turns out that not only function 1680h, but ALL functions of > Int 2Fh wedge the DOS box when invoked from nested DPMI clients, if they > are called via INT 2Fh instruction. __dpmi_int works okay. > > I searched the entire libc.a, but fortunately only __dpmi_yield calls > Int 2Fh. > > It *is* something to avoid, though. For example, Emacs called another > function of 2Fh and it hung for me on that machine while building (where > it is run from Make). > > Seems like the Int 2Fh handler on Windows 95 is badly broken. Or perhaps was broken from 12xx(>1202) to 1221 and that's why only few people experiment problems. SET ------------------------------------ 0 -------------------------------- Visit my home page: http://set-soft.home.ml.org/ or http://www.geocities.com/SiliconValley/Vista/6552/ Salvador Eduardo Tropea (SET). (Electronics Engineer) Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org ICQ: 2951574 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA TE: +(541) 759 0013