Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


PeteK27

Member
  • Content Count

    14
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About PeteK27

  1. Thanks for a great list Rjecina! I wasn't aware that Intel still sold a chipset for which there were Win9x drivers. I did know that there are still quite a few Win9x drivers for Via chipsets (I have had good luck with the EPIA boards) but was less sure of the others. Right now I am looking at video cards. Someone correct me if I am wrong but from what I can tell Nvidia stopped supporting Win9x with its Gforce 6 series of chips and ATI stopped with the R300 series chips. It looks like there are several inexpensive boards still around based on both of these chips. Anyone have any experience with them? Also will pci-e work with Win9x or is AGP a better choice?
  2. I realize of course that there are always work arounds and that I can always find used gear. However for various reasons I would prefer to buy all new gear. Is it still possible to assemble a system out of new gear and run a version of Win9x without having to do major hacking? Has anyone purchased a new system in the last 6 months and run Win9x on it? If so what kind of system was it? Was the installation of Win9x relatively smooth and trouble free or did you have a lot of problems? In my own case what I would really like to do is buy two new motherboard/video card combinations. They don't have to be the worlds latest and greatest. The machines will be used mainly to run office type apps (word processing, email, web, etc.) They will not be used for games. They may be used to edit fairly large images. Longer term I would like to get a new laptop. However my own needs were only part of the reason for this post. Manufactures of new product will only continue to provide Win9x drivers for new gear if there is demand. Needless to say demand is declining. Recognizing this I was thinking that if the remaining Win9x community could focus its purchasing power on the manufactures who are actively supporting the Win9x users of their products it would encourage them to continue to do so. Ideally we might get a few more generations of new products that would easily run Win9x. I thought perhaps we could come up with a list of say, five current motherboards, video cards, etc, that work really well with Win9x. We could then post this information and just say “hay, here are five manufactures that are still working to support Win9x. If these products meet your needs, please support them.” If these manufactures see a nice jump in sales because of this, they would be likely to release new products that would also work well with Win9x. Please note that I am thinking here in terms of just a simple manufacture/model number type list. I am not recommending that we try to do product reviews, etc. The only criteria for making such a list is that the product would be new and easily available and that it plays nice with Win9x (no major hacking). Do such products still exist? Or is used gear our only alternative now?
  3. I have a few Win9x systems that I would like to upgrade to newer/faster hardware but am finding that many equipment manufactures no longer provide Win9x drivers for their new products. I was wondering what manufactures others are having good luck with when they are trying to upgrade. I would be particularly interested in knowing what manufactures still officially (if not actively) support Win9X in the following areas: Motherboards (which normally need at least the following drivers). Video Audio Lan USB2 I am finding that even though most motherboard manufactures don’t provide Win9x drivers I am still able to go to some of the chipset manufactures (Via, SiS, etc) to get drivers. However even this is becoming a hit or miss proposition. For example I recently purchased an SiS based motherboard and found that I could get drivers for all the on board devices except USB2. What type of new boards work best? Via? Sis? Nvidia? Ati? I seem to have good luck with Via based boards. Any others that might be better? Any particular motherboard manufactures that still list Win9x drivers for their current boards? Who should be avoided (from a Win9x perspective). Video Cards Ati or Nvidia are the big ones here. What works best? Are there any small companies that may be a better option for a Win9x system? Printers/Multifunction Devices I seem to have reasonable luck with Brother printers/MFC’s. I just bought a 7820N and found that there were decent Win9x drivers for the printer, scanner (to my surprise even supported network scanning) and fax. How about others. HP? Lexmark? Cannon? Xerox? Network I haven’t had much of a problem here yet, but I suspect that wireless cards may be a problem in the future. Anyone noticing anything yet? Laptops This seems to be a big problem area. Are there any current machines that a person can still load Win9x on without major headaches? BTW it would be nice if there was a “sticky” (or something similar) that would provide a simple “Top 5” list of hardware that still supports Win9x. I know there is a lot of new gear out there that still works, it is just not very well marked any more.
  4. I would argue that Win9x is safer to use on the internet for the same reason it is safer to use Linux, OS X, etc. Today Win9x makes up such a small percentage of the machines on the internet it is simply no longer a target. Many of the newer nasties won’t work on a Win9x machine because the weaknesses that they are taking advantage of only exist on newer machines. This is not to say there is no risk. I’m just noting that the risk is probably much less than it was even a few years ago and will likely continue to drop. Also keep in mind that many people spend a lot of time worrying about things like obscure security patches and forget about the much more common risks to their data (accidental deletion, data corruption, hardware failures, fire, etc.). What good is it to have the most up-to-date system patches if you don’t have at least one backup copy of your data? My recommendation is that before you spend time worrying about virus checkers or firewalls, make sure you put in place a good system for making backups of your data. Don’t worry so much about doing complete system backups (your OS, application programs, etc). You can always reinstall Windows. It is the documents you create (letters, papers, financial data, pictures, etc) that are probably impossible to replace. Every few weeks everyone should at least copy their “My Documents” folder (or wherever you put your data) to a CD-ROM, flash drive, whatever and then store it far away from the computer. After all that backup CD-ROM probably won’t do you much good if it is sitting next to your computer when your house burns down.
  5. >So Dependency Walker isn`t a solution as it shows only dllfiles that are directly >imported by an exe. >Dependency Walker even does not show dllfiles that are loaded on the fly by a program. It will if you “Profile” your application (which I admit is not real obvious when you first use the program). Do the following: 1) Select File:Open and open your EXE as usual (or drag and drop from Explorer). 2) Select Profile:Start Profiling… 3) Enter any command line arguments in the “Program arguments:” box if relevant. Most of the time you will leave this blank. Don't worry too much about the other check boxes. 4) Select OK. Dependency Walker will then attempt to run the EXE and show you all the DLLs that are called as the program loads. If the program calls another EXE it will open another window and begin profiling that EXE as well (You may have to minimize the current window to see the other EXE's). It even gives you a running list of functions as they are called. You can also use it to profile control panel applets by opening rundll32.exe and entering the relevant control panel file name as a “program argument”. Amazingly it is even freeware. It is not perfect because a few applications don’t really like to be profiled and will crash while loading. However many times it gets far enough to give you a good idea what the problem is. I use it a lot to figure out what DLL’s I might be missing if an application won’t work. The only downside is it only works with 32 bit apps. Also if a 32 bit DLL thunks over to a 16 bit DLL or calls into a VXD (e.g. a driver) it won’t tell you. There is a somewhat similar 16 bit equivalent called Scanbin. However it is not quite as flexible or polished as Dependency Walker. http://members.aol.com/bellamyjc/en/scanbin.html >the problem is that this exe e.g blabla1.exe extracts during runtime another exe from itself called e.g blabla2.exe >starting only that extracted exe blabla2.exe does not work. I'll admit I am not sure how Dependency Walker would react if a second EXE was actually embedded in the first EXE. I can't recall if I have ever run into this situation. However depending on what the problem is, it may get far enough to figure out what is going on.
  6. >Unless you delete the registry entries under >HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\KnownDLLs (Known16DLLs) >Shell32.dll should be only loaded from system directory. You are correct. On my heavily modified 98SE system this key has been removed so moving shell32.dll worked for me. However on a normal system this value would have to be removed from the registry for this solution to work. I should have taken the time to test my proposed solution on a stock system. My bad. For those that might be interested, there is additional information here: http://support.microsoft.com/kb/q193067/ >loading shell32.dll from different locations can be a bad idea. I’ll admit that this is a less than ideal solution. However I continue to believe that it could be a workable one. >Everything crashs lot more often (I`ve tried that ). In theory (at least according to MS propaganda) this should not happen. But I agree that it probably does. However I suspect that this problem varies considerably from program to program. Therefore I still would be interested in knowing what others have observed – good or bad. >sometimes when an exe extracts during runtime another exe >and runs that your solution is only one. >I hate this kind applications but one of them is a important progam in our firm >and our hardware was incompatible with M$-IE 4 /Win98 ,but my chief wanted that >program without buying new computer. I assume here you are referring to EXE’s that, as they are loading, launch other EXE’s in the background. I agree that these types of applications are very difficult to troubleshoot since it is not always obvious what EXE’s are being started. I believe this is part of the reason why I had problems with Word97. You are probably already aware of it, but I have found Dependency Walker works well in helping to figure out these types of situations. http://www.dependencywalker.com >Sorry for that long post I want to give precise proof that >I know what I`m talking about. I assure you I never doubted your skill. Anyone who knows how to use a hex editor to solve a problem is clearly past the “Windows for Dummies” stage.
  7. From my perspective, the problem with Shell32.dll is just a variation of what has come to be known as “DLL Hell”. See “The End of DLL Hell” by Rick Anderson. http://msdn.microsoft.com/library/default..../dlldanger1.asp One of the solutions to the problem, according to Mr. Anderson, is to use what he called “Private” or “side-by-side” DLL’s. In a nutshell this just means putting a copy the DLL that works into the same directory as the troublesome EXE. See also “Implementing Side-by-Side Component Sharing in Applications” by David D'Souza, BJ Whalen, and Peter Wilson. http://msdn.microsoft.com/library/default..../sidebyside.asp >as far as i know shell32.dll is one of the files who will only loaded from the %windir%\system because of a registry entry. I think this would be the case with 16-bit DLL’s. It may also be the case with certain COM/OLE based DLL’s. However shell32.dll is, for the most part, just a standard Win32 DLL. With these types of DLL’s Windows just searches for and loads the required file as I described earlier. >The easiest solution is to keep an Win98SE Shell32.dll in System directory renamed to e.g Shell98.dll. >Use a hexeditor to replace entry Shell32.dll with Shell98.dll. worked perfectly for 5 years While this is a valid solution, I would hesitate to call it the “easiest” solution. However I would agree that it is unclear at this time which is the best solution. I have corrected problems with the Win98 version of Notepad.exe and a minor issue with Firefox (the Import function fails with the Win95 version of shell32.dll) by placing a copy of the Win98 version of shell32.dll in the same directory as the relevant exe’s. Hopefully others will post here and report their success and/or failure with other applications using one or both methods and we can find out what works best.
  8. I think there might be a simpler solution to this problem by simply taking advantage of how Windows loads DLL’s when an exe is started. Normally (if I remember correctly) Windows looks for DLL’s in the following order. 1) The directory the application started in. 2) The current directory 3) The system directory (usually c:\windows\system) 4) The Windows directory (usually c:\windows) 5) All the directories listed in the DOS Path (usually set in autoexec.bat) I think there are two main alternatives if you want to mainly use the Win95 shell but also want to run an application that requires the Win98 version of shell32.dll. The first is to simply place a copy of the Win98 version of shell32.dll in the same directory as the exe that is causing problems. When the exe loads, it will first find and then load the Win98 version of shell32.dll instead of the Win95 version that is located in the system directory. This is probably the safest alternative. The second is to move the Win95 version of shell32.dll to the Windows directory (which is normally where explorer.exe is located) and place the Win98 version of shell32.dll in the system directory. In this case Explorer.exe will load the Win95 version of shell32.dll and most other applications will load the Win98 version. I have had some stability problems running this alternative (e.g. Word97 crashes) but they may be fixable. I haven’t had enough time yet to figure out what might be going on. This may not solve every problem of this type, but it seems to work for at least a few applications that I have had issues with.
  9. Hi tentonine, Sorry for the delay in responding to your previous posts. >Tried to do some testing of Dial-up, but ran into a few problems. You are correct in noticing that I removed much of the support for ISA cards. While they should still work if you manually install the drivers, I took out most of the PnP stuff . If I remember correctly there are two parts to putting it back in. The first, which you found, is the isapnp enumerator (driver). This is normally in MACHINE2.INF. If your ISA card is PnP enabled the isapnp enumerator should make sure Windows detects it and kicks off the normal PnP driver install routine. Most ISA cards were not PnP enabled (they often predated Win95) and need to be detected manually. The file MSDET.INF directs how this was done. However since the process of scanning for usually nonexistent hardware can add several minutes to the installation time and increases the risk of a system crash, I removed most of the instructions. If you revert back to the original version of MSDET.INF I suspect your sound card might be detected properly. I’m a bit torn on how much of this support I want to add back in. As I am sure you remember, ISA cards were usually a royal pain to get installed properly with all the IRQ conflicts, etc. Are ISA cards still that common? Do you think this support needs to be added back in? BTW, you've probably already found it but I also posted a zip file containing original copies of the Win98SE inf’s sorted into various directories. I’ve found it makes troubleshooting a little easier. You will find it here: http://64.213.216.19/pcss/Win98SE%20master%20infs.zip >The modified setuppp.inf seems to work with Type 1, 2 and 9, but I'll be doing more extensive testing this weekend. This is good news. I was hoping I wouldn’t have to maintain several versions of setuppp.inf. I’ll add it into the main package in the near future. I would do it now but I would like to wait and see if I get anymore feedback. I prefer posting any changes all at once.
  10. >I want\need the GUI shell enhancements of IE but don't want to pay for them by accpeting the rest of it. Keep in mind that, as of Win98, iexplorer.exe and explorer.exe are two sides of the same coin. It is difficult to change one without breaking the other since they both use the same DLL’s. However if all you want is the shell enhancements and don’t plan to browse the web with IE there are significant chunks that can be removed. I would suggest that you take a look at iefiles.inf in PCSS for some background on the parts of IE that you will probably need. Even though I used the Win95 shell in PCSS, it isn’t too complicated to modify it to use the Win98/IE shell instead. I left several notes about how to do this. [see this post for PCSS http://www.msfn.org/board/index.php?showtopic=53927. BTW, PCSS.exe is just a big DOS based zip file. If you want to see what is going on (without reinstalling Windows) simply run it in a temporary directory. It will just extract a bunch of files and you can then read through them to see what is happening] Once you get the Win98 shell running you can then go through IE6SP1 and pull out the updated files that you would need and begin experimenting. In most cases you probably won’t even have to modify iefiles.inf. Just copy the updated DLL’s into the windows setup directory and install as normal. Setup will grab the updated DLL’s first rather then the ones in the cabs. However I am sure you will run into at least a few problems. A few of the updated files will probably depend on a few new DLL’s, require some new registry entries, etc. But if you take your time and proceed carefully I don’t see any problem making this work. <SOAPBOX>That said I still consider the integration of IE into the shell a bad design decision on MS’s part. No matter how many “critical updates” MS releases it will always be an inherent security problem. What parts of the shell enhancements do you consider important? Are you sure that there aren’t other solutions to these problems? I’ve been able to solve most of my own problems with the Win95 shell. However I do realize it has a few warts that could be a major problem for someone else.</SOAPBOX> >it could be modified ala Fred Vork's Win2000 RegInstall tips I’m not familiar with this. I think you are referring to modifying the inf files embedded in the various IE DLL’s but I am not sure. Please provide a link to more background. >like provide for installing the '/program files' folder at a different directory I think this is determined by the following registry entry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir Check the winbase.reg section in subase.inf in PCSS and modify as you see fit. You will also need to modify some DestinationDirs sections and change a few registry entries in other infs to point to your new path. Keep in mind that some lazy programmers may hard code the normal path into their third-party programs. You will have to experiment to see what works. >I'd like to make the default install certain files in a different location A few changes to the DestinationDirs section in the various relevant infs should do this. Keep in mind though that Win9x by default searches only a few key directories if it can’t find a file. Therefore if you move a DLL out of the Windows\system directory, for example, you will have to add the new path into autoexec.bat so Windows will find it. The exception to this is COM/OLE based DLL’s that are able to self-register (Most of IE, MediaPlayer and parts of DirectX falls into this catagory). >or if I can do it without breaking too much I'd like to make the setup put everything in '/Windows/system I’m of the reverse mindset here. I hate it when everything gets dumped in one directory. It makes it hard to keep track of what is going on. However in most cases I don’t see this as being a problem if you want to do it. >I'd even like to see what could be done about creating some kind of front end to this ala 98Lite If you are looking to create a “new” version of Win9x there are a couple of different ways to approach this. The first (mainly bottom up) approach is to modify the infs that come with a stock version of Windows to install the various components that you want and then just use the normal Windows setup routine (setup.exe) to install your modified version of Windows. This is what I have done with PCSS. A second (mainly top down) approach would be to create a package that would install over an existing Win9x installation. This is the approach used by the unofficial service pack. This is easier for the end user (since they don’t have to reinstall) but limits your flexibility since you have to be very careful not to trash someone’s system. There are multiple install programs out there to help you do this. I wanted maximum control and flexibility so I opted for the first approach. However the average user typically sets up their hard drive as one big partition which makes reinstalling Windows a difficult and risky process. As a result this approach is likely to be considerably less popular. >The trick (IMHO) is to get something that can be run on a proposed 98Setup directory and make all the changes from there with the user typing 'y' This is more or less how PCSS.exe works. >The difference would be that once finished the program\bat would exit out leaving a completely patched directory with everything ready to be used. Ditto >The whole thing would run from start to finished and exit out with an updated (in all senses of the word) desktop. This is the part that my package doesn’t do. In my case it wasn’t a big priority. However from what you have described, I think my package would be a good starting point/learning tool to help you get there.
  11. Having spent far too much time exploring the Win9x setup process, I would like to clarify a number of misconceptions about setup.exe. Jimmsta is mostly correct when he says “setup.exe is basically just a dummy launcher”. However even the *.bin files don’t really do much. They mostly just provide the pretty GUI front end. The real work is done by a handful of key DLL’s of which setupx.dll performs the bulk of the work. Setupx.dll is mostly just a text file parsing engine. Its job is simply to open, read and process inf files. Contrary to what you are thinking, it is the content of the setup files (infs) that determines what gets installed, not setup.exe or the related files. If you change the infs, you can radically change what gets installed. Overall there is really no point in rewriting setup.exe (and/or its related files) since a rewritten version won’t do anything that couldn’t be done much easier with a few custom inf files. >Things like adding IE6SP1 at install time simply can't happen because setup.exe says so. Unless MS recently changed things, most of the IE packages use an inf driven setup engine that for the most part is modeled on setupx.dll. If you download the IE setup files (mostly various cab files) you will find that they contain a number of inf files. With some relatively minor modifications, I am not aware of any reason why you could not slipstream IE6SP1 into the Win9x setup process. After all this is exactly what MS did with IE4 in Win98, IE5 in Win98SE and IE5.5 in WinMe. I haven’t done it simply because I am not a big fan of IE. >I'd like to be able to install IE6 at install Then learn all you can about how the win9x setup process works, download the IE setup files, fire up notepad, and start editing. >ditto on Direct X Different program, same process. I can’t think of a program (assuming that it was designed to run under Win9x) that couldn’t be made a part of the normal setup process. It is simply a matter of figuring out what files need to be copied and what registry entries need to be made, and then writing an inf file that will do that. All most of the various setup programs (Installshield, etc.) do is put a pretty face on the job of copying files and making registry entries. I’m not saying this is a 5 minute process. However the bulk of the work involves mostly testing, testing and more testing of your custom inf file until you get it right. My only advice is that you may want to consider starting with a slightly smaller project and working your way up to IE6SP1. IE is a rather tangled, complicated mess (this is part of the reason I don’t like it). If you don’t get everything just right, things just stop working. Even changing something minor often breaks some part of IE that you would think should not even be related. This is not a problem with the Win9x setup files, it is a problem with the inherent design of IE. >Things that 98lite did on the inf level can only go so far before they run into limitations in microsoft's setup.exe. 98lite and my package (pcss) only scratch the surface of what could be done simply with inf files. I have a number of ideas for creating what could be a whole new version of Win9x. I simply don’t have the time to execute them.
  12. tentonine, Nice work! It looks like you have hacked some of these setup files before. I going to remove my previously modified setupc.inf and instead post a version of setuppp.inf that includes your changes. If you can, please look it over and make sure I didn’t miss anything. http://64.213.216.19/pcss/setuppp.inf Just out of curiosity, did you try to use your modified setuppp.inf with your type 1 disk? What I am wondering is whether there needs to be different setuppp.inf’s for each type of setup disk or if it is possible to come up with one version that will work with all types. Looking at the web site you pointed me at, I’m guessing that the Type 1 disks are the “retail” version of Win98SE and the Type 9 disks are the OEM version (shipped with a new computer). Based on the disks that you have, does this sound correct? Also, is anyone else running something other than a ProductType 1 or 9? I think you should be able to check this by opening the file setup.inf in c:\windows\inf and looking for the keyword “ProductType” under the [data] section. On a more general note, once you got things up and running did you have any major problems? I am particularly interested in whether you were able to use dialup networking successfully. I don’t have a modem so I was never able to check this.
  13. tentonine, I was aware (or at least suspected) that there were slightly different versions of the Win98SE setup disks. Unfortunately I only have access to one so I was not able to test my package against some of the other versions. However I think I might know where the problem is. Before you begin to run setup, try replacing setupc.inf with this file: http://64.213.216.19/pcss/setupc.inf Hopefully this will correct the problem. BTW, do you know how many variations there are of the Win98SE setup disks and what the differences might be? wizy, Regarding integrating in the service pack, option pack, etc, I agree that this would be the logical next step. I have looked over the service pack a little but haven’t really worked much with it. Ideally it would be nice to be able to slipstream the service pack in prior to running setup. However I suspect that if you did this right now it would probably fail because my package uses the Win95 shell rather than the Win98 shell. Therefore the service pack will (at minimum) probably have to be modified to remove any Win98 shell components or my package modified to add back in the Win98 shell. However right now I plan to use my rather limited amount of time to concentrate on shaking out any bugs and adding critical features that are needed to make this a functional package. But if you decided to test my package with the SP, OP, etc I would be interested in knowing what problems you ran into. Even if I can't address them right now, your comments may help out in the future. Pete
  14. Hi all, Over the past few years I have been slowly customizing the setup files (inf's) that come with Win98SE to modify how it is installed on my system. I realized that some of my work might be useful to others so I decided to pull it together into a single package and make it available to those who might be interested. For background on what I have done and how these custom scripts work I have a readme text file here: http://64.213.216.19/pcss/readme.txt If you decide you want to experiment with these scripts, you can download them here: http://64.213.216.19/pcss/pcss.exe Warning: This is a big (13Meg) file and a slow unreliable link. All the best, Pete
×
×
  • Create New...