[RetroOS]

xrayer, on Mar 31 2008, 03:03 AM, said:

Problem (partially) solved!
After some days of messing I finally found HimemX XMS manager freely available here http://japheth.de/Jemm.html
which allows you to limit XMS size by /MAX= option. After I limit XMS to 1GB it boots and seems to work fine!
Of course windows sees then only 1GB but it's acceptable for me, I don't need then any commercial patch.
...

Nice!

xrayer, does this also let you boot into Safe Mode?
This was always a problem with 1.5GB or more of RAM since the SYSTEM.INI memory settings are ignored in Safe Mode.
I wonder if by limiting RAM at the XMS manager level, it might be possible to get more RAM available to Windows than the current maximum 1152MB?
1280MB?
Something to look at!

[xrayer]

Currently, with only replacing the himem.sys its unable to boot safemode coz windoze then load himem.sys on its own. But I found the strings in IO.SYS and patched and then it run also in safemode. I will program some small patch utility to rewrite it.
Installation of himemx.exe is quite esay, just download it, extract himemx.exe to windows directory and replace the line in config.sys to calling this driver. It has regular EXE stub so you can type "himemx.exe" in command line to get help, also there is included documentation and source code Thanks to Japheth maintaining it.

This post has been edited by xrayer: 31 March 2008 - 04:20 AM

[dencorso]

You might want to try patch.exe, from KanastaCorp: it's freeware, very small and very simple to use.

I think you should add Xeno86's fixed VCache.VxD to your system, at least because, when in Safe Mode, as you know, system.ini is ignored, so that your system is at risk of crashing from VCache getting too big. It gives you a default of 393216 (384 MB), which is much safer than 800 MB, and you still can keep your MaxFileCache=261120 entry in system.ini file, for normal mode operation.

And, finally, if you feel like it and have time to do it, I'd much appreciate to know how your system behaves when limited to 1280 MB and to 1536 MB, with a XMSDSK of 262240 and MaxFileCache=114688. Yes, these are the settings that work in my 1.5 GB system, but I use a 32 MB video board with 64 MB AGP aperture... My guess is that your system won't work with 1.5 GB but may possibly do so with 1.25 GB. Since you are the first to discover that windows 9x/ME in fact does not directly detect how much RAM the system has, but relies instead in what the XMS manager tells it, you should also be the first to explore the tweaking possibilities this knowledge opens up to all of us.

You rock!

[xrayer]

Hi,
I wrote a small patch yesterday http://www.volny.cz/...os/w98iopat.exe which fix IO.SYS to load himemx.exe instead of himem.sys for safe mode. I don't have problems with crashing in safemode (btw I know about mentioned fixed vcache.vxd). Just copy patch to root dir beside io.sys and run it (make backup before).

I didn't much experimended how can be RAM increased, I just try a few values 1.5G 1.25G (physpage=60000 resp 50000) and it hangs during boot so I gave it up, some additional few megs + are not much important for me, I need stable system. I laso tried to eat excesive RAM with XMSDSK but it didn't work for me.

[StarRiver]

Thanks for xrayer I also multiboot Win98 and WinXP with 2GB RAM successful while use HimemX.exe

Here's my win98's modify steps

1. Download HimemX from http://japheth.de/Jemm.html

2. Copy himemx.exe to win98 directory

3. Add the line in config.sys

DEVICE=C:\WIN98\HIMEMX.EXE

4. Here's my lines of system.ini:

[386Enh]
MaxPhysPage=48000
MinSPs=16
ConservativeSwapfileUsage=1
DMABufferSize=64

[vcache]
MaxFileCache=65535
ChunkSize=1024

After these step, I boot win98 with 2G RAM successful

In winXP, the sysem can detect 2GB RAM


And in win98, the system can detect 1150MB RAM

[fhub]

Hi xrayer,

xrayer, on Apr 1 2008, 12:51 PM, said:

