Yes, this is the source where I found it. Some drivers works to some point that is interesting.
e.g. WINDISK solves me boot VDMA issue on SATA3 port but the driver is so poor it cause freezing later on multiple disks access/query.
WINVBE is pretty fast compareed to VBEMP but cause some win32 apps crash when open.
So it brings something new and cool but it's useless for real (I wouldn't say daily) use.
If you noticed, I already created some issues on github but don't expect much happen...

myne wrote on 2026-10-23, 00:53:

Look into what glidulator is doing.
I realise DMA is a possible hurdle, but it looks promising to offload to another core.
No need to care about all the memory problems once you've carved out your niche.

I don't see the need for now. it's an optional feature as SBEMU needs to run on PCs around 2000 era when there was no multi core.
BTW there is no memory problems for now, its optimizations. all memory are put into himem and when "DOS" conventional memory is needed, it's really needed that way. but it can be optimized out.
and multicore management needed to implemented by a supervisor otherwise different drivers will may conflict.

RayeR wrote on 2026-10-23, 06:45:

Hehe, I can give you more precise hint now. I have found that the problem I reported before (that only 1st dir entry is visible […]
Show full quote

crazii wrote on 2026-10-21, 20:58:

Congrats on that and hopefully I will improve USBDDOS in the future, but I'm still busy on VDPMI so I have to put off.

Hehe, I can give you more precise hint now.
I have found that the problem I reported before (that only 1st dir entry is visible by on disk) happens only when I have loaded SHSUCDX.COM (the MSCDEX replacement) optical drives driver in my autoexec.bat that provides 2 drive letters for 2 DVDs and following drive letter is assigned by USBDDOS. When I skip loading the SHSUCDX (or load it after USBDDOS) it works fine then and I can access all files on my USB disk and no lost clusters are reported. So it seems your driver may corrupting some other's memory.
Interesting is that WINUSB behaves almost the same but only under MSDOS 7.10 while under MSDOS 6.22 it works with SHSUCDX loaded. So it gives a hint where the AI learned 😜
Please try with SHSUCDX and optical drive on real HW if you will able to reproduce the bug....

Very interesting. Hopefully I can fix that with your info.

rasz_pl wrote on 2026-10-23, 12:30:

someone just ai slopped a TON of drivers for old stuff, including USB 1/2/3 stack for DOS, Windows 1.0x / 2.x, Windows 3.0 Real […]
Show full quote

crazii wrote on 2026-10-21, 20:58:

hopefully I will improve USBDDOS in the future

someone just ai slopped a TON of drivers for old stuff, including USB 1/2/3 stack for DOS, Windows 1.0x / 2.x, Windows 3.0 Real Mode, Standard Mode and 386 Enhanced Mode (VxD)/ Windows 95 / 98 / ME https://github.com/ages2001/WINUSB

Edit: oh, and apparently https://github.com/ages2001/WINAUDIO "WINAUDIO — HD Audio / AC'97 / Intel audio DSP sound driver for DOS, Windows 3.x and Windows 95 / 98 / ME", curious how the interrupts and SB emulation was handled by the lawnmower, whose code did it rip off 😀
more at Re: List of open-source PC hardware projects

edit2: oh its very clever, it doesnt emulate anything at all 😁 and doenst support DirectSound 😀 drivers to nowhere 😀

Thanks for the info but please stop talking that way. you don't have to do that.

Lualb wrote on 2026-10-13, 02:49:

Hi Crazii, how are you? Sorry to ask this—I've been waiting for this for so long—but if I add GEMMIS to the memory extender on Windows ME (with the DOS real-mode patch enabled and the io8emmok.sys driver loaded so EMM386.EXE can initialize), will I be able to boot into Windows without causing any errors?

Hi there, I'm going to test with win98 and ME, can you be more specific of the problem? As I googled I found some patch being said to fix WinME with EMM386: https://github.com/gpdm/TPC-WinMe-DOSMODE/blo … /FILESOURCES.md
Doe that patch works for you? or do you want a unpatched WinME to work?

I have a laptop with WinME and I remember only the command.com was patched years ago. but never tried EMM386 on it.

crazii wrote on 2026-10-24, 22:54:

Hi there, I'm going to test with win98 and ME, can you be more specific of the problem? As I googled I found some patch being sa […]
Show full quote

Lualb wrote on 2026-10-13, 02:49:

Hi Crazii, how are you? Sorry to ask this—I've been waiting for this for so long—but if I add GEMMIS to the memory extender on Windows ME (with the DOS real-mode patch enabled and the io8emmok.sys driver loaded so EMM386.EXE can initialize), will I be able to boot into Windows without causing any errors?

Hi there, I'm going to test with win98 and ME, can you be more specific of the problem? As I googled I found some patch being said to fix WinME with EMM386: https://github.com/gpdm/TPC-WinMe-DOSMODE/blo … /FILESOURCES.md
Doe that patch works for you? or do you want a unpatched WinME to work?

I have a laptop with WinME and I remember only the command.com was patched years ago. but never tried EMM386 on it.

Hello! The reason I asked whether your software could be used in WinME—either in real DOS mode or from within Windows—is that, as you likely know, WinME does not support any type of expanded memory manager required to enter graphical mode. Furthermore, it does not allow EMM386 to be loaded unless you add `io8emmok.sys` to your `config.sys` file. It’s just a matter of curiosity; I understand that you aim to make it compatible with the graphical environment—much like how one might load `Sbemu.exe` from `autoexec.bat` before entering the Windows desktop—by incorporating GEMMIS into your software.

After many failed attempts to use JEMMEX.EXE, I tried VDPMI.EXE instead, which allowed me to get Sbemu working with good results. By the way, the error shown in the first image comes from Ctmouse.exe; it fails to detect the USB mouse, leaving only the keyboard functional. I’m not sure what the cause might be—perhaps an incompatibility with VDPMI.EXE ???

Lualb wrote on 2026-10-25, 02:13:

WinME does not support any type of expanded memory manager required to enter graphical mode. Furthermore, it does not allow EMM386 to be loaded unless you add `io8emmok.sys` to your `config.sys` file.

I'm aware that EMM386 cannot load without IO8EMMOK.sys, but WinME won't launch if EMM386 is installed? With or without DOS=UMB? I'll try it later to find the result.
VDPMI works without IO8EMMOK.sys as tested, as long as DOS=UMB is REMOVED. EMS seems fine with it.
Maybe I'll have to do some dirty work to try making it launch while DOS still have UMB.

EDIT: tested with EMM386+IO8EMMOK, same result, NOEMS/RAM + DOS=UMB won't launch.

Lualb wrote on 2026-10-25, 04:06:

After many failed attempts to use JEMMEX.EXE, I tried VDPMI.EXE instead, which allowed me to get Sbemu working with good results. By the way, the error shown in the first image comes from Ctmouse.exe; it fails to detect the USB mouse, leaving only the keyboard functional. I’m not sure what the cause might be—perhaps an incompatibility with VDPMI.EXE ???

JEMMEX conflicts with WinME's builtin XMS, you may try JEMM386 with the HDPMI edition of SBEMU.
Is your keyboard also connected via USB? or have you enabled USB legacy support in your BIOS?

crazii wrote on 2026-10-25, 10:09:

I'm aware that EMM386 cannot load without IO8EMMOK.sys, but WinME won't launch if EMM386 is installed? With or without DOS=UMB? […]
Show full quote

Lualb wrote on 2026-10-25, 02:13:

WinME does not support any type of expanded memory manager required to enter graphical mode. Furthermore, it does not allow EMM386 to be loaded unless you add `io8emmok.sys` to your `config.sys` file.

I'm aware that EMM386 cannot load without IO8EMMOK.sys, but WinME won't launch if EMM386 is installed? With or without DOS=UMB? I'll try it later to find the result.
VDPMI works without IO8EMMOK.sys as tested, as long as DOS=UMB is REMOVED. EMS seems fine with it.
Maybe I'll have to do some dirty work to try making it launch while DOS still have UMB.

EDIT: tested with EMM386+IO8EMMOK, same result, NOEMS/RAM + DOS=UMB won't launch.

Lualb wrote on 2026-10-25, 04:06:

After many failed attempts to use JEMMEX.EXE, I tried VDPMI.EXE instead, which allowed me to get Sbemu working with good results. By the way, the error shown in the first image comes from Ctmouse.exe; it fails to detect the USB mouse, leaving only the keyboard functional. I’m not sure what the cause might be—perhaps an incompatibility with VDPMI.EXE ???

JEMMEX conflicts with WinME's builtin XMS, you may try JEMM386 with the HDPMI edition of SBEMU.
Is your keyboard also connected via USB? or have you enabled USB legacy support in your BIOS?

Hi ! ... I have checked the BIOS settings: Legacy USB Support is enabled, Port 60/64 Emulation is also enabled, and XHCI/EHCI Hand-off is enabled. The BIOS detects one USB keyboard, one USB mouse, and three hubs; my computer does not have any physical PS/2 ports. Without VDPMI, CTMOUSE installs correctly on the Virtual PS/2 port (thanks to the BIOS’s Port 60/64 emulation). However, when VDPMI is loaded, CTMOUSE no longer detects the USB mouse, even though all the relevant BIOS settings are enabled—the keyboard continues to work within the system, but CTMOUSE fails in the DOS environment.

I tried the latest VDPMI (from 22.10.) but I have some problem with it.

1) my tools like CPUID and MTRRLFBE crashed when acessing GDT even they are whitelisted in VDPMI.CFG (I have both files directly in C:\, loaded in config.sys by DEVICE=VDPMI.EXE)

