• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
Gape

98 SE SP 3.32

2,361 posts in this topic

U98SESP3 12-12-2011

Added registry entry to core packs to make programs think Internet Explorer is installed

Added USP10.DLL 1.626.6002.22402 from Office 2007

Changed some command line switches for IE core packs

Added IO.SYS rloew full Partition Patch + Partition Offset Bug

Moved SCRIPT56.CHM from SPUPDATE.INF to SCR579X.INF, from SP3.CAB to SUPP.CAB. Installs with Windows Scripting Host 5.7

Please rephrase entry as:

Added IO.SYS rloew Full Patch for Partition Offset Bugs

0

Share this post


Link to post
Share on other sites

Please rephrase entry as:

Added IO.SYS rloew Full Patch for Partition Offset Bugs

I'll fix it.

What do you guys think about all modded and patched files having the time and date backdated to

July 11, 2006, 12:00:00 AM since this was the day support ended for Win98SE. All modded and patched files comes from here or MDGx site. We will all be using the same version just different time stamps. Then we all would know the exact origins of those files.

Just a thought :huh:

0

Share this post


Link to post
Share on other sites
:thumbup Updated :w00t: Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

Please rephrase entry as:

Added IO.SYS rloew Full Patch for Partition Offset Bugs

I'll fix it.

What do you guys think about all modded and patched files having the time and date backdated to

July 11, 2006, 12:00:00 AM since this was the day support ended for Win98SE. All modded and patched files comes from here or MDGx site. We will all be using the same version just different time stamps. Then we all would know the exact origins of those files.

Just a thought :huh:

Probably OK for the official versions, but doubtful for non-MS modified files. There are multiple versions of some files after that date such as my IO.SYS Patches.

The final release date for your Package would probably be a better choice.

0

Share this post


Link to post
Share on other sites

Awesome work PROBLEMCHYLD ! Thank you! Keep it up!

Thanks, I'm hoping maybe someone can improve the patch listed below by

on another note here is a patch for transparency of icon labels.

It is ONLY for shell32.dll version 4.72.3812.717

offsets and bytes are in hex

offset patch

11cbf 33 c9 49 89 4d 08 90

11d2b 90 90 90 90 90 90 90 90 90

This patch will NOT work with any other shell32.dll version, so don't even try it.

It is not perfect, if you drag a window over top of them it makes a bit ugly, but refreshing the desktop fixes it. If anyone can improve on it, feel free.

0

Share this post


Link to post
Share on other sites

Maybe this is easier solution for transparency of icon labels.

Source:

www.computerhope.com/download/win95/transparent42.zip

Transparent icon lbl.exe

Edited by RFMaster
0

Share this post


Link to post
Share on other sites

Maybe this is easier solution for transparency of icon labels.

Source: www.computerhope.com/download/win95/transparent42.zip

RPConfig does it already (with even drop shadows!),

but if you want an exe, I can upload what I was using: it's only 25 KB and allows you to choose the font color.

Charles.

0

Share this post


Link to post
Share on other sites

Maybe this is easier solution for transparency of icon labels.

RPConfig does it already (with even drop shadows!),

but if you want an exe, I can upload what I was using: it's only 25 KB and allows you to choose the font color.

Charles.

Thank you both for the input, but I'm going to patch the Shell32.dll because it easier.

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

Probably OK for the official versions, but doubtful for non-MS modified files. There are multiple versions of some files after that date such as my IO.SYS Patches.

The final release date for your Package would probably be a better choice.

More reason to backdate them.

Example: If you just patched IO.SYS a year ago and I backdate all unofficial files,

the service pack will not override your files

because they would be considered new. Your recent files will stay untouched. Its only about 25 files I need to do this to.

Another reason is everybody using different versions of Explorer.exe + other files. Me backdating modded/unoffical files is considered somewhat a safety precaution. Most unofficial files came out after support ended.

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

Doesn't the service pack decide what to overwrite based on version only, like all MS official updates and packs?

0

Share this post


Link to post
Share on other sites