I wrote a small patch yesterday http://www.volny.cz/...os/w98iopat.exe which fix IO.SYS to load himemx.exe instead of himem.sys for safe mode.

I think there might be a little problem with your IO.SYS patch!?

Look at the bytes in the following 2 lines: (o=0x0, d=0xd)
\HIMEM.SYSo/TESTMEM:ONdoo
\HIMEMX.EXEo/MAX=999999do

Since HIMEMX.EXE is one byte longer than HIMEM.SYS, the termination zero-byte 0x0 is moved one byte to the right by your patch. But this is exactly the byte where the HIMEM parameter /TESTMEM starts. So if IO.SYS is using the usual method of addressing strings (with a fixed address table), and I´m quite sure it indeed does it this way, then this address pointer for the parameter now points to this zero-byte (instead of the starting ´/´ of /MAX=...). So this parameter /MAX=999999 isn´t used at all by IO.SYS, I´m afraid!

A simple solution would be to just rename HIMEMX.EXE to HIMEM.EXE, so the length would be the same as HIMEM.SYS and the terminating zero-byte doesn´t need to be moved.
Furthermore you could now even use 1 full GB (1048576) instead of 999999, because after the /TESTMEM string there are 2 zero-bytes (but only 1 is needed of course), so you could increase the string length by 1 byte.

This post has been edited by fhub: 01 April 2008 - 02:57 PM

[xrayer]

fhub, on Apr 1 2008, 10:55 PM, said:

I think there might be a little problem with your IO.SYS patch!?

Look at the bytes in the following 2 lines: (o=0x0, d=0xd)
\HIMEM.SYSo/TESTMEM:ONdoo
\HIMEMX.EXEo/MAX=999999do

Good poit, can we display or log what will io.sys really call?
Anyway renaming to himem.exe is the simplest way to be sure.
Another thing is if /MAX= is needed at all, StarRiver claims
he run without this parameter. Hm, I will need to do some
more testing.

[xrayer]

Shortly

1) I upgraded io.sys patch to replace himem.sys by himem.exe so rename of the file is needed

2) I can confirm that /max=... parameter IS NOT really needed in config sys (so then I wondew why MS himem.dont work and this himemx works)

3) I did a finetune of MaxPhysPage and ended at value 488FF. Crazy is that when I set 1st itme edit 40000 to 48000 it booted but in VGA mode and display ed error of VGA configuration and open resolution change CPL. But whe I go back an increment MaxPhysPage with smaller steps and do rebooting between every change I was able to reach 488FF (over I got insufficent memory). I tried also xmsdsk again but always got VFAT error BSOD.

[dencorso]

Congratulations, xrayer!
Now your system is detecting the maximum amount of memory that Win 98SE can detect (for more see this link). Win ME, on the other hand, is known to detect about 1995 MB, but I've never had any success in devising a patch for having vmm.vxd v. 4.90.0.3003 load with Win 98SE. That vmm seems to be much different from v. 4.10.2226, so perhaps it is impossible to have it working in Win 98SE...

xrayer, on Apr 1 2008, 10:43 PM, said:

2) I can confirm that /max=... parameter IS NOT really needed in config sys (so then I wonder why MS himem don't work and this himemx works)

Well, about this I can tell you two things:

i) It has nothing whatsoever to do with their code, because, although Japheth's HIMEMX is carefully and elegantly coded, Win 98SE's vmm.vxd bypasses all code, literally taking possession only of the data areas (or of the XMS handle table, at the very least). Then again, HIMEMX puts its XMS handle table in its data area, well below 640 kB, in the normal DOS memory arena, while HIMEM.SYS uses the HMA for its table. Even so, I doubt this can cause the different behaviour you and StarRiver observed.

ii) Japheth's HIMEMX is *not* HIMEM.SYS, and does not try to fool Win 98SE into believing it is. So Win 98SE's vmm.vxd acts more tactful in its presence, probably forgoing the use of many undocumented hooks it cannot be sure would work, because it is not dealing with HIMEM.SYS and knows it. This probably is the main difference.

