awkduck

Hope it didn't get on your nerves. I overflow information. I don't know if it is presented well. Every once in a while someone, like Wonderbar98, comes along and turns my overflow into conversation. Its really a wonderful thing. Although, it carried things further from the mark. I guess you gave opportunity for a kind of survey. You provide nice simple opinions, in response to objects when they are introduce to the thread. Maybe that make me a bit troll like. I hope not. But I certainly take to being fed

You are right. And in some cases WINE will even give you better frame rates. But cards without interested devs tend to lose it. Some Via and Ati cards/chipsets for example. I understand that most gamers are gunning for early 2K Nvidia, Radeon, and perhaps Voodoo. But there are cards where the dev efforts are understandably less then stellar. Depending on the level of 3D capability the card has, gaming in WINE may be painful. However, newer cards get great translation to Wined3d. Video cards that are lower tier now, run on an older 2.6 kernel, X, and something like WINE 0.99 or 1 nicely. Like the S3 chips that comes in a Thinkpad T21/T22. I not sure if that same chip is 3D accelerated at all, by modern X. The Riva TNT isn't (1998). I think its the same dev for old Ati, Via, and TNT. I haven't checked for awhile, but one of his road blocks was not meeting the requirement to get some things accepted into mainline. But for one guy he is/was doing pretty good. I apologize that I wasn't I entirely thorough in my description. Oh yes, I know :) I've custom compiled them and packages for them myself. Not that impressive, in the nix/bsd world. Much of this might be beyond the current scope of the OP. Although, I probably haven't provided any Linux advice, that the OP will find more than mildly useful. At some point that would be better on another forum. I do also agree, that the user may be better off using Linux for modern tasks. My small aim was at a simple LiveUSB Linux. One less likely needing much configuration, to accomplish the needed tasks. Hopefully, not sluggishly. Maybe PuppyLinux or EasyOS. My personal slant on the topic, is avoiding adding anything to the harddrive. Especially if it is still a real IDE. But with this particular OP, Linux might not carry much of an interest. A USB stick, providing the machine can boot from one, might be less effort for cause.

Sorry, that I missed the pre-2000 era "hardware" part. Any Linux that would run there, you probably wouldn't like. Not that it couldn't be made pleasant. The crappy thing is that you'd have the same problems. Newer Linux stopped maintaining 3D Acceleration, for older video cards. And older Linux doesn't support the new encryption standards. TinycoreLinux would be a the closest fit, hardware wise. The default Desktop is pretty spartan. But the deal breaker is that accessing applications and settings is nothing near similar to Windows. It is a simple Linux. But far from intuitive, for a beginner. I don't how Slitaz Linux is compiling its 32bit kernel these days. They might be and option. Devuan Linux would work. But the default system configurations (background processes) and desktop might really bog the computer down. But any Linux could be made to look win9x-ish. One ugly example (page down a little). Its been awhile since I've looked into usp3, but I recall the check box menu listing one main upgrade, to install before the rest. However, some list themselves as needing to be install by alone. Meaning no other check boxes should be marked. I would say DougB's post is probably evidence enough, that v3.66 should be avoided by most. For anyone curious, you can just extract v3.66, and then read the install scripts for each thing you wish to install. You can consider the scripts as install advice, and adjust to your needs. Or at the very least, isolate the cause of the update stall/issue.

