Am confused (does not take much lately 🤣). Need more info ! Am confused why you need himem to return a handle-0. What motherboard, Which DOS version and how much total ram do you have?
What app are you trying to run that complains with more than 32MB ram ?
May sound odd but can boot DOS 7 from Win98se with 4GB ram on a Socc 775 quad core and run many apps including Pagemaker 4. So need more info...

Horun wrote on 2023-11-03, 03:45:

Am confused (does not take much lately 🤣). Need more info ! Am confused why you need himem to return a handle-0. What motherboard, Which DOS version and how much total ram do you have?

I don't want himem to return me handle = 0 except if it fail to allocate memory. But if it fail, I want it to actually not allocate memory. Because if it allocate memory and return handle = 0, how are you supposed to unallocate it without the handle. Dos 6.22, System is a "486" (Cyrix 5x86), motherboard is Acer A1GX-2 (version with cache).

Horun wrote on 2023-11-03, 03:45:

What app are you trying to run that complains with more than 32MB ram ?

The one I developing. And it does not complain, it just error correctly because himem told it that it could not allocate the memory. And once exited you type mem /c/p and notice that all the 64MB of ram are used and there is 0 XMS free, all... gone, thanks himem, I only asked for 1024KB!

Only If there is more than 32MB available, and i'm using only himem.sys.
In these conditions, the only way to allocate is to ask himem about what's the biggest block available and then allocate for that amount of KB then loop if more is needed.

Thing is my application need to be able to allocate two contiguous 1024KB block (I did not check if there available, just trying to allocate them directly and it's where it fail (available ram > 32MB, only himem). To make it simple, it think it's fragmented and for some reason the biggest XMS block is smaller than 1024KB. I could just use the loop and allocate more trick but I specifically wanted two 1024KB worth of contiguous XMS (To be able to flush the L2 properly)..

I also made a memory tester in that program and I have no issue with it as for that part of the code I just loop and allocate all the blocks until I get all the free ram (for that, it does not need to be contiguous so I can allocate the whole thing, use it, then unallocate it after.)

I am going to do more test this weekend to see exactly how that fail if possible.
If it's not possible to allocate two "big" XMS chunks (1MB) of contiguous memory with himem only config and >32MB available, then I will simply print an error and use the memory tester path as a failback (with only one memory test instead of 4). That should do the same thing (purge properly the L2) but it's going to take a lot longer.

Hi, I'm not sure if this helpful, but..
Himem.sys of MS-DOS 5, 6.x and 7.x have different max. RAM limits.
They also have different A20 handlers for different machine types.

If MS-DOS Himem.sys can't do it, there are still other DOSes to borrow a Himem.sys from.
DR DOS, Novell DOS, Caldera DOS, as well as PTS DOS, Paragon DOS. FreeDOS, too, I believe.
Some DOSes like X-DOS have their own Himem.sys built-in, as well.

If you want to tell Himem.sys to not take possession of all Extended Memory, you can try to use /INT15= parameter.

Alternatively, for non-gaming purposes, there are Wendin DOS, PC-MOS/386 and Real32.
DesqView and Desqview /X can also help for managing resources.

That being said, the Himem.sys in Novell DOS 7 might be the most sophisticated Himem.sys.
Because it has chipset support for certain motherboards.
Not sure if it's still great on other mainboards, though.

What sets Microsoft/IBM apart was their use of LOADALL instruction, for example:
That CPU reset method so common on 286 systems was dropped quickly in Himem.sys' timeline.

Microsoft's/IBM's Himem.sys had different code paths, rather.
Depending on the machine type (286/386) it used the quickest way of accessing Extended Memory.

Edit: There's also a difference between accessing XMS on MS-DOS 6.2x (and prior) and Windows 9x DOS (related to their Himem.sys/EMM386) .
One addresses RAM bottom-up, the other one top-down. That's important for the cacheable area.
If the cache is too small for the RAM expansion, a performance hit may occur early on.

Edit: I believe that's self-explanatory, but many third-party memory managers do ship with their own Himem.sys replacement.
The downside, however, is that they're sometimes cause more compatibility issues than Himem.sys.

Jo22 wrote on 2023-11-03, 08:56:

Hi, I'm not sure if this helpful, but.. Himem.sys of MS-DOS 5, 6.x and 7.x have different max. RAM limits. They also have differ […]
Show full quote

Hi, I'm not sure if this helpful, but..
Himem.sys of MS-DOS 5, 6.x and 7.x have different max. RAM limits.
They also have different A20 handlers for different machine types.

If MS-DOS Himem.sys can't do it, there are still other DOSes to borrow a Himem.sys from.
DR DOS, Novell DOS, Caldera DOS, as well as PTS DOS, Paragon DOS. FreeDOS, too, I believe.
Some DOSes like X-DOS have their own Himem.sys built-in, as well.

If you want to tell Himem.sys to not take possession of all Extended Memory, you can try to use /INT15= parameter.

Alternatively, for non-gaming purposes, there are Wendin DOS, PC-MOS/386 and Real32.
DesqView and Desqview /X can also help for managing resources.

That being said, the Himem.sys in Novell DOS 7 might be the most sophisticated Himem.sys.
Because it has chipset support for certain motherboards.
Not sure if it's still great on other mainboards, though.

What sets Microsoft/IBM apart was their use of LOADALL instruction, for example:
That CPU reset method so common on 286 systems was dropped quickly in Himem.sys' timeline.

Microsoft's/IBM's Himem.sys had different code paths, rather.
Depending on the machine type (286/386) it used the quickest way of accessing Extended Memory.

Edit: There's also a difference between accessing XMS on MS-DOS 6.2x (and prior) and Windows 9x DOS (related to their Himem.sys/EMM386) .
One addresses RAM bottom-up, the other one top-down. That's important for the cacheable area.
If the cache is too small for the RAM expansion, a performance hit may occur early on.

Edit: I believe that's self-explanatory, but many third-party memory managers do ship with their own Himem.sys replacement.
The downside, however, is that they're sometimes cause more compatibility issues than Himem.sys.

Thanks for the Idea, I did only test with dos 6.22 himem and windows 95b himem.
I will check with some other to see if there is the same behavior, maybe first with FreeDOS himem.

Personally I don't really care much as I mostly use QEMM or himem+emm386 couple.
But I just decided to test something with himem only and as I disabled xhdd (normally configured for ~32MB), I got the "why win31 tell me there is no XMS and fail to start" moment (my program is in the autoexec and had already triggered the bug by then).
As that's program is going to eventually be released (Actually, it is, in it's early form). At least that's something I will document in the readme in case other users try to use it in the same circumstance, like, "If you get XXX error, then you could try yyy or iii himem.sys to get the cache mode change option to work at the normal speed". But at least the alternate path will work, just from "ramsize_in_MB/2 to ramsize_in_MB * 8" times slower than normal path, depending of how much cache is installed, when changing the cache mode.

You also may try a himem.sys from Win98SE...

I have been doing some tests:

• Himem.sys dos 6.22 : FAIL
• Himem.sys windows 95 : FAIL
• Himem.sys windows 98 : FAIL
• Himemx.exe Freedos : PASS

Still doing some tests but so far the freedos himem seam to work as expected when there is more than 32MB of available ram (Can allocate big chunks of XMS without having to split them into small allocations).