Be as it may, the fact is that you found a way that works, and that certainly will be of help to many others!

BTW, there is a rumour, over the net, that XMSDSK hates to be loaded at the top of XMS, with 2 GB or more of RAM.
The same rumour says it stops crashing if you load it without the "/T" command-line switch. Did you try this? I cannot tell you whether this is a urban legend or a fact, because I have only 1.5 GB in my machine, so it's below the purported threshold.

This post has been edited by dencorso: 02 April 2008 - 01:18 AM

[RetroOS]

dencorso, on Apr 2 2008, 06:28 PM, said:

...Win ME, on the other hand, is known to detect about 1995 MB, but I've never had any success in devising a patch for having vmm.vxd v. 4.90.0.3003 load with Win 98SE. That vmm seems to be much different from v. 4.10.2226, so perhaps it is impossible to have it working in Win 98SE...

Hi dencorso,
I attempted earlier in the year to patch the Windows Me VMM.VXD 4.90.0.3003 to work in 98SE...
I got all the version checks sorted and also the VMM DOS loader version report to IO.SYS sorted...
Nine code changes in all.
The problem is that Me VMM.VXD does not like 98SE V86MMGR.VXD...
So I patched Me V86MMGR.VXD 4.90.0.3000 to work in 98SE with three code changes...
But... 98SE just does not want to work with Me V86MMGR.VXD. It fails with an exception.
Probably something to do with IO.SYS I expect.
I could not get past the V86MMGR.VXD exception, so I shelved it.

[vick1111]

Thanks again for xrayer

I have just installed HimemX.exe on Windosws 98 SE on an Asrock 4coredual-sata2 -Intel core 2 quad processor -2 Gb of DDRII -

My win98's modify steps are just as above

1. Download HimemX from http://japheth.de/Jemm.html

2. Copy himemx.exe to win98 directory

3. Add the line in config.sys

DEVICE=C:\WIN98\HIMEMX.EXE

I am now able to put a maxfilecache of 44000 (48000 did not work for me) while before I was only able to get as high as 40000.

And the most important thing is that I completely solved problems with dos boxes.

I can now start an almost unlimited number of dos windows instances while before (without the himemx) I was unable to run more than 3 dos boxes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[xrayer]

dencorso, on Apr 2 2008, 07:28 AM, said:

The same rumour says it stops crashing if you load it without the "/T" command-line switch. Did you try this? I cannot tell you whether this is a urban legend or a fact, because I have only 1.5 GB in my machine, so it's below the purported threshold.

Hoho, it works
So now I got 850MB ramdisk for swapfile
c:\dos\xmsdsk.exe 850000 z: /t /y

And thanks for thoughts about himem vs himemx. I don't know windows kernel magic how it can behave with different xms mgrs.

EDIT:
Ou, seems that windows cannot use xmsdsk ramdisk for swappping. I cannot see the drive letter in swap file setting dialog

EDIT2:
Aha, it can be redirected in system.ini now it works
[386Enh]
PagingDrive=Z:

This post has been edited by xrayer: 02 April 2008 - 01:13 PM

[dencorso]

xrayer, on Apr 2 2008, 01:49 PM, said:

So now I got 850MB ramdisk for swapfile
c:\dos\xmsdsk.exe 850000 z: /t /y

Glad to know it works! Thanks to you we've learnt quite a bunch of new things about Win 98SE.
BTW, you meant to write: "c:\dos\xmsdsk.exe 850000 z: /c1 /y" right?

I've also read somewhere that if you rename the ramdisk to any name, except "MS-RAMDRIVE", during autoexec.bat, then it'll show in the swap file setting dialog...

[xrayer]

dencorso, on Apr 3 2008, 02:32 AM, said:

BTW, you meant to write: "c:\dos\xmsdsk.exe 850000 z: /c1 /y" right?

