[PROBLEMCHYLD]

bphlpt, on 10 November 2012 - 12:26 AM, said:

It's been awhile since I've used, or looked at, 98SE2ME. According to it's page on MGDX's site it's last been updated Dec 14, 2011. Are there any changes necessary to using it with the latest version of SP3.x?

Cheers and Regards

No, you should be Golden

This post has been edited by PROBLEMCHYLD: 13 November 2012 - 01:40 PM

[Marius '95]

I can't download.
Does anyone have a mirror that supports resuming?

[Drugwash]

If you're using a download manager that splits the download into multiple streams, it won't work - I had the same problem, with FlashGet. The solution is to specify a single stream for this particular file, then it'll work.

[Marius '95]

I know. I'm not using a download manager. Speed is low and most probably PHP max execution time is exceeded before download is complete.

PS: Nevermind. Download completed without error this morning.

This post has been edited by Marius '95: 13 November 2012 - 05:41 AM

[PROBLEMCHYLD]

After about a week of testing, I have found that its impossible to install DSCLIENT.EXE 5.00.2920.0005 without the following 4 files that are included inside the package.

DCOM95.EXE
DSCSETUP.DLL 5.0.2195.5201
SETUP.EXE 5.0.2195.4860
WABINST.EXE 5.0.2918.2600

Now after breaking down the package and adding only the core files (to speed up installation time), the files seem to break dialup networking So the only way to add DSCLIENT is to add the whole package, which adds about 3MB to SP3.x, something I was trying to avoid. Unless anyone know of a way to only add core files to keep the SP small as possible, then I have no other ideas. Another issue with this is, Main Updates installs SECUR32.DLL 4.10.2228 US and Canada Only version and DSCLIENT.EXE installs SECUR32.DLL 4.10.2228 Export Version. You will have to replace the file manually depending on what version you decide to use. Now that I have everything working correctly, I will release 3.10 either this weekend or sometime early next week. Here is an updated list and changes for 3.10

22 missing registry keys added for HTML Help Update
 - HKLM,Software\Microsoft\Windows\CurrentVersion\Winlogon,BufferPolicyReads,0x10001,1
 - HKLM,"Software\Microsoft\Windows NT\CurrentVersion\Winlogon",BufferPolicyReads,0x10001,1
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436},,0x00000002,"HHCtrl Object"
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\Control,,0x00000012
 - HKLM,"Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}",,0x00000012
 - HKLM,"Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}",,0x00000012
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\InprocServer32,,0x00000002,"%11%\HHCTRL.OCX"
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\InprocServer32,ThreadingModel,0x00000002,Apartment
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\MiscStatus,,0x00000002,0
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\MiscStatus\1,,0x00000002,131473
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\ProgID,,0x00000002,Internet.HHCtrl.1
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\ToolboxBitmap32,,0x00000002,"%11%\HHCTRL.OCX,104"
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\TypeLib,,0x00000002,{ADB880A2-D8FF-11CF-9377-00AA003B7A11}
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\Version,,0x00000002,1.0
 - HKLM,Software\Classes\CLSID\{52a2aaae-085d-4187-97ea-8c30db990436}\VersionIndependentProgID,,0x00000002,Internet.HHCtrl
 - HKLM,Software\Classes\Internet.HHCtrl,,0x00000000,"HHCtrl Object"
 - HKLM,Software\Classes\Internet.HHCtrl\CLSID,,0x00000000,{52a2aaae-085d-4187-97ea-8c30db990436}
 - HKLM,Software\Classes\Internet.HHCtrl\CurVer,,0x00000000,Internet.HHCtrl.1
 - HKLM,Software\Classes\Internet.HHCtrl.1,,0x00000000,"HHCtrl Object"
 - HKLM,Software\Classes\Internet.HHCtrl.1\CLSID,,0x00000000,{52a2aaae-085d-4187-97ea-8c30db990436}
 - HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{41B23C28-488E-4E5C-ACE2-BB0BBABE99E8}",AlternateCLSID,0x00000002,{52a2aaae-085d-4187-97ea-8c30db990436}
 - HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility\{41B23C28-488E-4E5C-ACE2-BB0BBABE99E8}","Compatibility Flags",0x00010001,0x400
ATL80.DLL 8.0.50727.6229 Visual C++ 2005 SP1
DSCLIENT.EXE 5.00.2920.0005 Windows 2000
IMAGEHLP.DLL 5.1.2600.2180 Windows XP SP2
MFC70ENU.DLL 7.10.6119.0
MFC71ENU.DLL 7.10.6119.0
MFC80.DLL 8.0.50727.6229 Visual C++ 2005 SP1
MFC80ENU.DLL 8.0.50727.6229 Visual C++ 2005 SP1
MFCM80.DLL 8.0.50727.6229 Visual C++ 2005 SP1
MSDIA80.DLL 8.0.50727.6229 Visual C++ 2005 SP1
MSPATCHA.DLL 5.1.2600.5512 Windows XP SP3
MSVCM80.DLL 8.0.50727.6229 Visual C++ 2005 SP1
MSVCP80.DLL 8.0.50727.6229 Visual C++ 2005 SP1
MSVCR80.DLL 8.0.50727.6229 Visual C++ 2005 SP1
OLEVIEW.EXE 2.1.0.60 Windows Server 2003 SP1 Platform SDK
VB40016.DLL 4.0.24.22 Visual Basic 4.0
VB40032.DLL 4.0.29.24 Visual Basic 4.0
VBRUN100.DLL Visual Basic 1.0
VBRUN200.DLL 2.0.9.8 Visual Basic 2.0
VBRUN300.DLL 3.0.5.38 Visual Basic 3.0
VCOMP.DLL 8.0.50727.6229 Visual C++ 2005 SP1
Cleaned up all INF files
Downgraded GIFIMP32.FLT 2003.1100.8327.0 to GIFIMP32.FLT 2003.1100.8165.0 [Breaks Import GIFs feature]
Fixed Timestamp for EXPLORER.EXE when patching icons
Removed MFC70U.DLL 7.10.9975.0
Removed MFC71U.DLL 7.10.6101.0
Removed MFC80U.DLL 8.0.50727.6195
Removed MFCM80U.DLL 8.0.50727.6195
Removed MSPAINT.EXE 5.00.1523.1
Windows Management Instrumentation 1.50.1164.0 WinME CD

This post has been edited by PROBLEMCHYLD: 14 November 2012 - 11:03 AM

[PROBLEMCHYLD]

North of Watford, on 10 November 2012 - 02:06 AM, said:

Alas, it has been far too long since I have been able to contribute any encouragement or testing to this project. [As Macmillan said to a newspaper reporter during one election campaign: "Events, dear boy, events!"]

I have been watching this marvellous exercise in backporting develop over the 8 or 9 "dots" since Problemchyld picked it up by the scruff of its neck and started driving it forward. Very many thanks for the efforts that have gone into it.

My present W98SE system is too important to me and far too fragile to update in place. When I make the time to be able to start again from a reformat I will do so. In the meantime, thanks again to all who lead, contribute and test.

Jeff

I wouldn't expect nothing less Here is the thing, SP is becoming more and more stable as I continue to work on it. We have less people reporting problems which means all the bugs are getting squashed. I believe 3.8 and 3.9 are very solid builds. If anyone has any objections people post. I'm hoping to see no bugs with 3.10. So far, there has been only 2 issues reported for 3.9, and one has been fixed. Once the full stability get there, aint no turning back and we are almost there

This post has been edited by PROBLEMCHYLD: 14 November 2012 - 12:53 PM

[PROBLEMCHYLD]

Hey guys, guess what? I have got SP3.10 to install in just under 4 minutes with all options checked except for Main Updates and MDAC 2.8 SP1. I revised and tweak the installer. The older versions would take about 10 minutes on my P3 850mhz, 512MB. I was shocked when it happened, so I did it a couple more times to make sure it wasn't a fluke. The crazy thing is, I wasn't trying to do it, it just happened.

[bphlpt]

Cheers and Regards

[4js]

i love crazy things

[PROBLEMCHYLD]

I think I might have found a way to fix the VIA chipset issue. If we remove all of the VIA controllers and drivers from the main USB2.INF and create a VIA.INF with the VIA only controllers and drivers, the systems that has anything VIA will default to the VIA.INF instead of USB2.INF. Now, once we get this issue reslove, we can move to the next issue which is, if users has multiple USB 2.0 devices that may conflict with specific versions of USBHUB20.SYS.

[Drugwash]

Renaming the VIA driver to USBHUB2V.SYS or something, should solve the problem (theoretically). The only downside would be wasting some memory, having to load duplicate driver files instead of a unique one. But where there's no unique solution, there must be a compromise.
Better ideas, anyone...?

I must apologyze for not being active lately - got some hardware issues to deal with in real life and therefore haven't been able to work on software (NE editor, SP installer and other projects I planned to deal with).

[Hu$tle]

Flawless ! You need a donate button because you deserve it. If you continue doing what you are doing, I will never upgrade.

[PROBLEMCHYLD]

Drugwash, on 19 November 2012 - 03:17 PM, said:

Renaming the VIA driver to USBHUB2V.SYS or something, should solve the problem (theoretically). The only downside would be wasting some memory, having to load duplicate driver files instead of a unique one. But where there's no unique solution, there must be a compromise.
Better ideas, anyone...?

I must apologyze for not being active lately - got some hardware issues to deal with in real life and therefore haven't been able to work on software (NE editor, SP installer and other projects I planned to deal with).

I'm all out of ideas with this VIA issue. If I had a machine with VIA we probably wouldn't have an issue. Since I can't test, I can't give any further input.

[Drugwash]

Totally understandable. I've had reports of some of my toys misbehaving or not working at all and couldn't reproduce and fix because I didn't have any x64 machine and/or OS to test on.

Anyway, to keep it theoretical, your idea of pulling VIA-related commands from the inf and making a separate, VIA-only installation inf, combined with renaming the driver file as mentioned above, should allow for any combination of USB chipsets on a given machine. Unfortunately I can't test either, because the only working machine I have with VIA chipset is my main 98SE machine which works 24/7 and can't afford to botch the 6-year old installation.

I hate to add to this issue, but recently, while trying to fix a video issue in my test machine by installing different video/AGP drivers on a SiS630 chipset, I got system lockups (Windows protection error blah-blah). After fiddling around, I discovered the AGP driver package installs its own openhci.sys USB driver overwriting the one in SP, which leads to these lockups. As soon as I replaced the SiS openhci.sys with the one provided by the SP, the machine started up and worked correctly.

There still is the video issue that I cannot put the finger on, but on that I'll get back after some more testing. Right now I'm back at the NE Editor but it's coming out very slowly.

This post has been edited by Drugwash: 21 November 2012 - 08:20 PM

[LoneCrusader]

Renaming the VIA driver files may result in them not being able to properly interact with one another. I can't say that for certain, but I have a feeling it isn't a good idea.

I started to suggest having them install to a different folder than the MS files, say SYSTEM32\DRIVERS\VIAUSB2 instead of just \DRIVERS, but that may break their ability to interact with other files in the \DRIVERS directory. I believe WDMCHECK will report missing functions from files that are not in the same folder as the file being checked...


I would think that moving the VIA data to a separate INF file would be sufficient. I don't know of any situations where two different branded USB2 controllers would exist in the same system, but maybe I'm wrong...

[Drugwash]

I have a VIA VT6202 USB 2.0 PCI adapter on my main 98ESE machine. If I weren't using it daily, I could very well pull it and plug it into another machine's PCI slot, where would coexist with its native USB controller, or - if I had any money - I could buy another PCI to USB adapter from another maker and plug it along the on-board USB 1.1 controller and the VIA 2.0 adapter.

Incidentally, both the 1.1 and the PCI 2.0 USB controllers are manufactured by VIA, but it could've well been otherwise. And I've posted details about my not-so-good installation somewhere earlier in this topic, if I recall correctly.

I don't think the filename matters, as long as there are no others in the package to depend on it. Since the system registers the driver with the name it's being presented in the inf, whatever filename would do, as long as it doesn't clash with an already existing file in the same location. But of course, that is to be proven practically.

[LoneCrusader]

Drugwash, on 21 November 2012 - 11:37 PM, said:

I have a VIA VT6202 USB 2.0 PCI adapter on my main 98ESE machine. If I weren't using it daily, I could very well pull it and plug it into another machine's PCI slot, where would coexist with its native USB controller, or - if I had any money - I could buy another PCI to USB adapter from another maker and plug it along the on-board USB 1.1 controller and the VIA 2.0 adapter.

Incidentally, both the 1.1 and the PCI 2.0 USB controllers are manufactured by VIA, but it could've well been otherwise. And I've posted details about my not-so-good installation somewhere earlier in this topic, if I recall correctly.

I don't think the filename matters, as long as there are no others in the package to depend on it. Since the system registers the driver with the name it's being presented in the inf, whatever filename would do, as long as it doesn't clash with an already existing file in the same location. But of course, that is to be proven practically.

Good point about add-in cards. I wasn't thinking.

Driver files interdependent on one another may not be able to interact with each other if renamed. Often they have internal references to one another. Theoretically one might be able to Hex them all and change the names internally and externally, but that would also have to be proven in practice.


Another angle:
(dencorso please comment on this, you seem to be the most informed member about this)

Do we know 100% for sure that ALL versions of the MS USBHUB20.SYS cause errors/do not work with VIA controllers? Or is it just the version used by NUSB? Earlier versions of the MS USBHUB20.SYS driver exist (I tracked them down trying (unsuccessfully) to find the oldest possible versions of a USB2 stack to load on Win95). I can provide a link if someone can test.

[PROBLEMCHYLD]

Another possibility could be to patch USBHUB20.SYS to work with VIA. I'm not sure how to go about it but......

[dencorso]

LoneCrusader, on 21 November 2012 - 11:45 PM, said:

Another angle:
(dencorso please comment on this, you seem to be the most informed member about this)

Do we know 100% for sure that ALL versions of the MS USBHUB20.SYS cause errors/do not work with VIA controllers? Or is it just the version used by NUSB? Earlier versions of the MS USBHUB20.SYS driver exist (I tracked them down trying (unsuccessfully) to find the oldest possible versions of a USB2 stack to load on Win95). I can provide a link if someone can test.

AFAIK, the MS's USBHUB20.SYS v. 5.0.2195.6891is the troublesome one. What previous versions did you find?
I *think* that VIA's USBHUB20.SYS v. 4.90.3000.11 is universal and might be used for all users, while MS's USBHUB20.SYS v. 5.0.2195.6891 is not. So, one compromise solution would be to install VIA's USBHUB20.SYS v. 4.90.3000.11 for everybody, regardless and forget about it. However, I think that some select users experienced enough to be able to substitute back the USBHUB20.SYS for the one they already know works in their systems should test this approach. Of course, those testers must be running non-VIA machines, for this test to be useful. These are my 2 ¢.

[LoneCrusader]

dencorso, on 22 November 2012 - 12:37 AM, said:

AFAIK, the MS's USBHUB20.SYS v. 5.0.2195.6891is the troublesome one. What previous versions did you find?
I *think* that VIA's USBHUB20.SYS v. 4.90.3000.11 is universal and might be used for all users, while MS's USBHUB20.SYS v. 5.0.2195.6891 is not. So, one compromise solution would be to install VIA's USBHUB20.SYS v. 4.90.3000.11 for everybody, regardless and forget about it. However, I think that some select users experienced enough to be able to substitute back the USBHUB20.SYS for the one they already know works in their systems should test this approach. Of course, those testers must be running non-VIA machines, for this test to be useful. These are my 2 ¢.

I found USBHUB20.SYS v.5.0.2195.5605 inside this package (issued for Q319973). There may be others, but I'll have to look through all of the many, many packages I downloaded again. Maybe someone can test that version and see if it has the same bugs as the later one...


My next question was going to be whether or not the VIA USB2 stack works for all other chipsets, and if so, suggest using it instead. Similar to your suggestion.