Winbox 3.11
Dunstan Jomphe
When programming for DOS, I typically use native Windows development tools and do most of my quick testing/debugging in an emulator. So my workflow involves very frequent file transfers from the host (Windows) to the emulated machine. When the emulator is DOSBox, its filesystem integration makes this quick and painless.
But in PCem or 86Box it gets a little more cumbersome. There may be ways to do this if the emulated system has networking (or even a CD-ROM), but let's say it doesn't. To copy anything from the host filesystem to the hard drive image, you can either:
I'm thinking of a quick-'n'-dirty tool to let you select (and keep) a list of files, then do the image creation and file transfer in one click. Something like AutoHotkey combined with ImDisk Virtual Disk Drive should do the trick.
I've actually started working on this, but:
For that kind of thing I like to use GNU mtools on my Linux system.
A line like mcopy -i disk.img build/from.com ::TO.COM can easily be added to a Makefile.
I don't know whether there is a Windows port of it, though.
Yep, that's an option. In Windows, the abovementioned ImDisk does the same.
However my thought is to handle the required actions on the emulator side as well, probably by sending GUI events/keystrokes. There aren't too many of them, but even the manual eject/mount/copy/unmount dance does get old after a while.
Can't you exploit the IMD disk image format to format a 64K(1 byte less, so 65535 bytes/sector) sectors disk with 256 sectors/track, 80 tracks(for compatiblity), then a simple 4-byte header (start of the first sector, the boot record sector usually) followed by the file in all remaining sectors you want to transfer as the file system and complete disk? Then you can transfer a huge amount of data using the floppy disk standard(although formatted to the maximum supported amount)? That's 16MB/track, for a whopping of 1.2GB using said disk image for one huge file? of course, the last sector can be less than 64K to signify EOF(also signified by a sector read failure on any track, so that can be used as a EOF marker(together with maximum disk sector being reached as a reason), skipping the need for the header altogether, thus creating a disk image out of a file essentially?
Although you'll need a simple tool to format it like that? Although in the end, the maximum size will be a bit lower(since sector sizes need to be a power of 2, so 32K sectors except the final sector, requiring smaller sector powers of 2). Although to do non-power of 2 transfers for the final sector, you'll effectively need said header anyway(to perform rounding down of the final data)?
So that's a 4-byte file size header combined with the rest of the disk needing to be 32K sectors for containing all file data(thus allowing 32K*256*80*2=1.28GB of storage, with 4 bytes being reserved for the file size, thus 4 bytes less of floppy disk space for your single file)? Of course, that file can also be things like a simple .zip archive(which can be easily unpacked using any tool, e.g. pkunzip or linux commands)?
That sounds a bit like making three left turns when you can turn right... and I don't think the emulated DOS would support these oddball formats, anyway?
To transfer large amounts of data there's always a CD-ROM image (although, with the time it'd take to copy all that data inside the emulated machine, the "live injection" approach may not be worth it).
I think this came up on the pcem forums but Sarah wasn't interested in the VPC/Vmware approach due to dealing with multiple operating systems both on guest and host or mabye I'm thinking of someone else, would have to track down the post.
Why not considering networking?
I do the same on QEMU, too, and I have SLIRP or TUNTAP networking options with the host. On Windows host, I use TUNTAP. On Linux host, I use SLIRP which gives access to SMB shares on the host.
I've never actually tried networking with PCem/86box, but I should mention that my emulated target is about as minimal as it can be: 8088 CPU, 640K RAM, DOS only.
Such a guest machine should handle mTCP + an 8-bit NE2000 packet driver, but that means FTP for file transfers - kinda inconvenient for very frequent compile/test cycles. As for complete network solutions that allow remote shares, all reports I've seen indicate failure (and on the real hardware, they're usually very RAM-hungry when they do work).
For my testing I have a batch file and a text file. The batch file fires up FTP and has it redirect STDIN from the text file. The text file has all of the input that FTP would need to sign on, change directories, and transfer a file. It is not as convenient as having a drive letter right there, but typing "get" (the name of my batch file) is pretty quick once it is setup.
My use-case involves frequently updating and transferring the same file(s). In that case, you can simply keep the tool open with a fixed file list: when you click "inject", it'll always grab the most recent copies from the host filesystem.
Hi VileR! I've been looking for a solution to copy files to 86box directly and found this thread, but I haven't been able to use your tool with 86box 3.11. Maybe can you update it to support this version? Or there is a new way to copy files?
If using FTP, UniPCemu can also act like a PPP server as well as a serial modem capable of connecting to it (using TCP connections like Dosbox). So if you can use virtual serial ports on the host, you can connect UniPCemu to one end (like using COM0COM) as a modem and allow the other side to be connected to your emulator (which uses it's own serial port to access it like a normal serial Hayes modem). Then it's simply a matter of using miniterm or some other dial-up terminal to dial to the PPP server (which can be the very same UniPCemu app instance if configured for that), then start a PPP IPv4 driver to get network connectivity. SMB works on the PPP connection, although only within the same network as the client (so with other clients also connected to the UniPCemu PPP server using dial-up, verified with multiple Windows 95 instances myself). FTP is also possible using the same method (which doesn't have the shortcomings of the SMB protocol requiring the same network, as the host network isn't available to clients connected (although the internet is) due to the way subnet broadcast works) to connect to any other client on both networks.
Although oddly enough UniPCemu can't perform ARP to it's own host machine it's running on (Windows 10 at least) somehow. It will simply fake the ARP reply to itself using it's known host data (from the server settings) in that case though.
Tried the PPP connection myself using the Arachne web browser's own drivers (it's miniterm to dial, combined with lsppp or pppd or any other compatible IPv4 PPP driver after that). With autoconfiguration it requires a passive option for the proper PPP to start, but with manual text-mode login it can also work properly on PPP (selecting empty username and password and the protocol being given as ppp (lower case)).
I've discovered a better way, using MSCDEX with 86box CD emulation. If you map a Windows folder to a 86box CD drive, the files are always updated, so no need to mount/unmount the drive. This way I can copy files very fast and without having to create images nor something like that.
SMB using UniPCemu server should be possible in theory.
Just use a virtual serial port like COM0COM to create a virtual serial port.
Then connect modern windows to the serial port on one end and UniPCemu emulating a modem on the other end (directserial). After that, use Windows to dial to the server's own TCP port using PPP to archieve a direct dial-up connection with any connected clients.
Then, since both the Windows(running SMB) and a client(which connects using SMB) are connected on the same local network(within UniPCemu's server) they can connect through SMB.
Didn't go past two Windows 9x clients in Dosbox tho, but they can see each other and transfer files.
Just map one emulated port to one physical port of a 2x USB serial adapter with a null-modem attached.
The other application (DOSBox etc) then uses the other physical port.
Works on Linux, too.
As for nullmodem, I used COM0COM myself testing UniPCemu's serial dial-up server. Although I needed to add a bugfix I made myself to the COM0COM driver source code to fix some detection issues with it (to allow UniPCemu to use it's documented detection algorithm, which is bugged in the last release. Then there's the whole W10 driver signing issue, requiring unsafe boot to even use the fixed device driver) if using specific COM0COM support. And unfortunately a full two-to-one serial port for full modem emulation can't be done using it (connecting two lines from a second outputting port to the first port, making the second set of DTR/RTS lines into two extra status lines for full Hayes modem emulation). Haven't found any driver capable of that, unfortunately.
Windows 10 combine two virtual serial ports with different wirings into one serial port?
The local folder CD-ROM in 86box is near to a perfect solution, it basically works similar to a read-only shared folder. No need to update anything, just copy files between the CD mapped drive and the hard disk drive via DOS. With a simple batch script you can copy the whole folder into the hard drive directly.
4a15465005