That DLL should be included in USP3. It is a common add on to the Windows 98 libraries (sorry, if you already knew that). Classic programs like "Media Player Classic (middle versions and onward)" need it. Me presonally, I don't use USP3. When I do, I use it as an archive. I just extract what I want, then manually install it. You can search around and find that some people have even stuck with USP versions in the 2.x series. Regardless, I am glad someone spent the time to release at all. KernelEx is a great project. I've tested it out a few times, but have yet to depend on it. Having tried to "Teach" highly determined Windows users, to get the hang of Linux, I cannot recommend it. But, there is something to be said for overcoming personal limits. It is not my intent to discourage you. But plenty of people understand where you are coming from. I used to have some Windows centric friends, that praised "Peppermint OS". But that was awhile ago, and those users were coming from Win7. I apologize, as the following crosses the border of thread jacking. I've long planned a LiveUSB Linux, that centers on the use of WINE. A real basic linux window manager (Evilwm,Openbox) could host the execution of some Windows Shell, in fullscreen. WINE actually has its own explorer that could be used (ugly). Then a person could install and use Windows applications. Everything exists inside a Windows File Structure, located inside a user folder (/user/.wine/drive_c). Plenty of programs world great with Wine. Games can be a problem. But many work fine. Hardware/System settings become the issue. A person would have to learn how to connect Wifi, safely remove USB storage, etc. My planned solution would be a key combination shortcut, that opens a menu with the handful of required applications/system settings. If I had the time, I would modify WINE's explorer. Then the Linux settings could be exposed via the WINE interface, designed in the familiar likeness of Windows. Alas, this crucial part is beyond my current ambitions. I've seen other people approach the same idea. But I think the last time I looked into it, a more accomplished one failed; because they wanted to charge money for it. But the Linux part itself wouldn't take up that much space. Especially, if someone used something like Slax. Then all the Linux parts are inside a live compressed(fast decompressed) filesystem. Slax would just need to be ran in Persistence mode, to save setting (like wifi and username/password). Or that is one way. The user folder could just be linked to storage somewhere. The whole thing could just be booted and then completely installed to the harddrive. Any Linux people are probably thinking that I am just lazy. Because we all know the basic concept could be accomplished in hours. Apt-get insall this and that, with some Zenity here and there. But hey, I'm busy with Windows 98 right now. EDIT: Well, its been awhile since I've thought about this. I forgot that WINE now incorporates the .lnk shortcut, created when installing a program, into a directory, complying with Linux desktop standards. So a basic "Start Menu" like desktop environment could be used. A nifty "Wine" section shows up in the desktop menu. There all the Installed Windows applications are listed as menu entries. I don't use a desktop environment, so I'm almost ignorant about them; aside from seeing the lnk files being referenced inside a Linux folder.

Ironic. Three years ago I began digging up Win9x/Dos. Right about when Linux started acting more and more like modern Windows/Apple. I admit, it still has a long ways to go. Switched to the BSDs for awhile. They seemed more pleasant to lean out, when compared to something like Archlinux. The future is looking bleak. Anyway, I liked your Linux description. I had written one similar to it, but chickened out and went simple.

On the blog page, for KernelEx, "Retro Systems Revival" makes mention of the prerequisites. A readme distributed along with the release might not be a bad idea. But most are pretty grateful that the release even exists. Some have had stalling problems with 3.66. But that seems to be mostly a Virtual Machine issue. Killing the "old app (I think that is what its called)" process moves things along again. Don't know if that is advisable. To avoid that issue some prefer 3.65. Both come with KernelEx. So it is likely that you will be fine. Just be sure to read the instructions provided by the installer, during execution. You'll see what I mean when you run it. Linux is easy and hard. Good advice and/or research skills (man pages) can get you a long way. Linux is HUGE, its easy to get lost. But it is very flexible. Hence, user created video game console distro's (RetroArch). Smaller live Linux distro's can be easier to start out with.

I've had issues getting certain AC97 hardware to correctly initialize while using the correct WDM drivers. This was on 98FE and SE. Sometimes it seems like later hardware has sloppy backported driver support. Even though the drivers come from the correct OS version folder, the problem seems to resolve when using Rloew's "wdmex". This seems more often the case with FE. So I understand your WinME solution. Just thought I'd throw that out there. Maybe it'll be useful to someone.

It certainly works well, when people can match communication modes. What you describe sounds like a "Project" mentality. The kind of conversing found in a bug report thread. But even then, it helps if people have similar wiring. For example, three replies can give the same answer, but not every reader finds it in each. Way cool!

I wonder if we all do that a little. We attend to the problems of others, from our own experiences. And sometimes our advice may be colored by whatever our current projects are. I have wondered if some people, in the Win9x section, are intentionally sending others on a wild goose chase. Or providing information that leads to a dead end. But, since there are few of us here, I imagine it is more that we want to help one another; even if we don't know enough about the topic(s). It is also possible that personal bias will prevent us from helping someone achieve what we see little point in, or maybe even disagree with. Although, for some of us, we are doing exactly what we were when Win9x was more current. Socializing with "Win9x" dogma and opinions; be it for aiding or arguing. Some of us will probably find a way to keep doing that, right on in to the "Rocking Chair". That seems to be how it works out with any beloved hobby (talking shop). Language barriers can make trouble, but we all use these technologies differently. And that in itself can create another barrier. What may apply to your traditional setup, may make no sense to someone else's. Years ago, coming from a tech position, it was common that I had to help people setup up their machines, for specific needs. Often I configured systems/networks in ways that I would never chose to on my own. I knew they were going to have problems with that setup. But for some reason or another, someone somewhere wanted it that way. And it was my job to give them what they wanted. If you've ever had to help "fix" a family members PC, you probably know what I mean. The issue you resolve can often be caused by something that the owner will keep on doing. Or worse, the issue comes from the exact way they desire the system configured. It can be annoying. That annoyance is our own pride, while claiming we just can't tolerate ignorance. I suppose that's because we are all kings, right? I know this is way off topic, so I'll put a sock in it right here. You guys aren't trying to debug people :)