2) when trying to start Win98 - hoping that GEMMIS works and allows take over it crashed too.

At least it works with SBEMU and Doom.
BTW I found that when use WinUSB with switch /DOSDISK it solve interference with SHSUCDX and I can read whole USB stick. Japheth tried to reproduce this bug on his AHCI-only machine with AHCI CD driver and SHSUCDX but he didn't observed this issue...

Lualb wrote on 2026-10-25, 14:50:

Hi ! ... I have checked the BIOS settings: Legacy USB Support is enabled, Port 60/64 Emulation is also enabled, and XHCI/EHCI Hand-off is enabled. The BIOS detects one USB keyboard, one USB mouse, and three hubs; my computer does not have any physical PS/2 ports. Without VDPMI, CTMOUSE installs correctly on the Virtual PS/2 port (thanks to the BIOS’s Port 60/64 emulation). However, when VDPMI is loaded, CTMOUSE no longer detects the USB mouse, even though all the relevant BIOS settings are enabled—the keyboard continues to work within the system, but CTMOUSE fails in the DOS environment.

There could be compatibility problems of the VDPMI builtin keyboard/mouse driver. There are bad keyboard response reported in github.
you can set VIntFlag=0 in the VDPMI.CFG to disable the builtin drivers. VDPMI.CFG is available in recent release, may not in the one you're using.

