awkduck

Something else may be conflicting with it. I initially thought KernelEx was a possibility, since setting compatibility on the initial EXE installer wouldn't matter. Maybe MSI execution continues under default KernelEx settings. But you've tried with KernelEx disabled, so no dice.

It might just be a re-occurrence, of the Java issue. I bet there is a file "Nero.msi". I don't know this is certain, for your case. I downloaded a Nero7 and extracted the contents (7-zip), to find that it uses the "Windows Installer". It could be that you are installing edge 98se supported software, were configuration for older systems may have lacked attention. Or, maybe something is wrong with the system's "Windows Installer". Again, as of now, neither is certain It may be it a bit extreme, but you could modify the MSI to function the same on 98se, as it does on newer systems. No guarantee that will work. Also, as mentioned in the Java thread, you could make a portable application. If it is "Specifically" Win98se causing the problem, then its probably the "Windows Installer" (broken?). Historically, newer software is written less and less compatible, towards older systems. To the eager new shinny application user, if the application failed to load, it was obviously the old version of Windows at fault. Ah, the cycle of replacement. How it drains the poor and ignorant, while blessing the cunning and wealthy. Don't take me too seriously here. I'm just over dramatizing the reality of commercial progress. Buy it, you need it. Buy it again, you need it again. We are the ones using the technology, right? Its not the other way around? All my drama, and we'll find out it was a bad harddisk. I actually thought about comparing Java installer file hashes. But I doubt the harddisk is the problem.

Progress is progress. Thanks, for the update.

@justacruzr2 One other thing you could try, is installing it in safe mode. I've had to do that once. Alternatively, you could uninstall it on ME. Then export your ME registry to something like "B4.REG". Download a new-ish Regshot and 9x usable Windiff. If the version of Regshot is too old, I'm not sure that it records file changes; which "here" is the only reason for using it. Run Regshot, and take your first shot. Install Jre 5 22 again. Take your second shot and then export your registry a second time to something like "AF.REG". Then you are going to compare the two shots and reg files. With the Regshot comparison, only note the new files; the registry list is not REGEDIT4 formatted. Now run Windiff: WINDIFF.EXE -FRX JAVAIN.REG B4.REG AF.REG The order of files listed "IS" important. You'll need to open JAVEIN.REG in Windows Write. At the top and bottom of the file, there are lines starting with "--". They are from Windiff, and can be cut out. At the top of the file, add a line "REGEDIT4". The click "Edit > Replace". In "Find What" type " !> ", without the quotations and including the spaces. Then click "Replace All" and save the file. This is optional, copy the file to "JAVAUN.REG". Edit it and delete everything in "JAVAUN.REG", that that isn't in between square brackets "[]"; also leaving REGEDIT4 at the top. Run replace again, this time with "[" in "Find What" and "[-" in "Replace With". Save the file. Now you can copy the "new" files, listed in the Regshot compare, and the two JAVA*REG files to Win98. Make sure you copy things to the same place, as on ME. Finally, double click on JAVAIN.REG. At this point, you should be able to use "Add and Remove Programs" to uninstall Java. But you could delete JAVA's uninstall folder, and just use JAVAUN.REG; deleting the copied files afterwards. A note, you don't need everything in the JAVAIN.REG file. Some keys, especially at the end, are not needed. I imagine you already know this. But I'm adding it for the sake of other readers.

I've been meaning to play around with this. I am doubtful of the results. Thanks for bumping it. I hadn't read that post yet. ---- EDIT: I have messed with this before. I'm sure it should take more then copying registry entries. They won't really matter, between 9x and 2K/XP. You'll more likely just be combing them for settings. But again, there isn't likely much usable in there. I'm also doubtful that the driver memory/IO/Interrupt will matter much, unless you are on 95. When I first looked at this, I was on a 915GM/910L device. The latest Intel drivers for 9x seemed like less of a match. The even older 815M driver gave me more luck. SInce I last looked at all this, I've forgotten the chip lineage. Its probably helpful to know all of the design branching details. This isn't really helpful, but VIA display chips, from that time, use a similar driver design. Both the Intel and VIA chips have a late S3 heritage. Its my opinion, that you'd likely need to do some hex work. !And! there is a chance you could ruin your hardware. Some "light" reverse engineering observations, of both driver installed and working as intended, would help. But even that promises no victory. It just depends on how the chips and code changed. If it did work, its because someone sold something new, with hardly anything new about it. Stop blushing NVIDIA! ---- @sonyu Where you looking for something, in particular, when you found this?

There always seems to be something. Once removed a network card driver and, on reboot, Windows wouldn't load. Turns out the firewall software was tied to it, with its own driver. On another machine, I lose USB if I install Scitech Display Doctor or Scitech Snap Display drivers. If you don't realize the chain of events, right away, it can take a while to figure things out.

@deomsh Thanks for sharing the link. Good stuff. I'll keep poking at it. PKTNDIS seem more likely to work then PDEther. I'll probably try working with a real NDIS2 driver, to first make sure I've wrapped my head around this.

It's worth a shot. It is hard to deny, the issue is machine/environment specific. If this installer supports it, you could have it create a log file: /L C:\<path>setup.log Just add that at the end. Perhaps it would log why it is deciding to do what it is doing.

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.