If I'm not mistaken, you are trying to get a USB to Serial adapter to show up as a native COM port in DOS (FreeDOS or MS-DOS)? DOSUSB serdrv.sys is the closest to that but it has compatibility issues with software that directly accesses the serial port instead of using using the INT 14H interface. It also only designed to work with a specific type of adapter (Prolific). Basically, as far as I can tell there is no real, seamless solution for this.

Curious what USB->Serial converted anddrivers you are using under DOS... I've not looked into it much and don't recall seeing one with DOS support.

But... since almost all programs that use the serial port do so by directly accessing the 8251 compatible native PC UART device (DOS has such bad general serial support built in), I can't see how anything that wasn't specifically designed for it could talk to a USB serial port - but If I got one working, I might see if I could figure out how to talk to it...

I have an old AASTRA (formerly) VOIP PBX that I have DOS running on - but the only way to "talk" to it is via network (I fount a packet driver that works with its built-in ethernet).
There are no serial ports (how I usually interface to my homebuilt add-on controllers) - but there are about 6 USB ports...

DOS comm software works in DosBox because DosBox virtualizes the host serial ports (be it an actual hardware UART or USB device) as 8250 compatible devices.
I often interface to my serial controlled devices from DosBox, often via a USB serial cable. All my DOS software see is a standard 8250 UART.

Hi,

For a more detailed explanation:

The 8086/8088 architecture was originally not conceived with virtualization in mind. For interrupts replacing the original one can be done by saving the original interrupt vector to a variable, having the program Terminate and Stay Resident then handle the interrupt in the program.(optionally using the original interrupt vector in case where the original behaviour is preferred)

However as @DaveDDS mentioned, most of the time serial ports was handled with direct I/O instructions, those cannot be redirected in the x86 real mode.

The 386 architecture introduced Virtual 8086 mode, and for 16-bit Real Mode programs the issue could be hypothetically solved by making a simple 32-bit protected mode hypervisor that runs the DOS program in Virtual 86 mode, setting up the TSS I/O permission map to pass through all the I/O ports used except the ports used by the UART, in that case when an I/O access happen to those "forbidden" ports a general exception will be issued by the CPU that the hypervisor could handle and handover the necessary data to the USB-to-Serial driver. Why it hasn't been done? Well making a hypervisor + drivers for all of the USB-to-Serial devices(Which has enough documentation available to even developed them) would be not a weekend project, and as there are no industry need for such kind of a system, I don't think anyone would really take it up as a hobby project.

And all this effort would be needed to support only the 16-bit DOS applications, for the 32-bit ones, well 32-bit virtualization was introduced much later by AMD with AMD-V(With Athlon 64, don't remember the exact model though) and Intel with VT-X(Introduced in some of the later Prescott P4 models, I think the server/workstation Xeon-s got it a bit earlier), and those extensions are primarily designed to work with full 32-bit or 64-bit operating systems, 32-bit DOS programs generally call DOS interrupts via DPMI which are 16-bit, and as such I think AMD-V and VT-X cannot handle this transition properly, making it unlikely to have a solution that works with 32-bit DOS programs.

It is unlikely but might be possible to somehow coax the debugging registers DR6 and DR7 to trap the I/O instructions on processors that support CR4.DE(Control Register 4 - "Debugging Extensions", introduced in the Intel Pentium processor), but as those are meant for debugging and not virtualization purposes even if it would work, it would make for bad performance, so I think even if somehow it be made to work, the performance decrease wouldn't be worth it.