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 Yesterday, 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 ???