DOS ain't dead

VDPMI approaching GEMMIS...

Thu, 15 Oct 2026 05:05:54 +0200

Reply from RayeR, 15.10.2026, 05:05:

> BTW, I add a comments to each line of my ASM source code, too. Do you you
> think there's something inappropriate about that?

For those who don't code asm every day it may save some time re-reading ref/opcode man...

386MAX and assembly language comments

Wed, 14 Oct 2026 22:50:25 +0200

Reply from mceric, 14.10.2026, 22:50:

> > BTW, I add a comments to each line of my ASM source code, too...

While I agree that the comments are plenty, I do prefer well-commented code over little-commented code. Typical example: Assembly language optimizations using XCHG instead of MOV where nobody has an idea what was the intended effect and what was the to-be-ignored side-effect after a while ;-)

And 386MAX is software which works well. I would assume that the comments helped to make it like that :-)

VDPMI approaching GEMMIS...

Wed, 14 Oct 2026 21:21:42 +0200

Reply from Japheth, 14.10.2026, 21:21:

> From what I understand (and I may be completely wrong), when Windows starts
> it sense a message to EMM386 (or 386MAX) the send its memory management
> information to Windows (with GEMMIS) and then shots itself off and lets
> Windows take care of the memory management. When Windows shuts down, it
> does the same thing in reverse and the EMM turns itself on again.

From my understanding that's pretty correct.

> BTW, I add a comments to each line of my ASM source code, too. Do you you
> think there's something inappropriate about that?

IMO it's "suboptimal" - a comment shouldn't tell what is done but rather give an idea why something is done. Else, if used obsessively, it just increases the N part of the information S/N ratio ( as ecm has pointed out ).

386MAX and assembly language comments

Wed, 14 Oct 2026 20:32:34 +0200

Reply from ecm, 14.10.2026, 20:32:

> BTW, I add a comments to each line of my ASM source code, too. Do you you
> think there's something inappropriate about that?

I tend to agree that not literally every line should have a comment. The disadvantage is that sometimes the "comment" is useless noise that just rehashes what an instruction does, not the how or why. For instance, scanning one of the 386MAX source text files for a moment:

https://github.com/sudleyplace/386MAX/blob/f743b78...3909aeea368187125aefbe/386MAX/QMAX_DMA.ASM#L428

; Because we just changed the page table, we must flush the TLB

         call    FLUSH_TLB      ; Flush the TLB

This states three times we're flushing the TLB.

https://github.com/sudleyplace/386MAX/blob/f743b78...3909aeea368187125aefbe/386MAX/QMAX_DMA.ASM#L457

assume fs:PDTGRP ; Tell the assembler about it

Telling the assembler about a segment assumption is exactingly what the assume directive is.

https://github.com/sudleyplace/386MAX/blob/f743b78...3909aeea368187125aefbe/386MAX/QMAX_DMA.ASM#L473

         popad                  ; Restore all EGP registers

                                ; N.B.:  Do not follow with [EAX+???*?]

         ret                    ; Return to caller

The NB is useful, the other two comment lines exactly repeat what the instructions do.

https://github.com/sudleyplace/386MAX/blob/f743b78...3909aeea368187125aefbe/386MAX/QMAX_DMA.ASM#L578

         push    di             ; Save for a moment



         mov     di,si          ; Copy as physical source for REST_PTE

         call    REST_PTE       ; Restore 'em and flush page translation cache



         pop     di             ; Restore

Saving for a moment and restoring a register using push and pop is very much the usual way to use the stack. These comments don't add much signal here.

VDPMI approaching GEMMIS...

Wed, 14 Oct 2026 18:47:20 +0200

Reply from bretjohn, 14.10.2026, 18:47:

> > GEMMIS was an interface used to transfer "ownership" of the memory
> > management (and maybe some other stuff) from EMM386 to Windows and back
> > again. Was GEMMIS ever ever used for anything other than than the
> > interface between an EMM and Windows? I know Bob Smith (Qualitas) got
> his
> > QEMMM to work with Windows, at least partially.
>
> I may be wrong, but isn't Mr. Smith the 386MAX guy?
>
> I remember he's one of those assembly coders that add a comment to
> each source line... :-(

You're correct -- I got 386MAX and QEMM confused. He did get 386MAX to work with Windows, and AFAIK he's the only one that ever made a competitor to EMM386 that worked with Windows. He did some other interesting stuff, too.

But that doesn't answer my question -- was GEMMIS ever used for anything other than the the interface between Windows and an EMM? Does anybody know?

From what I understand (and I may be completely wrong), when Windows starts it sense a message to EMM386 (or 386MAX) the send its memory management information to Windows (with GEMMIS) and then shots itself off and lets Windows take care of the memory management. When Windows shuts down, it does the same thing in reverse and the EMM turns itself on again. It doesn't send everything to Windows, though (like the I/O port redirections), but just the memory management information.

BTW, I add a comments to each line of my ASM source code, too. Do you you think there's something inappropriate about that?

VDPMI approaching GEMMIS...

Wed, 14 Oct 2026 10:10:53 +0200

Reply from Japheth, 14.10.2026, 10:10:

> GEMMIS was an interface used to transfer "ownership" of the memory
> management (and maybe some other stuff) from EMM386 to Windows and back
> again. Was GEMMIS ever ever used for anything other than than the
> interface between an EMM and Windows? I know Bob Smith (Qualitas) got his
> QEMMM to work with Windows, at least partially.

I may be wrong, but isn't Mr. Smith the 386MAX guy?

I remember he's one of those assembly coders that add a comment to each source line... :-(

Physical RAM in pure MS-DOS

Wed, 14 Oct 2026 03:45:07 +0200

Reply from RayeR, 14.10.2026, 03:45:

> In the past I saw a nice table created by RayeR who compared the maximum
> RAM which can be used by various DPMI servers.

The table is here (1 page below)
http://rayer.g6.cz/programm/programm.htm#DJGPP_MEM

VDPMI approaching GEMMIS...

Wed, 14 Oct 2026 02:44:17 +0200

Reply from bretjohn, 14.10.2026, 02:44:

>> So maybe one day it could fully replace MS EMM386 - will be able
>> cooperate with Win9x...
>
> Interesting.

GEMMIS was an interface used to transfer "ownership" of the memory management (and maybe some other stuff) from EMM386 to Windows and back again. Was GEMMIS ever ever used for anything other than than the interface between an EMM and Windows? I know Bob Smith (Qualitas) got his QEMMM to work with Windows, at least partially. But I don't know that GEMMIS was ever used for anything else.

VDPMI approaching GEMMIS...

Wed, 14 Oct 2026 01:32:32 +0200

Reply from RayeR, 14.10.2026, 01:32:

I just uploaded logs on github, no sound produced.

Glidulator - 3Dfx software emulator for DOS-multicore

Wed, 14 Oct 2026 01:26:22 +0200

Post by RayeR, 14.10.2026, 01:26:

Just another fancy project, that took voodoo emulation code from 86box, add SSE optimized JIT compile and offload it on second CPU core - finally some real and usefull usage for multicore under DOS...
https://www.vogons.org/viewtopic.php?p=1450397#p1450397
And SBEMU could run on other core :)

