63 replies to this topic

[ktp]

OK, from the config.sys and autoexec, all the files seem to be at the diskette root,
so you have to add few lines in config.sys (COMMON section) and autoexec.bat:

[COMMON]

DEVICE=himem.sys /testmem:off

dos=high,umb

files=30

DEVICE=oakcdrom.sys /D:mscd001

DEVICE=btdosm.sys

DEVICE=flashpt.sys

DEVICE=btcdrom.sys /D:mscd001

country=033,850,country.sys

LASTDRIVE=Z

SHELL=a:\COMMAND.COM /F /P

@echo off

set CDROM=

LH \MSCDEX.EXE /D:mscd001 /L:R

FOR %%i IN (R S T U V W X Y Z) DO if exist %%i:\GB_PROG.EXE set CDROM=%%i



path=a:\;%CDROM%:\

keyb.com fr,,keyboard.sys

doskey

cls

goto %config%

This means that you have an utility like ImDisk to WinImage to change the diskette (floppy) image content, then reinject the image to your iso/CD.
Note: the doskey optional command is only for convenience, to be able to retrieve commands from the command line. country.sys,keyboard.sys and keyb.com/doskey.exe must be present on the diskette.

[Jack57]

Hello

I have done exactly what you told me but it still doesn't work i'm oblige to tape keyb fr in the command line to have the french keyboard
nice try to help me

@++

Jack57

[ktp]

This means that the "keyb.com fr, keyboard.sys" did not get executed or not correctly executed. To debug, you need to set echo on, no clear screen (rem cls) and put a pause to see the result of the command, such as :

@echo off

set CDROM=

LH \MSCDEX.EXE /D:mscd001 /L:R

FOR %%i IN (R S T U V W X Y Z) DO if exist %%i:\GB_PROG.EXE set CDROM=%%i



@echo on

path=a:\;%CDROM%:\

keyb.com fr,,keyboard.sys

doskey

rem cls

pause

goto %config%

[Jack57]

Hello there

Sorry it's work fine now i have an explication when i launch removal goback i always press F5 to go to command prompt Pcdos but i'll see now that in fact when i press F5 it skips startup files running
i would like to thanks all of you for helping me
thanks a lot

@++

Jack57

[dencorso]

what are the differences between HIMEM.SYS versions of winme and win98? in terms of filesize, winme version is smaller at 32711B while win98 version is 33191B. both say the same version: "Windows XMS Driver Version 3.95". is there any advantage of one over the other?

DoS 8.x version (Windows ME) should be 3.99:
http://www.mdgx.com/newtip20.htm

jaclaz

With all due respect to jaclaz and MDGx, wendy is right here:
A binary comparison (using Beyond Compare) of the HIMEM.SYS from Win 98SE and that from Win ME shows that the code in both *is* identical. What changed in Win ME is that a lot of the messages in the *data* part of the file were removed (and corresponding changes were made accordingly in the string dispatch table just above it), as you all can see in the attached screenshot.
And Wendy is again right when she says there is a version of HIMEM.SYS *embeded* in IO.SYS: just create a bootable Win ME DOS 8.00 diskette and delete everything from it, but for IO.SYS and COMMAND.COM. Add to it XMSTAT.EXE from Frank Uberto's XMSDSK package. Boot from it (say in a computer without any OS installed, to avoid any doubt). Once booted, run XMSTAT and you'll see it report the presence of a XMM, managing XMS and HMA. So, no room for any doubt remains about it. As for why there even *is* this message-challenged version of HIMEM.SYS included with Win ME, well, that is the only remaining mystery.
Moreover, the HIMEM.EBD that comes in the EBD folder and goes into bootable diskettes is binarily identical to that one that ships both with Win 98 and Win 98SE. Hence, no, there actually is no v. 3.99

[Wonko the Sane]

With all due respect to dencorso , the posted screenshot shows among the differences in the hex comparison the change from 3.95 to 3.99.

So, a 3.99 version actually exists AND it is functionally identical to version 3.95 AND it is also embedded into IO.SYS.
This makes the following (temporary) classification:

