awkduck

mTCP programs are establishing connections correctly. HKLM\Software\Microsoft\Windows\Real Mode Net netcard "pktndis.dos" transport "ndishlp.sys" Good pointer deomsh, I didn't know about those settings, but above is what is listed. Hey jumper. That is actually the standard interrupt vector for packet drivers. ---- I still think that the Windows "ODIHLP.EXE" expects those extra frames, for NDIS3 mapping. Or PDEther isn't feature complete enough. I tested a real ODI driver, and each frame type is listed as a board that "ODIHLP.EXE" binds to. PDEther does not even list Ethernet_II when "ODIHLP.EXE" is attempting to bind. The result is: bound to adapter PDETHER Error: not bound to any boards EDIT: I guess Ethernet_II doesn't get listed anyway? I'm pretty sure the NET.CFG for PDEther is set correctly. Here it is: Link Support Buffers 8 1600 Link Driver PDETHER Int 0x60 frame ETHERNET_II Protocol IP 800 Ethernet_II Protocol ARP 806 Ethernet_II Protocol RARP 8035 Ethernet_II

That is a good point, for anyone using KernelEx. I've now tested with connection. The install was still fine. There is an XML file, in my test install. "C:\Program Files\Java\jre1.5.0_22\libs\servicetag\registration.xml". Could be that the file it is looking for is the template. So how far into the installation do you get? Does it even start copying files?

I tested in WINE, for Linux. It is configured with no connection to the Internet/Network. I run with a slim desktop environment. Everything is ran from a Terminal. It just so happened, I didn't close the terminal when running the Java installer. So I can see different things happening in the background. It made several failed calls for Internet access. So, you may be on to something However, I didn't test allowing for the connection. It has been so long since disabling it, I've forgotten how I did it. I noticed that this version of Java contains it's installer data in a folder labelled "jre.1.5.0.b64", so the XML file may have nothing to do with another version. Maybe it is just weird sun/oracle naming conventions. The XML may relate to a variety of versions, until the file required renaming.

@justacruzr2 Is any Java listed under add and remove programs? What do you have under "C:\Program Files\Common Files\Jave\Update\Base Images"? Has anything been copied to "C:\Program Files\Java"? You can also check the regestry, "HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Uninstall". Click on the {} key folders and look for one or more with Java in them. At any rate, if you delete the registry key in Uninstall (the whole folder icon {} that contains a Java version "example 1.5.0.220") and the corresponding Java folder in Common Files, you should "for certain" not be dealing with any installer other then the one you are clicking on. Are you doing a custom install?

@justacruzr2 Do you by chance have 1.5.0_06 already installed? It is weird that it wants a prior Java version XML file. If so, you could uninstall it. Then try to install via the update 22 file. You might also try the AUTO_UPDATE=DISABLE argument. Maybe even the STATIC=1 argument.

Hi, SweetLow. Yes, that I have. There is a section in "PROTOCOL.INI" where you set the interrupt of the packet driver. [PKTNDIS_NIF$] DriverName=PKTNDIS$ interrupt=0x60 Net start fails to completely bind. Here is the complete "PROTOCOL.INI" [NDISHLP$] DriverName=NDISHLP$ Bindings=PKTNDIS_NIF$ [PROTMAN$] DriverName=PROTMAN$ priority=NDISHLP$ [DATA] version=v4.10.2029 netcards=PKTNDIS_NIF$ [PKTNDIS$] devdir=C:\WINDOWS\PKTNDIS.DOS device=PKTNDIS.DOS,@devdir\PKTNDIS.DOS [PKTNDIS_NIF$] DriverName=PKTNDIS$ interrupt=0x60 The shim "PKTNDIS" loads, after the packet driver, and displays that it is using interrupt 0x60. The packet driver is also set to interrupt 0x60. Hmm. You could be right. I haven't had very much experience using ODI with Win9x. The only reason I've "assumed" that it needed those other frame types, was because Win98 automatically adds them to "NET.CFG". Since PDEther does not support them, it will not load at boot time. If you remove them, leaving only Ethernet_II, Windows has no connectivity.

Alternatively, I thought about "Packet Driver > ODI > Win9x" I've tried PDEther, a packet driver to ODI tool. But it only supports frame type Ethernet_II. Windows networking "Existing ODI Driver" expects Ethernet_II, *_802.2, *_802.3, and *_SNAP. So it did not work out.

I know you can use a "real mode" NDIS2 driver with Win9x. And I know you can provide a virtual packet driver, for use in Windows Dos Prompts. But is there a packet driver to NDIS2 shim, so that you can base all your "in Windows" network connectivity off a packet driver? A discussion on Dosemu2's Github, provided PKTNDIS, but I think that it is only for NDIS(1). Any Ideas?

For now, this is the newest I have found. It is 1.5.0.07 vs 1.5.0.22. It is the full offline version. I'll look around a bit more. I tend to avoid Java, so haven't kept bookmarks of online archives. Edit: Here we go, 1.5.0.22. And here, just in case. Sorry if that does not work. It seemed like you wanted the update? But they are all the JRE 1586-p. I am Java ignorant.... And maybe then some.

@SweetLow You have a good point. Seemingly, your USB update has managed the lack of a BIOS EHCI hand-off option. Now, as far as can been seen, everything seems to work great. Nice work!

Just remember those priceless "Wonko the Sane" quotes. One in particular. To me, it seems like he is climbing a mountain; just because it is there. I had a friend who was quite nostalgic about Zip drives. He bought a bunch of standard floppies, just so he could reformat them to hold a handful of MP3s. There wasn't really a point. And no one he knew thought it was cool. He knew that too. I guess he just wanted the idea manifest before him physically.

Update, if you've read this far along. shelby is now able to connect. The issue was the unusual comment character used in "WATTCP.CFG". In Windows' INI files ";" is used as a comment/ignore character. Wattcp uses the Unix comment character "#". A comment character was blocking a configuration option from being read. But, the guidance about firewalls, involving VirtualBox generated I.P.s, is probably incorrect information. I have not used VirtualBox for much networking, and didn't understand its networking design. In the NAT configuration, all assigned I.P.s are handled internally. Outside of VirtualBox, any firewall just needs to allow VirtualBox network/internet access. I probably should have assumed this is how VirtualBox worked, as the setting is called NAT. I was distracted, by my comparative testing using a real machine. !No excuse! :)

Just in case someone else runs into this, or something like it, here is the rest of the situation. For me thing is workable (better than before). Ironically, if I want to format the USB drive correctly, I must boot the system with the USB drive connected and legacy USB enabled in BIOS. But, I must remove the drive and reinsert it to access the partition. I thought it was because FDISK had ran. But it turns out, if I boot with it connected and legacy USB enabled in BIOS again (already partitioned and formatted), I still cannot access the drive without removing and reinserting the it. Like I said, I can live with it. Thanks for the assistance, you two.

Alternatively, you could just have the batch swap out SYSTEM.DAT files. But that would mean any registry update, you saved, would need to be committed to each "hardware configuration" SYSTEM.DAT file. Another one of those, pick your poison things. Not that you would often need to save new registry setting, if the system was fairly complete in configuration. That is where making portable apps comes in handy. They also make new system setup handy. If they are homemade portable apps, you can just make sure to put them in the same location as when they where created; and done. The exception being software with VXD files, or anything that needs to be activated during Windows boot; this rather then at application execution.

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.