Retrozilla might work. I think you need to select the SSL option.

There is a very basic program called "Portable Application Creator". I don't know if it ever worked with Win9x. Also "Portable Application Launcher". Interestingly, similar to portable applications is application virtualization, like "Thinstall" (the pre 3 versions supported Win9x).

There was more then one project. Most of them came together as forum projects. Eventually, a few had their own websites. But those are long gone. I can't remember any of their names. There is still "portableapps". They ended Win9x support in 2010. But their tools don't really seem to support the creation of portable applications. They just provide a uniform system for deploying them. I would still do all the things I already do, but just format my package/launcher to their specifications. That isn't very important to me, as of yet. Most of the toolkits were just scripted GUIs, doing what I manually do now. Some were far better then others. There was one that gave you the option to have your registry and changed (portable) files in a hidden folder; named after and located in the same directory as your launcher. But it also provided an option to temporarily load the same data, but then store changes back inside of the launcher file. In both cases the portable application was just one file. There are advantages to both ways. That is how I build them. But it adds some steps in the creation process. Other toolkits often output "portable applications environments" working out of a folder. The main advantage of this method, was that you could view the files like you would in the "Program Files" directory. Also you can overview the portable registry files. It was easier to convert this kind into an actual installed application, if you wished to do so (batch file).

It makes perfect sense. And it makes sense that DosBox would name their project that. But it is still a pain :(

Years ago, I had a handful of ToolKits for making portable apps. As life has progressed, those tools have been lost. Back then I didn't use them much anyway. These days, I often run Win9x from a disk image loaded to ram. But I install programs elsewhere. I can save my settings to the "Live Disk Image" using a couple of different techniques. This saves, the sometimes needed, registry settings. But it is much more practical to create a portable application. In fact, a Live environment is great for that. Right now, I use a bunch of individual tools and notes; collected from various places. It works fine, since I can fine tune each application to it's needs (very hands on). But I was just curious if anyone still had some "Old School" portable application tool kits. This is low urgency. But high curiosity. For the record, this is for personal use and not for the distribution of copyright protected software. In the configuration above, portable applications are obviously a practical solution. In point of fact, this configuration maintains a very clean system registry.

I did notice that some (like 915.inf @ ICH6/win98se) are sparse, like you have said. But others do have registry entries, for configuring drivers (like ich4core.inf @ ICH4/win98se). Some specific windows files are specified for use. But perhaps windows already installed the same. I suspect that is what it ich4core.inf is doing with APM. It removes the driver and only (re)installs it if it is detected/verified. I would guess that most of these drivers work fine "as is" most of the time. Sometimes, settings other than the default may need to be used. As for when the inf files specifies using certain Windows' drivers, for all I know they are the same that Windows would have specified. It does list files to remove, that it does not reinstall. So in some cases it may be anticipated that incorrect files may have been installed or are not needed.

I agree that it is not a driver. I suppose writing "after other drivers" suggested thinking it was. I have had a video driver not work, until the chipset was installed. Windows would boot to a black screen, unless you installed the chipset before the video driver. While researching the issue today, I found instances similar to my own. Sometimes it was related to APCI problems, rather than video. I don't know if VIA chipset installations are different. But I have also had the above video driver issue with Via. With this machine, windows assigned the AGP port as a PCI device. The chipset inf files resulted in it being recognized as an Functional AGP port. No actual driver files of any kind where copied over. But for what ever reason, the video driver worked afterwards. Perhaps there is some brief specification information installed with the chipset? Or associating vendor/hardware IDs with already existing windows drivers, that otherwise may not have been associated?

The "Intel Chipset" is meant to be installed right after a fresh install. I was looking into the issue of installing the "Intel Chipset", after other drivers have been setup (Windows default and third party). I haven't tried it myself, yet, but it seems the "-OVER All" flag might do the trick. Example, "Setup.exe -OVER ALL". This should work with the "infinst_enu.exe" file, but you may have to use the "-A" flag first. Example, "infinst_enu.exe -A -OVER ALL". Otherwise, you can just use 7zip to extract the contents of the self-extracting executable (infinit_enu.exe), then run Setup.exe directly. Supposedly, "infinst_enu.exe -A -A (optional -P [output directory])" will self extract without running setup. Without the optional "-P" flag, the contents should extract to "C:\Program Files\Intel\Infinst". I wonder if this would help with Windows installs ran without the "Setup.exe /p i" switch? Would it correct ACPI issues? As a side curiosity, I have wondered if installing the "Intel Chipset", enumerates pci devices not listed in device manager; on machines where using "Setup.exe /p i" did not do so. I'm sure I will find out soon. Other drivers might need to be re-installed, to correct issues from the chipset having not been previously installed correctly. Anyway, a complete list of "Intel Chipset" install flags is located in the "readme.txt", found with the chipset installer (compressed inside infinst_enu.exe). Anyone have experience with this?

One day I'll dig my hands into those features So much to do, so little time.

Actually, that has been a real annoyance for me. Its been called a "dos box" for awhile. When researching Windows internals (Win3x-9x) many books do refer to it as a dos box. It can make using google almost pointless, as DosBox/DosBox-X will return in most of the results. It makes trying to understand what happens when you run command.com very obscure. This since command.com is ran inside the dos box, not the actual dos box itself. I guess there is a ReactOS cmd.exe, for Win9x, that initializes a similar environment. Reading the source code for that might give me some clues. I have so many projects, that I haven't continued to research it. Looking to get three books, Undocumented Dos/Windows and Unauthorized Windows 95. Maybe they'll give greater detail. But, in this case, it is the win32 side of things I'm interested in. The same problems you had when running shell replacements?

Which driver? VGA 16 Colors? It probably does not matter, but could you type mem at the command prompt? Then tell me how much free conventional ram you have.

jaclaz, thanks for the excellent reading material. Lots of good energy in those posts!

I haven't used BB4Win much. But LiteStep never caused me any issue. There are other shell replacements I've tried, that had many issues. But I imagine if a person's Windows configuration relies heavy on explorer, they would be much happier using the explorer shell. I run a pretty lean install. Long ago, I used to run with Program Manager as my Win98/XP shell. With XP I had to save the XP original progman.exe file, since SP1 replaced it with a non working version. But I had no systray, when using Program Manager. I found something called "Rocket Tray". Or I think that was it's name. But Litestep had it's own systray and on the whole was quite light. But none the less, your XP like start menu, with the MS-Dos Prompt, deceptively looks like an improved version of XP Or maybe not so deceptively

You might have better luck with the newer versions. It could also be that there was an error installing the driver. VGA 16 colors is the default VGA driver that Windows reverts to, when there is a problem. Since VBEMP supports 32bit color, I would suspect the driver is not compatible or did not install correctly. But even the windows VGA16 driver may be enough to tell if the issues is your ATI driver. Wolf/Sod should still work, even if only 16 colors. Remember, VBEMP and VGA16 is not meant as a fix. Just a test to determine if the ATI driver is the issue. If you get the same blackscreen with VBEMP/VGA16, then you know the ATI driver is likely "NOT" the issue; since the black screen affects all video drivers. Not as far as I know. But I am glad you have sound.

If someone could write a more "hardware direct" and "non CPU emulated" win32 dosbox, then HxDos 2.17+ (Ruslan Starodubov) would be a possible option. It would be a nice project, without the interest of using it with HxDos 2.17+. Just not architecture portable.

Joaquim, wolf4gw does not always automatically enable sound, when detected. You need to change the settings in the "Game's" sound options. If soundblaster is not detected, you may not be running VDMSound correctly. Some "Extra" notes on VMDSound: 1. From the "Same" commandline window that you run "dosdrv.bat", you need to change directory to where you have "wolf4gw.exe". Then run wolf4gw. Otherwise soundblaster may not be detected. 2. You can unload VDMSound by running vxdsboom.exe. 3. The "Tip of the Day" error, when running dosdrv.bat, can be fixed in the registry. REGEDIT4 [HKEY_CURRENT_USER\Software\Freeware\VDMSound] "NextTip"=dword:00000000 "TipsFile"="C:\\Program Files\\VDMSound\\VDMSound.tips" "ShowTips"=dword:00000000 You can either create a .reg file with the above in it (and double click it), or add the contents manually with regedit. 4. The reason wolf4gw may be working for you, may have to do with conventional memory. Original Wolf3d and Wolfdosmpu both require that you have enough conventional memory. Wolf4gw does not. I believe wolf4gw also supports vesa modes, that the original Wolf3d does not. This is more likely the reason it works for you. If VBEMP fixes the black screen issue, with the original Wolf3d, then your ATI driver may not be supporting the needed modes. I think someone has mentioned that to you before, in another thread. An older or newer ATI driver may fix that issue, since VBEMP does not support "3D Acceleration".