Doesn't the service pack decide what to overwrite based on version only, like all MS official updates and packs?

It depends on the flags that are used.

That's why a lot of files inside the SP doesn't install because of their flags.

If some files don't exist on your system SP will NOT install the updated files.

It varies from file to file and the importance of that file.

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

Probably OK for the official versions, but doubtful for non-MS modified files. There are multiple versions of some files after that date such as my IO.SYS Patches.

The final release date for your Package would probably be a better choice.

More reason to backdate them.

Example: If you just patched IO.SYS a year ago and I backdate all unofficial files,

the service pack will not override your files

because they would be considered new. Your recent files will stay untouched. Its only about 25 files I need to do this to.

Another reason is everybody using different versions of Explorer.exe + other files. Me backdating modded/unoffical files is considered somewhat a safety precaution. Most unofficial files came out after support ended.

The problem is that earlier non-MS mods would also be considered new.

If you set my latest IO.SYS to 2006, it would not replace my earlier IO.SYS from 2010.

0

Share this post


Link to post
Share on other sites

The problem is that earlier non-MS mods would also be considered new.

If you set my latest IO.SYS to 2006, it would not replace my earlier IO.SYS from 2010.

You make a good point. The date I gave to backdate was just an example. I don't have to use that specific date.

But people have been having problems with the SP, maybe because of files conflicting with each other. I think we should all be on the same page. LoneCrusader made a great point. There should be the original version and only one modded version. IMO your patches for files has yet to let me down. So there is always room in the SP for your files.

Semi off-topic

If erpdude8 patched Explorer.exe and didn't disclose the specifics of what he patched

he must have had good reason and for MDGx to allow it on his site. Everything does not need to be advertised or broadcast. If people feel insecure about using modded files then they shouldn't use any modded files.

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

The problem is that earlier non-MS mods would also be considered new.

If you set my latest IO.SYS to 2006, it would not replace my earlier IO.SYS from 2010.

You make a good point. The date I gave to backdate was just an example. I don't have to use that specific date.

The actual date doesn't matter. The issue remains.

Another complication is that I often release updates as Patchers rather than the files themselves, for Copyright reasons, so the date on the file is the date the Patch was applied.

This would not be an issue for prepatched files in your SP but might affect the SP's installation.

But people have been having problems with the SP, maybe because of files conflicting with each other. I think we should all be on the same page. LoneCrusader made a great point. There should be the original version and only one modded version. IMO your patches for files has yet to let me down. So there is always room in the SP for your files.

Conflicting Mods are always going to be a problem. People may want different combinations of Mods. A single "Core" Version having only Mods, that everyone can agree should be present , would be the basis for a SP file. Anything else would be optional addons.

Edited by rloew
0

Share this post


Link to post
Share on other sites

I agree with RLoew. Moreover, my own adventures in attempting to establish which files are older than which, in some specific cases of MS official files (documented in less than 10 posts around MSFN) has let me very skeptic about the real usefulness of common file dates. They can even change on decompressing a packed archive, depending on the decompressor one uses. That's why I do rely primarily in PE Timestamps (when available) and Version Numbers, although I reckon neither are foolproof either. Fact is this is already a very confusing situation as it stands, and proliferating identical files with either different dates or, even worse, different Version Numbers will do no good, IMO, and increase the confusion. My take is, when there's no good solution in view, let sleeping dogs lie. Of course, here more than anywhere else, YMMV.

0

Share this post


Link to post
Share on other sites

A single "Core" Version having only Mods, that everyone can agree should be present , would be the basis for a SP file. Anything else would be optional addons.

Totally agree.

The thing is, we all need to be using the same mods so one can pin-point the problems and come up with a solution without any side effects.