No, /c1 parameter only set cluster size I don't care about it let it set automatically. Parameter /t is important.

[rsx7]

vick1111, on Dec 30 2007, 12:25 PM, said:

Well I have tried everything that was possible (given my knowledge of the problem) and I have not been able to make XMSDSK work without problems.

I have Windosws 98 SE installed on an Asrock 4coredual-sata2 -Intel core 2 quad processor -2 Gb of DDRII -

I have developed the idea that the MaxFileCache entry does not solve definetely the out of memory error.

In some cases no matter what the entry for the MaxFileCache or for MaxPhysPage I got an out of memory error when starting dos.
(I have verified memory values with system monitor)


---------------------
My failed attempts
---------------------
Even in the most favourable situation after starting 6 instances of dos windows,
the out of memory error appears again.


At one point I was able to make XMSDSk work without problem with:

c:\ramdisk\xmsdsk.exe 500000 z: /T /Y
(in autoexec.bat.)

At that point I did loose completely the use of Dos window.

(It is like some important memory resources are taken by the video card or something else and I have no clue about what is it! even if I have developed the idea that the solution is not in the maxfilecache settings : the solution must be in some kind of wise memory management I cannot find)

-----------------------------------
My present configuration (without XMSDSK)
----------------------------------
I have upgraded to service pack 2 for 98 SE.

and my present settings are:

autoexec.bat
mode con codepage prepare=((850) C:\WINDOWS\COMMAND\ega.cpi)
mode con codepage select=850
keyb it,,C:\WINDOWS\COMMAND\keyboard.sys
LH /L:2 C:\WINDOWS\COMMAND\DOSKEY /INSERT
PROMPT $p$g
SET DIRCMD=/P /A

system.ini

[386Enh]
MaxPhysPage=40000
ebios=*ebios
mouse=*vmouse, msmouse.vxd
device=*dynapage
device=*vcd
device=*vpd
device=*int13
woafont=app850.fon
keyboard=*vkd
MinSPs=16
ConservativeSwapfileUsage=1
DMABufferSize=64

[vcache]
MinFileCache=3000
MaxFileCache=393216

(rest is omitted)

config.sys
DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:OFF /Q
DOS=HIGH,UMB
DEVICE=C:\WINDOWS\EMM386.EXE NOEMS X=A000-F7FF
DEVICE=C:\WINDOWS\setver.exe
device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=039,850,C:\WINDOWS\COMMAND\country.sys


(I have tried and cannot use UMBPCI.SYS at the place of EMM386 cause my motherboard is not supported)


EMM386.exe did work only with the setting: X=A000-F7FF .

I do not think that EGOvoruhk either has solved the problem????

In this configuration I am able to start 2 (two) fresh dos windows before I get the out of memory at the 3rd dos istance.


-----------------------------------
XMSDSK Failure
-------------------------------------
Whenever XMSDSK succesfully creates a ram drive then my dos windows become unavailable for the "out of memory error"

MOREOVER XMSDSK does not work properly: when I start the scandisk, to check the sectors into the ramdrive Z, the write attempt fails after a while.
A more simple copy write attempts fails too.

The failure happens not at a specific point.

what happens is that I got a blue screen with not recoverable error sayng things like:

"An exception 0E has occurred at 0028:C0004D6D in VxD Vmm(01) + 00003D6D. This was called from 0028:C19359C4 in Vxd Rmm(01) + 00000254"

I have tried many different settings for XMSDSK.

(Some example :

c:\ramdisk\xmsdsk.exe 1800000 z: /T /Y
c:\ramdisk\xmsdsk.exe 1100000 z: /c1 /T /Y
c:\ramdisk\xmsdsk.exe 500000 z: /T /Y
c:\ramdisk\xmsdsk.exe 500000 z: /c64 /T /Y
c:\ramdisk\xmsdsk.exe 500000 z: /c1 /T /Y
)

