awkduck

Seems there is some, progressive, work on a Dos SoundBlaster emulator (real/protected). This is what the SBEMU project page says: There are more recent, beta files, found on a well know legacy computing forum. Github seem to have an early release. I don't see this being useful to Win9x. But it'll probably be useful to people, who use Win9x

I also choose 98fe. 95 is very appealing. Too many things make 98fe more useful, for me.

I have had problems, using HxD, to save RAM images over 350Mb. When using Grub4dos, the error is "Stream Read Error". With Grub2/Memdisk(from Syslinux), there is no error. But when you boot the saved image, there is filesystem corruption. I'm not entirely sure it is the size of the image, causing the problem. It could be specific machines. I haven't investigated it very much. A work around is a Dos USB/Fat32 drive and Partition Saving. This won't work, if the available Dos USB drivers don't work for your machine. There are some good Dos USB drivers out there. But even the "demo" Dosusb drivers operate long enough, to do a back-up. Note:These drivers don't work with "EMM386". The other problem, is that Partition saving adds a very small header. It needs to be cut off, after saving. If your machine has no PS2 keyboard support, you may have to add a batch file to "C:\Windows\Dosstart.bat". "Partition Saving" can be automated through a configuration file. Then you just exit to Dos, and your batch handles it for you. Note:If you have prevented Windows from installing a Driver, for a specific USB, your BIOS PS2 Emulation may still work.

Its nothing to severe, long term. Sometimes only a few hours. But it has prevented me from engaging employment, in remote administration. Such is the way of things. I've had many harddrive failures, in the last few years. That is part of what has taken me so long, in setting up a development environment. Add to it, that I am fickle at system crafting. The aim is redundant safe saves and quick machine portability. Years ago, I had a several year project zeroed on me. Ironically, it was in Java. It can really be discouraging. It has happened often enough, that I've learn to just let it go. However, once in a while, it was for the better. I have messed with many different languages and operating systems. Not many scripted languages. I don't care for Lisp, but ironically love Scheme; this causes me to admire ML. I like ASM, the simplicity of complexity. Most high level languages, seem like the complexity of simplicity; for the sake of organization/business. On the outside, Forth looks great; but I have yet to investigate it. The moving target of progression, has always seemed poorly implemented. Not having a career agenda, has greatly liberated my scope. When the 286/386 were in main use, and the 486 in fresh vogue, I really only used C and Batch. I was so out of the loop, I had never even known about Pascal. I knew about GWBasic, but never bothered to check it out. I was pretty young. While I find assembly a focus, I would not be the guy to address a wide range of processors. I initially set out targeting the NEC 186 V-chip. Even now, I find the Next186 pretty tempting. So I might get to learn all about these differences you've mentioned. Thanks, for sharing some of your history. I enjoyed it.

Your O.S. of choice?

I'm a bit late, back to the thread. I watch an elderly woman, about every other week. When I am there, I don't do tech. Simply because, I get too drawn in. Sometimes, she only gives subtle hints of her needs. Great tip! I (too?) will look into the various sources mentioned. Old stuff is getting hard to find, but I'll try hunting for Ramdisk98 source. I'm not entirely opposed to buying a copy of Walter Oney's book/CD (about $6). There are a couple of other books, along the same line, I am looking to snag anyway.

Maybe it was in the Nero installer? Well, it is a direction. Static builds are the very portable, within a O.S. type. I can use new static GO builds, in old Linux distributions. With GCC C/C++, it would often require that the Linux kernel and Glibc be more up-to-date. And with win32, it will also depend on what libraries you build on. But you already knew that part. There are other options, too. BlackBox Component Builder, provides something similar(ish) to Java/VB. You can run it on different OS versions and Platforms. I would think the overhead would less, then say Java. However, it has a less mature availability of libraries. But it offers rapid-application-development. There are some different "Small Talk (modern example)", rapid-application-development, projects. But I'm not sure if there is one, that bridges between many systems. I mentioned "FreePascal/Lazarus", as there has been some work on win16 and Dos compatibility. Win9x has been depreciated. But, if there was enough interest, it could be re-ignited. If Win9x was brought, more into vogue, it would make FreePascal more interesting. Lazarus, is the rapid-application-development side of things. If Win9x support was re-upped, in FreePascal, Lazarus would also need updated. But there are alternative environments, to Lazarus, for FreePascal. They rely on the leaner Win/GDI and *nix/X11. MseGUI/IDE and fpGUI are the notable ones. Note: It might be more likely, that the alternative GUI environments, would consider support for older systems. While they have a smaller development crew, they also have less dependency entanglement. It is also noteworthy, that they could just build in support for older versions of FreePascal; the ones that support Win9x. One could use older versions of FreePascal/development environments, and then minimally port their own code to the new compilers. Also, many older compilers support newer systems. For the masochists, like me, there is FASM. It can have good O.S. portability. But is harder to bridge between architecture types. Writing something "like a modern web browser" in this, would be daunting. But, no doubt, many people would praise your skill/insanity. Fresh IDE, is a rapid-application-development environment for FASM. You can imagine, that work on this takes time. But the project could provide useful, if you are looking to use assembly. More specific to web-browsing, there was an interesting project called "Hv3". It has 12/13 years, since it was last developed. But, might provide interesting study, for someone looking to build a web browser. This one would be "somewhat" useful, as is, if it just had modern encryption support. But Fifth, is more relevant. It is FLTK3/Webkitfltk based. Obviously, this would require some Win9x back-porting. But it might be less dependency bound, than other options. The least compatible GCC compiler is 4.7.3. That means there is "potential" for MinGW/TDM and Win9x. I am "near" ready, on my own "Win9x" production environment. Hence, less knowledgeable regarding Win9x development. I'm only partially focused there, anyway. Please forgive, I'm having a histamine attack today (Mast Cell Activation Syndrome). Concentration is harder. If my reply is confusing, it is probably due to my brain fog.