RayeR wrote on Yesterday, 04:11:

1) my tools like CPUID and MTRRLFBE crashed when acessing GDT even they are whitelisted in VDPMI.CFG (I have both files directly in C:\, loaded in config.sys by DEVICE=VDPMI.EXE)

I haven't tested with recent changes, it turns out broken. I've fixed it in the new attachment. it's a bug in the loader that access a freed buffer and corrupts the whitelist.

RayeR wrote on Yesterday, 04:11:

2) when trying to start Win98 - hoping that GEMMIS works and allows take over it crashed too.

It seems the exception context is valid, i.e. not a wild execution. It is LMSW instruction, it's OK as long as the PE bit is set. It's possible that this is a untested code path on your CPU, related to FPU settings, which I haven't encountered with my CPU. It also could be a rare chance that VDPMI failed to switch to real mode and still in v86. Anyway I've add emulation for LMSW, you can test with the new attachment below.

I've finished testing win98se and winME, and added special fix for the UMB:

new option:
/UMB80: prevent DOS kernel from being loaded to UMB.
only visible and accessible in dos 8.0 aka winme only.
other LH/DEVICEHIGH still works, only 10K DOS kernel data kept in conventional memory.
This is a hack that patches two DOS8.0 memory locations, 1 in dos loader data, 1 in dos data. along with some IVT fixes if IVT hooked by UMB address (interrupt installed by driver through LH/DEVICEHIGH), and DOS device header in UMB (loaded by DEVICEHIGH).

Here is the comparison of mem.exe otuput without and with /UMB80.

With /UMB80 (WinME_ImprovedUMB) the block device tables, FILES, FCBS, BUFFERS, LASTDRIVE=Z, STACKS and still in conventional memory.
this allow WinME to startup with DOS=UMB. Note that all drivers loaded with LH/DEVICEHIGH won't be accessible in WinME GUI session, they are hidden.
To make the /UMB80 hack work, "DEVICE=C:\WINDOWS\IFSHLP.SYS" must be the last line in config.sys

I will continue with more tests and bugfixes with SBEMU on real PC.