dencorso

Thanks, JorgeA. You rock!

I can confirm that. And I've also added the .NET 4.0 mentioned on post #561.

You mean... behaving like rampant malware?

AFAIK, the TrustedInstaller can do anything, isn't it?

That's a nice idea! And since it's not quite time-critical, it might, say, check just once every full hour, which would make its impact really negligible...

Well, for what it's worth, I've checked and all versions of diskcopy.dll, from XP up to 7 including the 32-bit one from the WOW64 folder of 7 ultimate SP1 yield the exact same floppy image when extracted with Nuno Brito's DISKEXTRACT. That image is a modified version of the original Win ME ebd floppy, and can only behave exactly like it, in all relevant aspects.

Nowadays, with current BIOSes etc. using part of the UMA for USB native support and another part of the UMA for SATA native support, there's hardly any UMB memory to be recovered. So, it's difficult to justify using EMM386.EXE. If not using it, the handles problem does not happen, and a (real or virtual) floppy or pendrive booting solely with IO.SYS, COMMAND.COM, HIMEM.SYS, SMARTDRV.EXE and a dummy MSDOS.SYS should work great, but adding a CONFIG.SYS to load both HIMEM and SMARTDRV (as a INSTALL= line) is quite handy, and can accomodate CD/DVD drivers, too, if needed. I'll justify this later, but the best choice for those files is using those that come with Win 98SE, not those from ME, and in all cases, replacing IO.SYS by the one from KB311561 (use the EBD version for ME). The attached image is a screen capture in plain DOS 7.1 (without EMM386), acquired with the good old Screen Thief for DOS v2.04, of the map of the upper memory area of my P8Z68-V LX motherboard, generated by the good old UMASCAN, by Jeff Prosise. As you all can see, there's just 64 kiB available for the creation of a UMB...

True. But neither display the contents of the Properties => Version Tab, like VxDProps.

The ebd floppy from ME is essentially equivalent to that from 98FE/SE. But Win ME has actually 3 different HIMEM.SYS! One for the EBD, which is actually the same as that from 98FE/SE, one with just about the same code, but recognizing less command-line switches and without most of the error messages and one even slimmer actually embedded in IO.SYS!!! I'll get back to the ME IO.SYS question latter, and give you a fuller answer. Please bear with me. There are actually 3 scenarios: 1.) One boots with no valid MSDOS.SYS: then config.sys is needed to load himem.sys, but smartdrv can be run with the default number of handles, unless one also loads emm386; 2.) One boots with a valid MSDOS.SYS: then config.sys is not needed to load himem.sys (because it'll be loaded by default), but smartdrv can be run with the default number of handles, unless one also loads emm386; 3.) One insists in using emm386, which is not required nor useful for smartdrv. Then config.sys is needed to load himem.sys, regardless of whether a valid MSDOS.SYS exists, because the use of emm386 causes the need for more handles, somewhere between 2.5 and 3 GiB. So, my one-liner tried to cover all the cases, unless it was totally ignored, which was what actually happened.

When talking about this, the classic Google study remains a cornerstone reference, despite having aged somewhat: Failure Trends in a Large Disk Drive Population.

This was not a rhetorical question... do any of y'all remember a scene featuring a self-filling empty glass in one of the Matrix movies, and can perhaps tell me in which of them does it appear, or whether I've just dreamt it?