Excellent.

Actually, this is the reason for the OP. I'm kinda spoiled, and don't want to reboot. Depending on how much was already present, in Walter Onely's book, I had thought about it. I like systems programming; just maybe not Windows 95/98 systems programming (or any modern system). Time is always an issue. In spare time, if it took half a year, I would probably not have ambition for it. A couple months, of poking around to completion, and yeah. But anything more than that, and I'd rather work on a project that solved more problems. That's for another post. :) Yes, that has crossed my mind. I did end up getting RamDrive98 to mount/unmount, without a reboot. The project, I am working on now, can use "Fat16"; requiring, a maximum of, half a Gigabyte. So this will work, for now. The main issue has been file permissions. Many alternatives would require manually setting file permissions, after injecting files into the image. And there are a number of files, where the permissions are important. I really doubt anyone will follow, using this method. But the Internet is big. If you do, pay close attention to the data, "right" after the end of the partition's first sector. Those few blocks may not match, between the two. You can probably leave them, as they are, for each image. In the raw disk image, search for "fat16"; also sector 63, depending on your editor. The size of the partitions need to match. This limits the usefulness. As I am creating the raw image " blank", this works fine for me. I can just match RamDrive98's partition size, by messing around with Qemu's "qemu-img.exe".

Some people have reported problems with 3.66, on virtual machines. When I tested it "Win old app" needed to be killed, in "Task Manager", to continue from an installation stall. The installation continued, but I never investigated for install errors. Some have said 3.65 didn't have the issue. Some said 3.66 worked fine, after using 3.65. You can read all about it, starting in the last handful of pages. You can extract the update contents, and read the install scripts. Seems like the installation is the problem, not the content. You could just install things a piece at a time, when possible. Then when/if something goes wrong, you can read the script and do it manually. But it really depends on what you need the update(s) for. For example, if you are trying to resolve a specific issue.

Yes. Here it is. You can make static builds with other languages. It can be a pain. But I've found Go impressive. I don't remember were, and a quick search didn't turn it up, but I think someone ported Go to dos once (protected/extended mode). Hm? I used Ghex2 and couldn't find the string GET_UPDATE.

SoftICE comes to mind. The Bochs Emulator. IDA(pro).

@jaclaz Thanks for the tip! I have something working. But it isn't ideal, or a solution for large hard disk images. I downloaded RamDisk98, from one of the many Simtel FTP clones. If my disk image has the same partition size, as the RamDisk98 saved partition image, I can use HxD to copy the data between the two. So the image size is limited by the amount of free ram you have. You need enough ram, left over, for HxD's copying in order to paste. So it's better to save the ram image, then operate "afterwards" without the ram disk. For me, the ram disk does not start and stop, as described in the readme. Edit: now works Mapping a disk image, with Grub4Dos, is still easier. I'll install Paragon's Harddisk Manager 6, to see it I can do something similar with the included Image Mounter. They have a header, on there created disk images. As long as the image is not compressed or encrypted, it saves it raw. But this would only work for people with this software. Update: Image mounter couldn't unmount Paragon's own images correctly; the changes were not saved. It seems like a Win98 compatibility issue. Otherwise, it seems as if it would have worked. Mounted images, that had been modified by raw disk image partition data, displayed contents of the original raw partition. Alternatively, the "README.TXT" included with RamDisk98 say: If there is enough usable code, in there, maybe something could be (re)written for a ram or file image.

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.