• jaclaz-> RIGHT (this is by definition, you cannot do anything about it )
• MDGx->RIGHT (this also can be assumed as a "by definition")
• Wendy->RIGHT (and even this has been proved by experience)
• dencorso->WRONG ( but has helped in summing up some loose ends, so he is anyway worth, even if wrong, to be "promoted" to "right" )

JFYI, about the HIMEM embedded in IO.SYS, you may appreciate how jaclaz always used a dubitative form, and ONLY about the reason why it was embedded, and when/which/how it was loaded, not about the fact that it was embedded... :
http://www.911cd.net...showtopic=16745
http://www.911cd.net...o...16745&st=13


Wonko

[dencorso]

With all due respect to you, Wonko, you may be Sane, but are also wrong here...
Get your favorite hexeditor and look again at the Win ME HIMEM.SYS, and you'll find:

Offset 654B: "MS-DOS Version 8 ©Copyright 1981-1999 Microsoft Corp Licensed Material - Property of Microsoft All rights reserved"

Offset 7CA9: "Windows XMS Driver Version 3.95 Extended Memory Specification (XMS) Version 3.0 Copyright 1988-1995 Microsoft Corp."

q.e.d.

[wendy]

The file was recompiled for MS-DOS 8, so it has the information embedded in the current dosver.h file. The 1995 copyright message comes from the source for the himem.vxd file embedded in himem.sys.

Much of the differences, between eg MS-DOS 6.20 and 6.22 is the change of string x0614 to xo616 (dosver check), and change of the copyright date by way of dosver.h.

The inclusion of himem.sys may have been a failsafe device. It is indeed possible to deactivate various things in io.sys, and it may be possible to deactivate the internal one and load himem.sys externally. Such may had been needed for variant OEMs.

Here's himem.sys from the various versions. One could describe the versions as by binary comparison, giving the version as indicated. The 3000 ebd himem.sys was included after this run, is exactly the same as 3.98 (as far as fc /b is concerned).

32711  0x3BB75359  "3000/himem.sys"  3.99

	   32935  0xC275B94A  "0950/himem.sys"  3.95

	   33191  0x264590A3  "1111/himem.sys"  3.96

	   33191  0x9E93ACDF  "1998/himem.sys"  3.98

	   33191  0x9E93ACDF  "2222/himem.sys"  3.98

