awkduck

After disabling BIOS USB legacy support, and then booting with the USB drive connected, Windows installed some USB related driver. It was not very specific in description. However, the Systray didn't provide the connected device icon. The USB drive was not accessible. After removing and reinserting, the drive and MBR were accessible. Interestingly, after all of this, I can now have legacy USB enabled in BIOS; and MBR access is still retained. Initially, I though that the only reason it was "now" allowing me access (even with legacy USB enable), might have been something to do with "now" having been partitioned/formatted by Dos through Windows. But partitioning/formatting the device with Linux, with a foreign Linux filesystem, didn't prevent access to the MBR.

I'm sure there are ways. For me, I would just disable GUI boot in MSDOS.SYS. Then you could use a Dos boot menu with options for different configurations. Each option would, by batch, modify your "active" hardware profile. It would do so by using the Dos registry tool. You could also ignore the profile and just modify which hardware needs to be enabled/disabled. An issue arises, if you have a machine without BIOS USB to Serial Keyboard emulation. The boot menu would do you no good. In that situation, you could load both a floppy and harddisk image. Transfer your MSDOS.SYS, CONFIG.SYS, and AUTOEXEC.BAT to the foppy image. The floppy would carry the batch for system configuration, or AUTOEXEC.BAT would run one on the Hardisk. But you would need a floppy image for each configuration. Then you could just use a bootloader with USB keyboard support.

Yep. It is a 2005-ish machine, Intel ICH5. It does not boot from USB unless legacy is enabled. But when disabled, I can modify the MBR from Windows.

Well, kills it in a sense of new "lively" development. People will be playing Dos games and using Dos programs for some time. When I say kill, I mean it no longer grows. But those that have enjoyed using it, remain hopeful. Thank you, Freedos (and all the sentimental archival soldiers keeping lost files found).

Maybe a typo or something.

WATTCP.CFG?

TLS 1.3 could exist for dos. With the abundance of open source code, it is more about patching the difference between systems. However, with dos, it becomes more a labor of love. With Dos, you must reinvent the wheel many times over. There isn't an abundance of modern, or even near modern, supporting code base. On top of that, the dos compilers are more static in development state. Code, meant from modern systems, is always being updated to build under new compiler versions. If there were interested developers, Dos could become more capable in meeting modern use scenarios. One downside, as opposed to writing support code for other systems, is that the code would mainly benefit Dos. It would be much less portable to other systems. Portability has become important to the development ecosystems. Portable code can also be a boon, but that is another topic. One issue that seems to cast a dark shadow, over Dos, is PC/Laptop vendors aiming for hardware without BIOS. It isn't the last nail in the coffin. If you look a the Raspberry Pi, it has no BIOS. Operating systems wishing to run on the RPI needed to write a kind of bridge. Sometimes it is called a firmware. You can kinda imagine it as a virtual BIOS, but this isn't quite correct either. Something like this could be done for Dos, for x86 hardware distributed without BIOS. But, it would require interested developers. However, there may be interest in this area, as such a development would support running other operating systems, like older Windows and OS2. This would not be an easy undertaking. And you would need a specific "Virtual BIOS" for every hardware version of Laptop/PC. But there are plenty of, powerful, BIOS enable machines floating around for now. As an alternative, a machine architecture independent Dos could be developed. One that could be ported to ARM devices. The issue there is that the bulk of original Dos software would not run on it, without some kind of emulation layer. Amiga has been doing that for awhile now. The Amiga fans have a spiffy FPGA system called the Vampire. The Vampire V4 is offered as Amiga upgrades or as a standalone system. For Dos we do have the Mister, supporting an FPGA clone of an enhanced 486SX. For era recreation, this is pretty good. But to reach a larger audience, I would estimate that such a system would need to meet at least Pentium II equivalence at 450Mhz. A 800Mhz system, with some 3D Video acceleration, would get some good attention. Right now, this isn't really an option. The price of such a machine would out weigh the extra spent on a authentic machine. The Amiga group is in a different situation. Edited in: It should also be mentioned, that there is a push to always replace security, productivity apps, protocols enhance, media fidelity and Definition enhance, etc. While there is lots of open source code there, it is often corporately beneficial. With more reliance of enormous code bases, you get a kind of Vendor lock in. What most people like about Dos, is the absence of the update/upgrade/replace(waste) mentality. However, Dos faces the obsolescence lock in. To fully enjoy it, you need old hardware or emulation. Emulation is a great way to enjoy and explore Dos. But for those seeking a more literal escape from the digital realities of life, emulation seems a bit defeating. The metaphorical Dos resurgence, is only virtual. Like a rebellion in a box. But this may be going a little far. There is good joy in finding something new, even if it is old. If you follow Dos back to it's early heritage, you find people running a kinda Homebrew Dos on Homebrew hardware. There is no reason Dos couldn't fork from the modern direction of protocols and security. You might not be able to post on Facebook or Pay your bills. But there is nothing stopping people from writing independent Dos social media platforms. Linux was a kinda Homebrew system, for a long time. In my option, the main issue with Dos is the lack of a multitasking interface, shared audio, better shared (at least) vesa support, full multitasking memory access, and shared networking. We have Windows. But then, this is about Dos and the Future of Dos. Dos is cool. But what kills a system, is it not being used by enough capable people.