The OP asked "how do I make it work?" and I replied objectively to the question asked... But right now I have some time, so I'll give you some version history data: All the files below support INT 2FH, AX=4309H (GET XMS HANDLE TABLE) and dw ES:[BX+2]=DEFHANDLES=============================================================================HIMEM: DOS XMS Driver, Version 3.09 - 02/23/93 14208 kiB 24E2H = 20H DOS 6.00HIMEM: DOS XMS Driver, Version 3.10 - 07/21/93 29040 kiB 5ED2H = 20H DOS 7.00 BetaHIMEM: DOS XMS Driver, Version 3.10 - 09/30/93 29136 kiB 5F32H = 20H DOS 6.2x; WfW 3.11HIMEM: DOS XMS Driver, Version 3.xx - 06/10/94 32631 kiB 6752H = 20H Chicago Beta 122=============================================================================The pair of files below are binarily identical:HIMEM: DOS XMS Driver, Version 3.95 - 06/21/95 32935 kiB 6892H = 30H Chicago Beta 501HIMEM: DOS XMS Driver, Version 3.95 - 07/11/95 32935 kiB 6892H = 30H Win 95=============================================================================HIMEM: DOS XMS Driver, Version 3.95 - 10/02/95 33127 kiB 6952H = 30H Q137755HIMEM: DOS XMS Driver, Version 3.95 - 08/24/96 33191 kiB 6992H = 30H Win 95 OSR2.0=============================================================================The three files below are binarily identical:HIMEM: DOS XMS Driver, Version 3.95 - 05/11/98 33191 kiB 6992H = 30H Win 98 FEHIMEM: DOS XMS Driver, Version 3.95 - 04/23/99 33191 kiB 6992H = 30H Win 98 SEHIMEM: DOS XMS Driver, Version 3.95 - 06/08/00 33191 kiB 6992H = 30H Win ME (ebd)=============================================================================HIMEM: DOS XMS Driver, Version 3.95 - 06/08/00 32711 kiB 6992H = 30H Win ME (windir)=============================================================================The numbers to the right of the date are file size, the offset of DEFHANDLES (the default number of handles) and the value MS put there. If you seach the rather scarce MS documentation about it you'll find it stated that DEFHANDLES = 20H (= 32 decimal), and that statement is repeated even here, where it's no longer true, because MS noticed 32 handles might not be enough anymore and updated silently DEFHANDLES to 30H (=48 decimal) during the development of Win 95 (or DOS 7.0), and that's the value that remained as the default till Win ME, inclusive. So, while I do agree with almost everything RLoew said in post #17, I must disagree with the value he gave for DEFHANDLES. It's, in fact, 48, not 40. And 48*64 MiB = 3072 MiB or, in other words, the issue starts just short of 3 GiB. Of course, one can set a value for /NUMHANDLES in the command-line or get an hexeditor and patch the address I provided above. Both solutions work. Remember, however, if deciding to patch, that 64 is 40H, and, yes, it should be enough.

Download this. Then run it, with the /wuforce command-line switch. Then reboot and try again accessing the WU site.

Well, not quite...

Himem is probably running out of handles.

Supose one double-boots 9x/ME with XP or 7 or both. There's no way to find out version, language and all those familiar info from the Properties => Version tab for .VxDs, because NT-OSes don't know anything about .VxD (aka .386 or .PDR) files. NT-OSes don't read their version info structure because they don't even suspect it's there. So, in order to be able to check that info, to update or replace such files in 9x/ME, from NT-OSes, a special app is needed, and the only know such apps are those in this thread. My original one also runs in DOS, but shows just version info. The new one provides all the info from the Properties => Version tab, but can only run in a DOS box, because it's a Win32 console application. To see the new one work, a VxD file is needed. Having one such file at hand, the usage is: VxdProps <filename>. Cheers!

It's been a long time already, since I've released VxDVer... I always wished to make it more complete, but never actually found the time to come around to it. Quite recently, I've found out an ancient MSKB document (viz. Q201685 aka KB201685), which provides sample code precisely for reading more fully the properties of a VxD file (usualy having the extensions .386, .VxD or .PDR). I compiled it, and it works, although it has a bug, which was first reported by Jordan Russell: So, I decided to fix this bug, cause the program to give error messages and localization languages in plain English, not just as a code number, format a little better the program's output, and make available a compiled copy of it. As opposed to my VxDVer, this new program named VxDProps is not a plain DOS executable, but instead a Win 32 console applications, that should run equally well on 9x/ME and on NT-family OSes, at least from 2k on. It's compiled with VC++ 6.0. Problems, bugs, etc., please do let me know. The original version has been replaced by a new one, now available for download from Post #20.

Try using /NUMHANDLES=80 option for himem.sys and rem out the emm386.exe. That ought to get your machine booting. Afterwards you may find a way to put emm386.exe back.

Tinfoil is so last millennium... the thing now is Velostat!

Yes. If one gives 100% the ontologic meaning of "all", then it's impossible, it would require underflow, an impossible phenomenon in our physical reality (imagine one buys a banana hand having 6 bananas, then plucks and eats, say, 7 bananas out of it: that's underflow). But in the word of computing, buffers may underflow, all right! And that may cause very real security issues, BTW. So, by letting ontology aside, for a moment, and looking at it just from a mathematical point-of-view, 3000% is a somewhat euphemistic way of saying "30"... Then again, if the idea is to obfuscate, I, for one, would rather prefer to say "half again a score"! In any case, to cut the chicken head count by 3000% would require a helluva overkill !!! BTW, I seem to remember vaguely a scene featuring an underflowing drinking-glass in one of the Matrix movies... Is there really one such scene or have I just dreamt it?