We then look at say, 3.99 v 3.98 (where we find differences due to dosver.h, and differences in the message table. The XMS driver is described as 3.95 in both. 3.99 is then essentially 3.98 with a different message table, to take care of more recent hardware.

Putting 3.96 and 3.98 side by side, we see that 3.98 differs from 3.96 in a lot of byte pairs, having an invariant difference of 0x1001, except when the former starts with f, where the difference is 0x002. Supposing that this is a reversed digits, we suspect that 3,98 is looking for an address location 0x 0110 different for 3.96. At two locations, we see that 3.96 has an isolated byte b8 that becomes c9.

Supposing the address shift fits, we can suppose 3.96 and 3.98 differ simply by relocating some page frame by 17 segments.

Putting 3.95 and 3.96 into tfc, we see that the differences are more varied in the changed byte segment, but the bulk of the changes seems to be a change of order 0x0b80 (reversed), along with isolated changes of 0x10 and 0x40 in some bytes. I suggest that there is further memory fiddling rather than real code change to the driver.

Thus, i suspect that 3.95, 3.96, 3.98 are simply the same driver with getdata.h changed, and that 3.98 and 3,99 simply change the message table. It is then safe to call all of these 3.95, and that for general use, variant 3.98 is the safest one to use.

[dencorso]

It is then safe to call all of these 3.95, and that for general use, variant 3.98 is the safest one to use.

I do agree.

*****

However, I've got to say that finding jaclaz wrong distressed me, because, since he's always right (by definition), that might, with time passing, erode irretrievably the Foundations of Reality...
So I decided to look further on that matter... and found out that, while there really is no stand-alone HIMEM.SYS v. 3.99, a v. 3.99 XMM from MS does exist, albeit being somewhat hidden:

If one boots from a floppy disk having Win 98SE IO.SYS, COMMAND.COM, HIMEM.SYS and a CONFIG.SYS that loads HIMEM.SYS, and then runs XMSTAT.EXE from Frank Uberto's XMSDSK v. 1.9I Ramdrive suite, it'll say, among many other things:

"Driver version : 3.5F"

which shows it actually displays that version in hexadecimal, with "3.5F", meaning decimal "3.95".

Now, if one instead boots from a floppy disk having solely Win ME IO.SYS (ebd) and COMMAND.COM (ebd) and then runs XMSTAT.EXE, it'll say, among many other things:

"Driver version : 3.63"

which shows it actually has found a MS XMM v. "3.63", that is decimal "3.99"! That's the XMM embedded into Win ME's IO.SYS!

Wow! That was close! I sure hope this is enough to keep Reality going...



*****

@wendy: BTW, there is still one more official variant of HIMEM.SYS (size 33127, dated 10/2/95, CRC-32 0x1C0F6BA2), formerly available inside HIMEMUPD.EXE, from KB137755, which is newer than the 0950 variant, but older than the 1111 one. It's obsolete, of course, being of historical interest only.

[Wonko the Sane]

So I decided to look further on that matter... and found out that, while there really is no stand-alone HIMEM.SYS v. 3.99, a v. 3.99 XMM from MS does exist, albeit being somewhat hidden:
....
which shows it actually has found a MS XMM v. "3.63", that is decimal "3.99"! That's the XMM embedded into Win ME's IO.SYS!

Hmm

What happens if you compare the above with what Mdgx wrote and jaclaz ONLY reported ?:

DoS 8.x version (Windows ME) should be 3.99:
http://www.mdgx.com/newtip20.htm

HIMEM.SYS 3.99 is included with Windows ME (a.k.a. MS-DOS 8.00), and is loaded automatically from IO.SYS, rendering the CONFIG.SYS HIMEM.SYS line obsolete.

Can :

included with Windows ME (a.k.a. MS-DOS 8.00), and is loaded automatically from IO.SYS

be interpreted much differently from:

embedded in Windows ME's IO.SYS

?




Wonko

[wendy]

Can :
QUOTE (Mdgx)
included with Windows ME (a.k.a. MS-DOS 8.00), and is loaded automatically from IO.SYS

be interpreted much differently from:
QUOTE (dencorso)
embedded in Windows ME's IO.SYS


?

One might say that HIMEM.SYS is included with Windows 98, and automatically loaded from IO.SYS, but it is not embedded in Win98's IO.SYS.

Windows ME has three different IO.SYS, the versions i called 3.95.8 (EBD), 3.95.9 (himem.sys), and 3.99 (embedded in Windows ME's IO.SYS). We note also that the reported mouse from Windows is the elsewise unknown version 8.30.

It could serve no other purpose than to prevent people loading older himem.sys (eg 3.10, 3.95), or mouse.sys (eg 8.10, 8.20), but allow newer ones (like himem.sys 4.00 or mouse 9.00.

[dencorso]

I disagree with the compressed nature of IO.SYS in WinME, consider this: [...]

To me that means it's compressed.

Thanks to Rudolph R. Loew, this divergence can now be solved: he has just released his awesome freeware decompressor for the various versions (at least the official) of Win ME IO.SYS, called IO8DCOMP.EXE! It is findable at the Prerelease and Beta Section of his Software Catalog.

[Wonko the Sane]

Thanks to Rudolph R. Loew, this divergence can now be solved: he has just released his awesome freeware decompressor for the various versions (at least the official) of Win ME IO.SYS, called IO8DCOMP.EXE! It is findable at the Prerelease and Beta Section of his Software Catalog.

Great news!


Wonko

[wendy]

Time to fire this up again.

 

We've got MS-DOS 7.10.2400 out and running, and trying to get it to boot some versions of Windows 95.  (4.00.950).

 

In order to get this to work, i took dencorso's 'ver710.sys' and patched it three places in the data block  (070A -> 0700 , then 0800 -> 070A)  and all of the 'incorrect DOS versions' in Windows 95 disappear!

 

The plan is to run two different versions of Windows 9x off the same DOS boot. 

 

Mostly the work has been prowling through all of the undocumented commands, and some interesting utilities i have found in the win98 cab files.

 

Dencorso's mention of a himem.sys comes useful, since i do run win95 boxes. 

 

Work continues on running Win95 0950 and Win98 2222 from the same DOS version.