As jaclaz has been kindly pointing out, the issue "was" the BIOS. PartitionMagic still cannot see the drive. But, Fdisk and HxD are happy now. The machine had legacy USB support enabled.

Maybe, the Links DNS could be useful. But for connectivity issues, resolving the host (www.somepage.com), it is more probably related to D.N.S. settings in the config file. We know that you get an I.P., when one is requested from your router/gateway. We've seen that by running Trumpet and mTCP DHCP. And if we use mTCP PING.EXE, we can test connectivity with D.N.S. servers. So we know that the only issue is getting the browsers to resolve www.somesite.com into an I.P. address the browser can connect to. Sometimes, you can get around that by manually entering the site I.P. into the Browser. That could tell you for certain the browser is connecting, but just not resolving. After that, the more probable issue is, in this case, that the WATTCP.CFG is still incorrect somehow. One less likely possibility is that, running in VirtualBox somehow prevents you from fully using multiple I.P. addresses at the same virtual Ethernet adapter. Since you can run Trumpet and mTCP DHCP, with different I.P.s, it suggests things are fine here. And lastly, there could be something preventing connection to these I.P.s, outside of VirtualBox.

I do question if there is still *somehow* an issue with the D.N.S.. It seems the documentation(s) often say you may need to use your gateways as the D.N.S.. Some of the automatic configurations do exactly that. But too me, using your actual D.N.S. would be more appropriate. But, I too hope it works.

@SweetLow USBHUB20.SYS USBD_CreateConfigurationRequestEx USBD_PraseConfigurationDescriptorEx The other two are fine.

With Trumpet, you can check the main log Window. With WATTCP, there is an option in the config, to save the DHCP settings to a file. Obviously, if you specify a static address, that should be the I.P. you are using. I believe, if mTCP programs are not pre-assigned DHCP in the config, they will display the information during execution. If you need your host I.P., for Windows you can follow these directions. Those are for Win10&11. But its very similar for other Windows. If you need to find out what other I.P.s are on you network, it might be good to have a administer access to your gateway/router. That should, at the very least, have a log. But more then likely, It will have detailed network client information and status. ---Some Notes--- Since you say you are kinda just learning things, there are some things I'd like to put out there. There is a ton of information that could be included in this thread. You and I are just stumbling on them as subjects occur. But with that said, even on the subjects we have touched on, there is plenty of undisclosed information. For example, with the setup you are now using, it should be possible to use all static addresses having the same I.P.. But there is potential for occasional conflicts. I have never had one, when run that way. But, I am sure it is possible. My explanation for suggesting the setup you have now, is that it is the more "By the Book" clean approach. Since you are having some configuration issues, it seems best to apply the most diagnostic friendly setup. Earlier we had you running PKTDRV in MsDos Prompts. For me, that has worked pretty well, for some projects. But, by the nature of these components, I have occasionally ran into memory conflicts. The constraints involved there are a deeper subject. With appropriate care and consideration, those conflicts can be avoided. The simple rule of thumb, is to unload every PKTDRV before closing the MsDos Prompt, that loaded it. You would run the desired application, in between loading and unloading, from that same prompt. And if loading multiple MsDos Prompt PKTDRV sessions, manually specifying each new interrupt would be advisable. Separate Dos VMs (Windows MsDos Prompts) don't acknowledge, or at least don't always acknowledge, each others interrupt use. They will tend to only acknowledge real Dos interrupt use. PKTMUX is running in real dos. But even without that real/VM Dos crossover, there is probably potential for conflict.

