> Not sure why JLM also needs it, but I guess it
> is part of your plans to port VSB together with some USB sound
> driver to some JEMM JLM? No, it's just because the JLM/JLOAD structure
> already supports I/O virtualization. To add "generic" I/O support (via INT
> 2F.4A15) I had to change the way I/O trapping is done in JEMM which makes it
> incompatible with the way originally Japheth did it with JLM's. I've see at
> least one example of a JLM that uses I/O traps, so to keep compatibility with
> other programs I need to keep JLM's working. I personally think JLM's are a
> bad idea since they only work with JEMM and nothing else and don't intend to
> implement anything via a JLM. > I think USB serial would be cool,
> even when you only support access using the BIOS serial API I've considered
> that, but the problem is that almost no serial programs use the BIOS serial
> API (INT 14h). For it to be useful, it really needs to virtualize the serial
> port hardware. I went through the same issue with the USB joystick driver --
> hardly any programs use the BIOS joystick API (INT 15.84) and they almost all
> access the game port hardware directly. My USB parallel port driver works OK
> using the BIOS (INT 17h) API since almost all DOS programs print through the
> BIOS instead of the parallel port hardware. For an Ethernet port, a
> software-based packet driver would get you most of the way there but I also
> think it needs to virtualize something like an NE2000 at the hardware level
> for older networking applications. In fact, for security reasons (if nothing
> else) I can see someone using something like an isolated NETBEUI/NetBIOS LAN
> for certain applications instead of IP since hardly anybody even understands
> how they work any more. There are similar issues on the USB side, too. While
> there is a standard USB protocol for USB serial port adapters, almost nobody
> uses it. The major USB serial chipset manufacturers (including FTDI) use
> proprietary protocols instead of the USB standard, so writing a USB serial
> port driver is going to be vendor-specific. The same thing is true with USB
> Ethernet ports -- while there is a USB standard almost nobody uses it (one
> USB chipset that does implement the USB standard is the Realtek RTL-8153).
> I'm also playing with some support for touch-screens with my USB mouse
> driver, and those are mostly proprietary on the USB side also. It's a real
> mess when vendors decide to not implement the standards.
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
