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. 



Gape

98 SE SP 3.32

Recommended Posts

PROBLEMCHYLD    44

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.

Share this post


Link to post
Share on other sites

CharlesF    0

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.

Share this post


Link to post
Share on other sites
PROBLEMCHYLD    44

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

Share this post


Link to post
Share on other sites
PROBLEMCHYLD    44

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

Share this post


Link to post
Share on other sites
dencorso    540

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

Share this post


Link to post
Share on other sites
PROBLEMCHYLD    44

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

Share this post


Link to post
Share on other sites
rloew    93

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.

Share this post


Link to post
Share on other sites
PROBLEMCHYLD    44

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

Share this post


Link to post
Share on other sites
rloew    93

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

Share this post


Link to post
Share on other sites
dencorso    540

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.

Share this post


Link to post
Share on other sites
PROBLEMCHYLD    44

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

Share this post


Link to post
Share on other sites
dencorso    540
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.

Share this post


Link to post
Share on other sites
PROBLEMCHYLD    44

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

Share this post


Link to post
Share on other sites
loblo    23
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

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.

×