great!

[dencorso]

xrayer, on Apr 3 2008, 11:18 AM, said:

dencorso, on Apr 3 2008, 02:32 AM, said:

BTW, you meant to write: "c:\dos\xmsdsk.exe 850000 z: /c1 /y" right?

No, /c1 parameter only set cluster size I don't care about it let it set automatically. Parameter /t is important.

Well, I think you didn't get my point...
I can run XMSDSK with or without the /T switch, and Win 98SE doesn't care. Older versions of Win refused to run without the /T parameter (which loads XMSDSK at the top of XMS, as farther away from HMA as possible), for sure. As I said, Win 98SE does not care whether XMSDSK is at the top or at the bottom (close to the HMA) of XMS, in my experience, so the /T parameter in not fundamental anymore. However, there is a legend that XMSDSK has a bug that prevents it from loading at the top with 2 GB or more of RAM. Since you are able to load and run XMSDSK OK, having 2 GB of RAM, you either demonstrated it is just a baseless legend, or, more probably, have found out yet another strange quirk related to HYMEM.SYS, for it works for you but you are using HIMEMX.EXE. Curiouser and curioser...

On the other hand, the /C1 switch directs XMSDSK to automatically select the smallest possible sector number per cluster, what leads to the best possible performance of the FAT, without you having explicitly to set that number. Hence, in my opinion, you should be using it.

Frank Uberto's XMSDSK is among the best and most carefully written pieces of software I've ever seen. It rocks.

This post has been edited by dencorso: 03 April 2008 - 07:48 PM

[dencorso]

vick1111, on Apr 2 2008, 08:33 AM, said:

And the most important thing is that I completely solved problems with dos boxes.

I can now start an almost unlimited number of dos windows instances while before (without the himemx) I was unable to run more than 3 dos boxes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Hi, vick1111!
I confirm your finding: before I was able to open around 20 DOS Boxes, whereas, with HIMEMX and all other things unchanged, I can now open more than 40!

This post has been edited by dencorso: 04 April 2008 - 01:16 AM

[xrayer]

dencorso, on Apr 4 2008, 02:44 AM, said:

On the other hand, the /C1 switch directs XMSDSK to automatically select the smallest possible sector number per cluster, what leads to the best possible performance of the FAT, without you having explicitly to set that number. Hence, in my opinion, you should be using it.

I'm not sure about it. When you have small clusters then FAT must be greater and seeking for the specified cluster will take long time when browsing large FAT. And when using the ramdisk for paging file the minimum allocated size is one page - 4kB so smaller clusters don't bring any advantage. Anyway for my ramdisk size and FA16 FS limitation the smallest cluster size is 16kB. I didn't checked what value was automatically set.

This post has been edited by xrayer: 04 April 2008 - 07:47 AM

[xrayer]

>GreyPhound

I finally had time to read through entire thread from the beginning.
Thaks for your effort with translation of Igor's technical article,
I got some better view or windows memory management now.
Spasibo!

But it's still not clear why in some cases himemx.exe works
and himem.sys not. Anyway I'm use this solutoin more than week
and didn't found problem. I only sometims hit the limit of swapfile
in ramdisk when etiting huge soundtracks in goldwawe, swapfile
ran out of space and shoot windows down. If I would had set swap to HDD
it could grow to bigger size. But from ramdisk it runs pretty fast!
Unfortunatelly memory protection is poor so instead kernel should
shoot the app exceeding memory it allow shoot off all system
It depends on used program.

[Offler]

to XRayer:
if you enter XMSDSK line like this:
c:\dos\xmsdsk\xmsdsk.exe 524288 K: /c1 /t /y
C:\OS\COMMAND\label K: scorpion

then the xmsdsk will be labeled as scorpion drive and system will recognize it as a harddisk. than you can enter the parameters in system settings without manually editing system ini. the drive will become visible for swapping. you can do this in Autoexec.bat