Here's the full article (or sales piece).

http://download.microsoft.com/download/0/A/5/0A57F593-57B7-4B8B-8598-A3EBEAC3620D/NDP20SP2-KB2894843-x86.exehttp://download.microsoft.com/download/C/2/C/C2CBA674-3E4B-4BF0-9B75-6239E994C356/NDP20SP2-KB2972105-x86.exehttp://download.microsoft.com/download/F/1/4/F14595A2-A761-4368-9537-CB1347A5C31D/NDP20SP2-KB2972214-x86.exehttp://download.microsoft.com/download/4/A/E/4AEAB77C-6FF8-44C2-9679-1BAB52B93250/NDP20SP2-KB2978124-x86.exehttp://download.microsoft.com/download/E/0/5/E0501D1E-4046-484C-AB8D-00F82DE53651/NDP20SP2-KB2979574-v2-x86.exehttp://download.microsoft.com/download/5/2/C/52CDC545-676A-4BC8-BA7E-F7634A06205E/NDP20SP2-KB3023220-x86.exehttp://download.microsoft.com/download/2/9/B/29B473CB-63B7-4ED0-8A54-5F512AC2475F/NDP20SP2-KB3035488-x86.exehttp://download.microsoft.com/download/D/A/2/DA2E8293-1888-42EA-BA21-CB88EEC51177/NDP20SP2-KB3037577-x86.exehttp://download.microsoft.com/download/2/B/2/2B23383E-72A3-4B45-A0B2-74F41674AB8D/NDP30SP2-KB2973115-x86.exehttp://download.microsoft.com/download/F/8/5/F859846E-37D4-422F-AA06-DA7F44EB3246/NDP30SP2-KB3048073-v2-x86.exehttp://download.microsoft.com/download/5/D/8/5D8CAE6E-DD52-4654-A8A5-F783079CBD39/NDP40-KB2894842-v2-x86.exehttp://download.microsoft.com/download/A/1/C/A1CF7A32-DE4C-4801-9941-97968014D0CD/NDP40-KB2931365-x86.exehttp://download.microsoft.com/download/7/3/2/7326625B-CED1-4466-A3B2-9ACAE4891ED7/NDP40-KB2938780-x86.exehttp://download.microsoft.com/download/1/5/E/15E6F381-A764-457D-A9BF-D4DF22665F1D/NDP40-KB2972106-x86.exehttp://download.microsoft.com/download/7/7/7/777B7C3B-F6D7-4F2A-BAB9-3E79287009E9/NDP40-KB2972215-x86.exehttp://download.microsoft.com/download/C/C/A/CCA7CA55-9109-42B0-908C-FFA419E4792E/NDP40-KB2978125-x86.exehttp://download.microsoft.com/download/2/F/7/2F798ACF-EFDC-45EA-B76F-F0DE4E67882E/NDP40-KB2979575-v2-x86.exehttp://download.microsoft.com/download/2/0/8/208D1422-5B68-4BEB-BFD2-6B860DA4F978/NDP40-KB3023221-x86.exehttp://download.microsoft.com/download/A/A/3/AA3F6C4D-0DC2-4074-9DAC-88FA3A8AFDD4/NDP40-KB3032662-x86.exehttp://download.microsoft.com/download/B/F/9/BF95F11F-6552-437A-BD62-1666826A8EE5/NDP40-KB3037578-x86.exehttp://download.microsoft.com/download/9/2/1/921E5232-83F4-43CA-8B28-6B4F2A4484F7/NDP40-KB3048074-x86.exePlease do correct me in case I'm mistaken, but... all the .NET 2.0SP2 to 4.0 are international (= multilanguage), right?

I know it's irrelevant... but, just out of curiosity, may I ask what each of these 3 messages signal?

No software firewall at Windows level should be relied on, to defend one from MS new worldview. A good firewall on the router might be reliable enough but, then again, it might impair the setup process... MS may have become obnoxious but hasn't become either naif or senile.

Well, when one wants fast... these are fast! And one can RAID 0 'em, too...