I agree with RLoew. Moreover, my own adventures in attempting to establish which files are older than which, in some specific cases of MS official files (documented in less than 10 posts around MSFN) has let me very skeptic about the real usefulness of common file dates. They can even change on decompressing a packed archive, depending on the decompressor one uses. That's why I do rely primarily in PE Timestamps (when available) and Version Numbers, although I reckon neither are foolproof either. Fact is this is already a very confusing situation as it stands, and proliferating identical files with either different dates or, even worse, different Version Numbers will do no good, IMO, and increase the confusion. My take is, when there's no good solution in view, let sleeping dogs lie. Of course, here more than anywhere else, YMMV.

Until someone come up with a better solution, we all are going to have this problem.

In the mean time I will consider you guys expertise. There is no guarantee I will take this approach in future updates

in the Service Pack. One thing I will say, is that MDGx unofficial/updates/mods/patches has always been a reliable source.

Until someone can prove otherwise I will update the SP with all the files from his site.

P.S

ANYONE HAS THE OPTION OF INSTALLING OR NOT INSTALLING SP3.

If you don't like what I'm doing then don't install it. I CAN'T PLEASE EVERYONE!

NO DISRESPECT to dencorso or rloew

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites
One thing I will say, is that MDGx unofficial/updates/mods/patches has always been a reliable source.

I agree. That and the output of our fellow MSFN members, whose work we know well, I trust implicitly. Files from any other sources need careful analysis and testing, before being accepted as trustworthy.

0

Share this post


Link to post
Share on other sites

Even though some of rloew patches are not listed @ MDGx site

if rloew don't mind I would like to continue using them in the Service Pack :thumbup

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites
Until someone come up with a better solution, we all are going to have this problem.

Well there is a solution that should be 100% foolproof and I guess everyone knows what it is. It is creating a database of checksums of known/trusted files if anyone is up to it. Time stamps would then be completely irrelevant, however a modification of the file version would of course yeld a different checksum even if nothing else apart from that is changed but by synchronizing the file version resource with reshacker one could then check out quickly if two files with different version number are actually identical as far as the compiled code goes.

Edited by loblo
0

Share this post


Link to post
Share on other sites

The actual date doesn't matter. The issue remains.

You are right. All I need to do is set the flags in the inf to override any and all files modded or not.

So if you install the Service Pack you will automatically get the modded versions. The timestamp or version won't matter.

Thanks

Well there is a solution that should be 100% foolproof and I guess everyone knows what it is. It is creating a database of checksums of known/trusted files if anyone is up to it. Time stamps would then be completely irrelevant,

I'll try to put a list together of all modded/unofficial/patches etc.......

:thumbup

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

Even though some of rloew patches are not listed @ MDGx site

if rloew don't mind I would like to continue using them in the Service Pack :thumbup

Not a problem.

I would like to believe that my freely released Mods are "Core" Mods as I described previously.

0

Share this post


Link to post
Share on other sites

Hello,

This is my first post so just wanted to say thanks for all the work on the service pack. It’s really good to have something like this.

There is one bug (and fix) I’d like to report.

BUG: Cannot open Opera after running U98SESP3.EXE and choosing Main Updates.

Error message is “Opera Failed to load Opera.DLL because: A device attached to the system is not functioning.”

CAUSE: USP10.dll v 1.626.6002.22402

SOLUTION: Revert to v 1.422.3790.3959 of USP10.dll. This is included in RichEd9x.exe available on MDGX website.

Looks like this is an old bug resurfaced: http://www.msfn.org/board/index.php?showtopic=46581&view=findpost&p=706246

0

Share this post


Link to post
Share on other sites

Error message is “Opera Failed to load Opera.DLL because: A device attached to the system is not functioning.”

Hello gherkins,

you are very welcome here! :D

What version of Opera are you running?

If it is Opera 11, you must install first KernelEx,

and then to set KernelEx compatibility of opera.exe (right-click -> Properties -> KernelEx -> Use specific compatibility mode) to Windows 2000 SP4 :) .

No need to reboot.

HTH :)

Charles.

0

Share this post


Link to post
Share on other sites

Hi Charles

I tried it with various different versions of Opera, including 11.5 with KernelEx and 10.5 without..

In the end, the only fix was to revert to the older version of usp10.dll.

Once I did that, Opera worked fine.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.