It certainly can be done. Just gotta pick your poison. I suppose the issue for some people, is portability. Depending on the OS configuration, some machines may not care to boot it. Using Hiren's minimal Windows 98 as an example, it goes to show that a high rate of compatibility can be achieved.

I'm just mentioning the 2 versus 1 partition, as a way to expand on some of the speculations jaclaz has put forth. The primary issue, is accessing the MBR. As an example, the boot loader Syslinux comes with an MBR that must be written to the drive, in order to function as a sole boot loader. When I am installing it, to the main O.S. drive, I can use something like WDE for dos. However, in attempting to do this for a USB drive, WDE cannot even view the MBR. The same is true for the HxD hex/drive editor. But to answer your question, if the drive is zero filled, FDISK cannot even see the drive. "Change current fixed disk drive" displays only the physical C: drive.

One that is within the range your gateway/router is configured to accept. When you ran mTCP DHCP, it only added 1 the the I.P. of Trumpet. So, you are probably safe following that example. For every static I.P. you need, you can probably just add one. Certainly, 254 is the max. However, some routers are configured for a shorter range. Since you gateway is 192.168.1.254, 254 is off limits. Any other I.P. already in use, on the network, is also off limits.

In Windows FDISK can see the drives partition, when there is only one. If I put two partitions on the drive, FDISK crashes after asking if you want to enable large disk support. The reason I looked into this, is because sometimes I end up behind a Windows machine, more then a Linux machine. I also don't really ever use any NT variant. Sometimes I run into a situation where I'd like to make a bootable USB drive, and would like to do it without rebooting. It is something I can easily live without. But, sometimes you've just got to see if it can be done.

Consider this, the free version of Paragon NTFS for Win9x works on Win95. So that eliminates the likelihood of needing several updates. The manual states that the System requirements are: Windows 95/98/ME, 16 MB of Ram, an NTFS partition or the space to create one. I don't know about other NTFS drivers/software, because I haven't tried them.

Will do.

Their DHCP is built in (onboard). mTCP programs will read the config file. If the config file is configure for DHCP, mTCP programs will use their internal DHCP; unless the config file has the settings already saved at the bottom. WATTCP programs will also follow their config file, and use their internal DHCP. But those setting are only saved, for latter use, if the config file is set with the option to save them. At the bottom of this page, it says that some WATTPC programs don't always work with DHCP. (bug?) If that is the case, you might need to set the file your self. That same page provides a example snippet.

I have the files to give "Switch to Win3" a shot, but haven't gotten around to it. I haven't examined the Win3x drivers from the leaked build. But, I think they certainly would aid it beyond the stock files. They are probably the most important files. I've guessed that there is a little more to it then just being in a V.M.. If the host keyboard input is disabled during use, then you can't simply Alt+Enter to see it turn to a Window. The up side, is that the guest would get your Alt+Tab, instead of the host. So, if a V.M., it is an altered one. It would be nice if someone running it sported the about Window. Or testified if you could open a Dos Prompt. I'm sure it can't. There are enough legacy files, in Win9x, to build an okay standard mode Win3x. But you'll get no Dos Prompt. You'd need to build a better "SYSTEM.INI".

In the Arachne DOC folder, there is a file "LAN.HTM". It says,

In WATTCP.CFG there is a variable "my_ip". It can be set to dhcp (the default) or static I.P. "my_ip = dhcp" or "my_ip = xxx.xxx.xxx.xxx"

Yup Or at least it seems like you got it.

No. Dillo and Links look to WATTCP.CFG at execution and use the information inside to determine how to connect. They have their own DHCP. DHCP is just used to put information at the bottom of MTCPCFG.CFG. But I asked you to use it, to verify that your Dos applications were getting a different I.P.. And to show you what I.P. you might have to allow firewall passage, if you wanted connection for them.

TCP/IP Stack It is important to understand, that in Windows there is a single TCP/IP stack that Windows programs utilize for networking. There is a TCP I.P. issued and all Windows TCP/IP programs route through it. Dos does not use the Windows TCP/IP stack. Dos also does not have a "main" TCP/IP stack. Most of the time, a TCP/IP stack is built into each program. Since Dos is single tasking, this isn't a problem. One task = one I.P.. So, if we multitask TCP/IP stacks, we get multiple I.P. addresses. Wattcp is a TCP/IP stack, and programs with it built into them use WATTCP.CFG as a configuration file. mTCP is a TCP/IP stack, and programs with it built into them use MTCPCFG.CFG as a configuration file. They can't use the same file, because they are not the same TCP/IP stack.