VDPMI approaching GEMMIS...

Tue, 13 Oct 2026 23:03:11 +0200

Reply from Japheth, 13.10.2026, 23:03:

> So maybe one day it could fully replace MS EMM386 - will be able cooperate
> with Win9x...

Interesting. Btw, have you forgotten to test your CA0106 SB card with vsbhda? I supplied a - may be - fixed version 8 days ago...

See

https://www.bttr-software.de/forum/forum_entry.php...amp;page=0&category=0&order=last_answer

Physical RAM in pure MS-DOS

Tue, 13 Oct 2026 16:32:11 +0200

Reply from Laaca, 13.10.2026, 16:32:

In the past I saw a nice table created by RayeR who compared the maximum RAM which can be used by various DPMI servers. However I am not able to find it more (maybe it disappeared from internet?)

But it is sligthly different topic - if the question is how much of RAM is accesible from pure MS-DOS, unmodified, without 3rd party drivers, the answer is, that with XMS method up to 4GB (minus reserved areas, so realisticaly around 3,5GB). With EMS method 32MB. With VCPI method 32MB.
However you can use 3rd drivers (like JEMM386) and the accessible XMS and VCPI will be bigger.

VDPMI approaching GEMMIS...

Tue, 13 Oct 2026 04:01:36 +0200

Post by RayeR, 13.10.2026, 04:01:

Crazii just announced he started implementing GEMMIS to his VDPMI/XMM/V86mon
https://www.vogons.org/viewtopic.php?p=1450372#p1450372
So maybe one day it could fully replace MS EMM386 - will be able cooperate with Win9x...

Physical RAM in pure MS-DOS

Mon, 12 Oct 2026 08:24:21 +0200

Reply from Oso2k, 12.10.2026, 08:24:

> And there's also another RAM disk driver -
> https://bttr-software.de/forum/board_entry.php?id=18797#p18797

And EMS driver for 64GB of RAM - https://board.flatassembler.net/topic.php?t=19410

Physical RAM in pure MS-DOS

Mon, 12 Oct 2026 08:10:21 +0200

Reply from Oso2k, 12.10.2026, 08:10:

> > upper limit of "physical" RAM that can be used in pure MS-DOS.
>
> Define better what you mean here? Used by MS-DOS? Which version of
> MS-DOS? Used by MS-DOS applications? Are you constraining yourself to
> period relevant tech (<1998 or <1995)?
>
>
> DOS mem command can have issues with more than 64MB for some versions. I
> think some had issues with 16MB too. Some older apps have issues with more
> than 16MB installed even if they don't have a use for it.
>
> Few applications will be able to take advantage of more than 64MB and if
> they do, they're relatively lightly documented and are pretty much
> "non-standard conforming".
>
> You best bet advantage to take of larger memory installations will be:
> * djgpp with CWSDPMI r7
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/cwsdpmi/
> * HimemSX with RdiskSX and its smartdrv patch
> https://github.com/Baron-von-Riedesel/HimemSX/blob/master/Readme.txt
> https://github.com/Baron-von-Riedesel/HimemSX/blob/master/RDiskSX/RDiskSX.txt
> https://github.com/Baron-von-Riedesel/HimemSX/tree/master/Smartdrv
>
> I briefly tried these things on a HP t5745 thin client with 2GB of RAM and
> a Dell Optiplex 9020 with either 16GB or 32GB of RAM. IIRC, the HP did not
> like these bits of software but it was also a bit short on the RAM. The
> Optiplex did a little better. I could create the RAM disk but HimemSX was
> a bit unstable, as was the RAM disk. I don't recall if I enabled smartdrv.
> I didn't have time to dig in further at that moment. Maybe I'll try again
> soon.

And there's also another RAM disk driver - https://bttr-software.de/forum/board_entry.php?id=18797#p18797