awkduck

Read about this a while back, regarding beta releases. Nice to see 95 still getting some play. One day, 95 may even see USB2.0 support.

Anyone know if there is a drive/application that can do this? I'm looking to mount it as a device letter. I know Qemu can run with a disk image, while you copy files over a shared FTP folder. Also, DosBox can mount a hard disk image, and a shared folder as a virtual drive. Files could be copied that way. WinImage allows inserting and extracting files, from a disk image. I could also use Grub4Dos and mount the image as a secondary drive. Is there a better "native" way?

Don't mind me, I'm just jesting about extremes. I have a fondness for static (or near static) applications. That is one of the things making "GO" (static friendly) an interesting programing language. Or tools like FreePascal/Lazarus (very portable) appealing. Sometimes, in some tech corners, you get criticized for reinventing the wheel. But back in the Dos days, static building was much more normal. Then again, Dos didn't provide you much to build off of. There wasn't a library folder anywhere. Not that you couldn't do that. But if you built things with less dependencies, especially O.S. dependencies, it would be harder to control the product life cycle. Just did a post mentioning it. Great tool. Absolutely, you can. Some installers hash themselves, checking for changes. But I doubt that is the case here.

Probably the easiest way :) With some guru tools, you could watch how everything interacts during execution. Depending on the day, that might be a bit too far :) Like running the system in a VM, stepping through and noting every interation/opcode. Would be interesting, if it was Norton Utilities.

First off, this is not a post about writing a grub.cfg file, or booting Win9x using Grub2. I don't mind if it turns into that. But "initially" this is just about installing grub, from Win9x. And it is only in regards to BIOS booting systems. Grub2 has installation files, for Windows. They will run under win9x, but only seem to accept NT physical drive designations. That can make installing it a little rough. Maybe there is some option included, that provides the needed functionality. But it wasn't in the user manual, nor did anything turn up online. There are many bootloaders and Grub2 forks out there. It might be possible to use one of those, quite easily, using only Win9x. I use Grub2/Grub4Dos/Syslinux, individually and in combination, all the time. There are just times, when Grub2 works well for me. So don't read this as a "You should use Grub2" post. It isn't always the most flexible bootloader, when you are working with Win9x. If you are familiar with Linux, or you have a Window NT variant, you probably don't need this information. This is for the real masochists out their, that want to do everything within their Win9x domain. Also, if you haven't messed with a hex editor, or your systems is to important to risk its functionality, you probably shouldn't mess with this. Disclosure: There may be a different, and perhaps official, way of doing this. I just gave up looking. Turns out, installing it "this way" is easier then writing the grub.cfg file by hand; which you would also need to do. First you need to download Grub2 for Windows. Then you need a handy "Disk Viewing" hex editor (maybe). I used the HxD hex editor. There are Two ways you can go about this. -If you already have a bootloader, you might just want to chainload Grub2. This would not require a hex editor; so you can leave manually editing you harddrive alone. -If Grub2 will be your main bootloader, then you will need to chisel and hammer some. No matter which way you go, you need the Grub core.img file. So lets build one. Once you have your Grub download unzipped, you'll see a bunch of "EXE" files. You can get rid of all but maybe one or two. For certain you need "grub-mkimage.exe". But if you already have a "syslinux.cfg" file, you can play with "grub-syslinux2cfg.exe". I won't be doing anything with that, here. There are also a couple of folders you can get rid of. Both "i386-efi" and "x86_64-efi" are not needed. Now, in this same folder, you want to run this command: grub-mkimage.exe --output=./core.img --format=i386-pc --prefix=(hd0,msdos1)/boot/grub biosdisk part_msdos fat Note: This command can also be ran in real Dos, but you need "long file name" support and "HxDos" extender loaded. Now "(hd0,msdos1)/boot/grub" represents the location of the folder you just ran that command in. So you will want to rename it "grub", and then create a folder "C:\boot" to move it to. But you will have to adjust things, if you want to have this folder somewhere other then "C:". If it is on a USB drive, (hd0,msdos1) is still fine. When booting from it, BIOS sees it as the first disk. If you are chainloading, then just use "/boot/grub". So in hdx, x equals the physical disk the grub folder is on. In msdosx, x equals the partition it is on. If you want to have it on a partition that isn't "Fat16/32", then you would want to change out "fat" for the correct partition type. For example ntfs, ext2, exfat, jfs, etc. "Ext2" also handles "Ext3". These names correspond to modules in the "/boot/grub/i386-pc" folder. So if there isn't a .mod file for the partition type you need, then it isn't supported. You don't need support for all of these partition types, in core.img. You just need the one for the partition that "/boot/grub" is on. Once Grub boots, and locates that folder, it can access the other mod files. Now, if you want to chainload Grub, then you need one more thing added to "core.img". Inside the Grub folder, you would run: copy /b i386-pc\lnxboot.img + core.img boot.img If you are chainloading, you could delete core.img and/or rename boot.img to core.img. It doesn't really matter what it is called. That is pretty much it, for the chainloaders. Just create your grub.cfg file, in "/boot/grub", and point your other bootloader at "boot.img". But you real masochists, keep on. If you are going to format the entire drive, you can copy the whole Grub "MBR" over before hand. But if you already have "needed" information/partitions on the disk, then you'll need to take more care. And you can throw in the towel right now, if don't have 28KBs free, after then end of your first sector. A standard MsDos MBR should be fine. Modern Linux made partition have even more space in there. Okay, so now you will need to start your hex editor, and open your target disk. Then open the file "\boot\grub\i386-pc\boot.img". Like I mentioned earlier, if you plan to format the entire drive, just copy the entire contents of "boot.img" and paste it on your drive; starting at 0x0. But if you already have data/partitions you want to preserve, then you may want to copy the whole fist sector of you disk; and save it somewhere other than this disk. Then you will only want to copy "boot.img" from 0x0 to the end of 01A3 (01A0x3). Now paste that to your drive at 0x0. Note: If things don't work out, you can copy/paste over your "saved" original first sector. Finally, if you have enough room for it, you can open/copy the entire "core.img", and paste it at the very beginning of your drives second sector. That should be it. Now with a good grub.cfg file in "\boot\grub" you should be all set. If you are unsure about any of this, maybe try it on an empty "USB" pendrive.

