Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Soundcard emulation in DOS on non-legacy hardware. Possible? (Emulation)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 04.11.2022, 22:03

> I don't like that API - too immature and "hackish", IMO. The few
> applications I checked that use that API also intrude into the monitor's
> context and modify GDT/IDT. So even if you implement that API in Jemm,
> probably none of those apps would work with it out of the box.
I agree, at least up to a point. Microsoft's implementation was really bad (uninstalls don't always work properly, Word/DWord I/O doesn't work at all, etc.). But the simple fact that it was created and implemented by MS gives it a lot of credence in my book. I think what MS did with the whole VFAT thing to support LFNs was a terrible hack as well (it broke a lot of other programs, including some of MS's own programs), but we're stuck with it. I know this is not the FreeDOS forum, but if FreeDOS is supposed to be pretty much a direct replacement for MS-DOS, at least one of the FreeDOS monitors should support this API.

You're correct that some existing apps need to modify the GDT to do what they need to do (I haven't seen one that modifies the IDT -- that's part of what the API is supposed to do for them). Again, though, that's because of the poor way MS designed and implemented the API (they assumed the implementation would be done with a "simple" TSR where everything was in one segment). At least some of the programs I've seen that needed to do something with the GDT simply ASSUME a specific format in the GDT (which GDT entries were associated with which selectors). That's just a really bad idea (definitely worthy of being called a "hack"), but it worked with MS's poor implementation.

One of the things I do in the new version of the API is provide a pointer to the GDT so that the program can make modifications if needed. I know that's a bad idea from a security/protection perspective, but the whole concept of virtualizing I/O is a security hole anyway (that's part of the reason why NTVDM didn't even allow I/O, at least by default). Of course, it's also possible to create GDT entries some other way and then just reference them without needing to directly mess with the GDT at all.

As far as working "out of the box", the programs won't work with JLOAD either, so that's not exactly a valid reason to not implement it.

> Btw, the I/O trapping is already implemented in Jemm ( actually, it's
> JLOAD, see JLM.INC - since Jemm's memory model is flat, zero-based, it's
> best to emulate some of the Win9X ring0 APIs ).
I know, but I think there needs to be a more generalized way to virtualize I/O than JEMM/JLOAD, and MS provided a way to do it with this API.

> To mmake that suitable for Jemm, the "IRQ virualization" should be
> implemented in JLOAD, as a small subset of the Win9X VPICD API.
I think it would be possible to do both, but haven't yet tried to integrate the JLOAD piece.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 59 users online (0 registered, 59 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum