awkduck

Good luck. Hope everything works out.

I believe that is correct. It is my understanding that this patch could potentially make things worse, or "at best" not really make a difference. But I can't claim, with 100% certainty, that it won't help; instead with just an awful lot of certainty.

From private messages, I was able to tell Joaquim is referring to rloew's "Win9x 512Mb Nvidia patch". I believe there may be another patch, someone could be referring to. One specific to updating video device bios/firmware so that cards not compatible with the Win9x drivers (at all/hardware too new) could possibly work. This patch (rloew's) is extremely unlikely to help with the "black out" issues. It is a 2 path option patch. (1) driver patch - patches the driver limiting it to the use of 256Mb of video ram; thus preventing issues when the driver attempts to use beyond the 265Mb reported by the hardware. (2) hardware patch - updates the video device bios/firmware to report to the driver the full 512Mb of video ram, to the driver; thus preventing the driver's attempt at writing to the later 256Mb of ram, that isn't correctly allocated. !!!!Note: I may be getting the technical explanations of this patch incorrect, but I only gave the patch manual a brief skim. I think my description is near enough to express why this patch shouldn't change the "black out" issue. By all means, improve my description; I welcome the corrections. I would highly discourage updating the bios, unless you were sure it solved whatever issue was believed to be solved by doing so. As for patching the driver, sure. I doubt it will help. But in the spirit of desperation, I understand. These are the directions, as provided in the patch manual.

Joaquim, I don't think "anyone" has gotten regular drivers for HDA to work on Win9x(95,98,ME). The only driver with support, that I know of, is Walters Driver. You could use a USB audio adapter. Windows has built in drivers for that.

Which devices have the conflicts? Did disabling acceleration stop the black outs? There is a possibility an updated DirectX could help. I've had no experience with the specific drivers you are using. So, I can't speak to the probability of this being the issue. Unless you prefer not updating it, you could try and let us know the results. You audio device seems to be a Realtek HD Audio. It can be a bit of a struggle getting those to work. Deomsh does some work with Walter's HDA audio driver. There are several threads here, where you can examine the process of getting it to work. It may work right away. Did you search for more information on the video patching? There are some discussions here, about it.

Okay, so this is completely different. I've had some "edge of support" drivers do what you have described, due to poor DirectX backwards compatibility. You could disable video acceleration, and test if the black outs still happen. If they stop happening, then it could be a DirectX issue. It should be noted, that a video driver can work perfect on one machine and then malfunction on another (same/similar video hardware). Especially, if it is an integrated video device (laptop). Are there any conflicts listed in device manager? Is there anything not installed in device manager? This may be a less likely issue, but I've had a few Nvidia chips behave this way, before they kicked the bucket. Probably nothing, but be weary if the machine is running hot. If it is hot, maybe examine your configuration and see if you are in need of a CPU idler (Rain/Waterfall/CPUidle). In laptops the heatsink for the GPU is often on the same heat rail as the CPU. Might be good to make sure the fan area is free of dust. Also, if it is hot/warm, avoid using the device in warmer rooms. Like I said before, this may have nothing to do with your issue. Just mentioning it as a precaution. But if the thermal grease hasn't been replaced, keep temperature in mind. Most of my older ATI/Nvidia featured laptops, eventually die related to the GPU. Could be due to poor upkeep, on my part, or poor cooling designs.

It is kinda neat. I just wish someone like DM&P would put out a legacy device. Their CPU packages/SOCs still include ISA etc. They could make a laptop, with the potential to include or add old SBlaster/Adlib support of some kind (includes AC97 or HDA, i think?). If I had the time, I would try to order one of their chips and build one myself. They are plenty fast enough for even some modern tasks. I think they do have a bottle neck in the bus, but it wouldn't bother Dos or Win3/9x much. Their MiniPCs, on ICOP eshop, are fanless. You would just have to slow it down, to run the older Dos games. I guess I don't know how well their included video supports all dos modes. I doubt it has much in the way of video acceleration. But with PCI and ISA support, you could build a laptop with one PCI and one ISA slot. The laptop chassis would just need to have connecters for the audio and video, included in the isa/pci card bays. It's a pipe dream, but lets see what the universe does.

Hi @Joaquim, I was curious about when, or what happens, that causes your black screen. I remember some time ago, you had tried using the s-video out of your laptop. The issue back then was that the s-video out did not support the graphics mode attempted (a Dos or a DirectX game [can't remember which it was]). It was a documented limit, even with the right drivers (a win9x limit, if I remember correct). It has been a while, but I think it was that s-video did not support DirectX. Maybe also that some Dos games were picky about fullscreen output, over s-video. Is this something similar; does it involve a fullscreen command prompt or the s-video out?

@jumper Yeah, that is pretty low.

Which resources? I know you don't mean ram. There are greater limitations, if you are not in 386 enhanced mode. I also remember that having virtual memory enabled, limited you to 512mb of memory. When that is disable, I could see the machine's 1.5Gb (alternative Dos Memory managers). Not that Windows could actually use it. I've read that 256mb was the maximum managed (actively used) before the memory manager would become unstable. But applications like Adobe Premiere (v1.1) required 8mb of ram. And I certainly have ran more then one application, of such demands, simultaneously (cooperative multitasking). But, I do recall the Graphical Display resources being an issue. Also, I think there was an issue with allocating over 64mb of ram (similar issue [but not the same] with DrDos7 multitasking). It would be neat to have a 32bit Dos multi-tasker (like WfW[32bit]). Something like Dosemu, but instead on Dos, using Dos Drivers. Japheth (HxDos) has done excellent work for Dos. It would be interesting to have preemptively managed Dos VMs, supporting environments like Japheth's extender. It could be a hobbyist nerd's playground. Sbemu and VSBHDA are slowly approaching the potential, for forking into an "A.L.S.A. for Dos". It might prove nice targeting a modern(ish) browser, towards an open sourced environment like this. Especially, since HxDos has implemented some of the Win32 environment. If one designed the UI correctly, HxHos is not a Window Manager (no floating Windows), you could implement or port a browser to HxDos' Win32 environment. With VSBHDA, you might even have audio. There is even, now, Javascript for Dos; not that it could be used "well" in a Dos WebBrowser.

I've heard rumor of FreePascal/Lazarus having a Win16 target. This doesn't mean it would be easy, but it is one option.

@SweetLow Excellent work! I've been intending to write something like this, myself. I may still take a whack at it, for the educational result of the challenge. But, who knows how long it would have taken me to start? I'm spread too thin, lately. Looking forward to taking your work for a test drive. You've done some neat things. But this one is an attention grabber. Would have tried it sooner, but my main browser is terrible, on github. Seems that a lot of the things you work on, have been things I've see people discus a desire for (at the usual Win9x places).

There are some I have been meaning to test (with KernelEx). SSuite Office Personal Kingsoft Office Suite Free Softmaker Office The newest versions will most likely not work. I wish I could give you some version numbers and links (probably archine.org links or something). I'm pretty sure I've had the best luck with Softmaker Office.

Flesh this out a little bit more. Is this a old Windows install (harddrive transfer, from different computer), or a new fresh install? Does fully updated mean unofficial service packs, or a personal collection of updates? Have you installed USB Drivers, prior to the chipset? LoneCrusader has a unofficial Intel chipset, for newer machines.

I've never tried it, but the "PC-Dos Viewer" looks like Pc-Dos' version of a help/information tool. Maybe try it out.

I have to apologize, jumper. On my part, the thread has become a little muddy. loblo was correct. The orphaned folder should have still been accessible (and was), to the application that created it. It just didn't appear to me that it was. I made a poor assumption, about why the application could not insert the key into the setting file (stored in the orphaned folder), or read the key from it. I used the WinME SHELL32.DLL and SHLWAPI.DLL (and a handful of other files) to test, if the folder "being created/accessed correctly" would solve the issue. But that was just a temporary experiment. I tested on WinME first, and the folder was not orphaned; but I couldn't get the application to run (no test of key file functionality). The application not being able to run, was probably just a problem of me having no real experience using/updating WinME with KernelEx (the Working KernelEx settings from Win98FE were not enough). I'm pretty sure the ME install was completely original, with no system updates. I didn't really want to update WinME, for this simple test. So, the WinME files where used, on Win98FE, to test what I could not test on WinME. The issue is the application failing to process the key, in or out of the setting file, even while having access to the proper CSIDL (provided by ME files). I didn't have an issue with the fact that ME files would be unstable, on Win98FE. I knew this from having played with Win98SE files, on Win98FE. I just needed the CSIDL functionality long enough, to see if it fixed the problem. It did fix the orphaned folder issue, but not the overall issue. While it would be nice to have extended CSIDL support, I can handle not having it. Again, I just wrongly assumed the missing CSIDL was the cause of the issue. Also, if I've misunderstood something, as I sometimes do, I'd gladly eat some words.

I get it. We all have to problem solve, in a way that makes sense to us. I do apologize, that I couldn't help more. I know I have used the service pack 3, without the issue you've described. I wish I could remember more, about the one time I had ran into an issue. I suppose, I do things more in a revision history kinda way. For example, "what change broke things?". But it isn't a direct "fix this specific machine approach", but rather a "fix the cause approach". But the direct "fix this machine approach" will find the answer to the cause, just as well. I'll keep my eyes on the thread, and see if I can help in anyway. I don't think the following will help, but its just something I ran into, from the SP3 site. That's the option with the "(98lite Users Only)" tag. I didn't see your issue anywhere in the service pack forum, but I did not read it from cover to cover. It is possible you could find a clue there. You may have already looked. Also, there is a list (and links), for service pack releases, on the first post.

This is good advice. But I don't actually want IE at all (it has been removed from the system). Just the files needed, to satisfy system and application dependencies. That is why I extracted the needed files. However, to concur with jumper, most people should probably always install.

@ruthan I should add, if you are just looking to solve this a little faster and be done with it, you could look at some of the older service packs. As far as collected official updates, many older versions still contain them all. So if an older service pack did not cause this issue, you could use it and then cherry pick the things you wanted from SP3 (providing it is not the thing causing the issue). Then you would have a way to duplicate a successful update, without the issue.

I'm still wondering which version of SP3. For example 3.65 or 3.66. But... I think I may have noticed something similar to this, once before. It almost seemed like the system needed to revert first (uninstall the updates), reconfigure the network with the needed change, and then re-install the updates. This was just a passing thought I had once, when dealing with a Win98SE system (post SP3.66 update). I can't remember the exact issue; but I vaguely remember it seeming like the files needed could not be installed (original cab files), because their reference had been lost. However, it could have very well been, that some new file(s) were preventing other components from functioning correctly. I didn't mess with Win98SE for very long, so my memory is fuzzy on it. If it was original files not being referenced, in the update's newer system and or .INF files, then one might be able to examine pre-update system INFs for the missing references. But I'm not entirely sure the INFs control everything. Sometimes, when installing a driver, it looks for files that the INF says it needs. However, depending on the version of that/those file, the following files called for (through out the rest of the installation) may be different. It must be detected linked dependencies that are being requested? So there is a chance that newer system files are not linked to older system files, needed for system reconfiguration. Or some near variation of that last sentence. It could just be some other trigger that doesn't get called. It would still help to know which update option was causing it. It's probably the "Main Updates/System Core Files" option. Another questions, do you get any errors or strange behavior, while installing the update? Are you saying you copy the "broken" install over to a new system and the issue is still present; or that you are overwriting the broken install, with a working install, and the issue is still present. I think you are saying the first, and that would make sense; since nothing, with the core system, has really changed. I can't remember, does SP3 have an uninstall option? If it does, can you test that? Can you back up one of your working VMs and test if just the "Main Updates/System Core Files" option causes your/the issue? It would be nice to know, if focusing on just that one update is enough.

What version of the Unofficial SP3 are you using? What Update options are your selecting? I couldn't make out for sure, if you had ever had a machine with working networking after the update. It seemed like it was only some machines that had the issue. If that is true, of the machines that do have the issue, do they always have the issue (after the SP3 install); or is it erratic? You can copy the service pack to a temporary folder, and extract it with 7-zip. "INFEX.INI" is the core of the service pack. You can examine it to get a grasp of the over all process. But for individual updates, you need to examine the ".INF" file, that correlates to the update. Also, you may need to examine the correlating ".BAT" files. This will tell you what files are being replaced, and what registry settings are being added/changed. The file you probably want is "SPUPDATE.INF", unless you are also installing Internet Connection Sharing "ICS.INF". You could try a fresh install, just installing "Main Updates/System Core Files (SPUPDATE.INF)". If you end up with the same networking issue as before, you could then eliminate, for certain, all the other "less likely" causes. If "Main Updates/System Core Files" isn't causing the issue, then you can "one by one" install each update (that you normally use from the service pack) until you find the one that creates the error. Unfortunately, you are the only one that can debug this, unless it is duplicated somewhere else. After each change you make, to the new install, restart and test the network. The you can at least isolate, to some degree of certainty, that it is the service pack (and a specific update) causing your issue.

Yes, I've extracted it from both explorer versions (5.5 and 6.0). Shell32.dll, from ME, isn't happy with either. You get the nice white box message and grey ok button, about needing to reinstall Windows. There are two Shlwapi.dll files included with both IE versions. I've never gotten the one intended for Win98SE (and ME) to work for me (without errors). The other one, I think, is meant for Win95 and Win98FE. It's the one dependency walker says I support. Likewise, I can't use the one that comes stock from Win98SE (without errors). So when I say Shell32.dll (from ME) isn't happy with either, I means that it isn't happy unless it is a Shlwapi.dll version that isn't fully compatible with my system.

So with Tracktion 3, the issue goes beyond shell32. Oh, well. But, the orphaned "Application Data/Program Data" was fixed. For Win98SE, a person can just use the shell update, from 98SE2ME. I'm on Win98FE, so I only did this temporarily. The most updated Win98FE shlwapi.dll isn't new enough for ME's shell32.dll. But I can used ME's shlwapi.dll, just long enough to test things (it would eventually cause errors). I admit, I don't know 100% what you can get away with here. On Win98SE, you may have to update beyond just ME's shell, for stable operation. Sadly, Tracktion 3 did not accept or reject it's key file. I manually edited the settings file, with the key file data. The application recognized the registration name/email, but it cannot process the key string. I may end up looking at things in Olly or something. I have Tracktion 2 to cross examine with; it has a similar "key string/key file" activation and works fine. That's a different topic, for a different forum.

With no alterations, WinME installation places the "settings" file in "C:\Windows\All Users\Application Data\Tracktion 3". There was no orphaned folder in root "C:\". It found no need to seek out a ProgramData folder. I was unable to test functionality further, as I couldn't get Tracktion to run. I imagine that the install, of WinMe, needs updated files. It only had KernelEx installed, with basically original system files. I'm using Win98FE, updated as far as it can be, and Tracktion 3 runs great (activation aside); so an updated ME should run it. Yes, Tracktion was not meant to run on any Win9x.

The only thing that has remotely worked, is setting the key "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\explorer\User Shell Folders\Common AppData". But that only fools the installer. The application will access the orphaned ProgramData\Tracktion 3 folder (in this case F:\Tracktion 3), but only for certain things. It never finds what has been installed to "C:\Windows\All Users\Application Data"; or where ever I have redirected it to, with the registry entry above. Sounds like my best attempt would be to patch the appliction to use a different CSIDL, if that is even possible.