If you go far enough, then you'd have to deal with all the different hardware variations. The JAVA, write once and run everywhere, idea was cool. But I'd hate to use a modern web browser, written in JAVA. Eventually, most people's idea of an OS will interface through a scripted client/server GUI environment. Our devices will be nothing but kiosks. Getting a new OS, will be upgrading your "OS as a Service" package. So, ironically, well be hoping our kiosk-ish devices are compatible with the service. A reversal. Needing the right browser, to access your OS; rather then the right OS to use access your browser. Note: A kiosk does have an OS. But in this situation, its more akin to soft firmware. This is the only way a Metaverse could work. You can't fluidly go from device to device, each one loading everything up. Nor would you want to walk around, with augmented glasses etc., connected to some large GPU/CPU and storage media. From your bathroom > living room > sidewalk > car, the stream is just re-initiated where you left off. Until B.C.I.s become popular. Then it would be just one stream, that follows you around. I'm not looking forward to it, but one day it will be difficult connecting these devices/OSs to the Internet. Perhaps illegal. A device with user guided processing, on this side of the cloud, may be considered insecure. You can imagine, it would much easier to secure the Internet/Metaverse "from bad actors" if everyone only has direct access to the input side of things. We are nearing that, with smart phones. They are powerful computers, with well curated portals to apply that power. The browsers we know, will be (are being) reinvented between retro group hobbyists. Kinda like how the 8/16bit retro scene still comes out with new browsers. Hackaday has a retro webpage, for old machines on the Internet. That's gonna be us one day :) Sooner, if you've went to check that link, in your Win9x browser.

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.