MDGx,

thanks again for the latest updates ... can you confirm that the Q933360 update replaces Q931836? It seems obvious that it does, but you normally explicitly say something if an update replaces another, and you didn't for this one. So i'm bugging you about it, sorry

EDIT: oh, and both versions you've released of the Scripting engine v5.7 update doesn't work right on my test system,it days i already have the update installed when i jolly well don't. i'm going to try to repackage it i;ll let you know the results ...

is anybody else getting a message saying you already have v5.7 when you actually don't? Is it just me, have i finally lost my marbles?

EDIT2: all i did was repackage the contents and now it installs OK. MDGx, you are doing something different to me, it looks like a version check but it's not working in my case.

EDIT3: oh, and MP936782 replaces the now obsolete kb917734. Let me know if i'm wrong.

Same here, says that 5.7 is already installed. But it does install ok manually, shows up in add/remove programs. I removed it again. Reinstalled 5.6 and then, with a fresh start, installed 5.7 again. Now I don't get the message and it installs automatic.

256 colors windows icon on the Start button!

The icon shown on the Start button is 16x16, 16 colors in all versions of Win 9x/ME.
That's because it's taken from icon group 105, within user.exe, where there are no 256 colors icons. I thought that maybe just adding a 16x16, 256 colors icon to group 105 would be enough for the 256 colors icon be used instead of the 16 colors one... It was a long shot, but I found I was right!!!

So I decided to also include a 32X32, 256 colors icon, as well as substitute both original 16x16 and 32x32 16 colors icons with retouched icons using a lighter blue for better display.
Now, here I offer you my results, three files: USER.EXE 4.10.0.2233 with new group 105 16x16 and 32x32 icons in both 16 and 256 colors, with the new versions of the tradicional Windows icon; a proof-of-concept version of USER.EXE 4.10.0.2233 with the same icons except for the 16x16, 256 colors, which, in this case, I substituted for Dr. Hoiby's 16x16, 256 colors icon, just to show that this is the icon used in the Start button; and a new version of my USER.EXE 4.90.0.3001, for use with 98SE2ME, with the new icons and hexedited to show the windows version correctly as 4.10.2222 A in SYSDM.CPL. I've tested each of them for more than a month on my system, without any troubles, so I feel they are safe for release.

*** Warning: Of course, these modded versions of USER.EXE can only be used with the matching version of USER32.DLL!***

Download-Link: <http://rapidshare.com/files/52583808/USER256.7z.html>

Thanks to eidenk for starting the topic on how to do it. See:
<http://www.msfn.org/board/index.php?showtopic=93116>

@ MDGx

I think there's a problem with MS 5.7, it's breaking your code that finds the Program Files folder. It's returning a 'Bad command or filename" error.

Has anyone else had problems?

Many thanks for the mods.

I'll add USER.EXE 4.90.3001 to 98SE2ME soon.

Keep up the good work.

1. Indeed it does, Q933360 replaces Q931836.
Added this to the 8-27-2007 update:
http://www.msfn.org/board/?showtopic=46581

2. I've updated MSE 5.7: please see 9-3-2007 update:
http://www.msfn.org/board/?showtopic=46581
Hopefully it will run ok now.
See also unofficial MSE 5.6 [install it in case MSE 5.7 doesn't work]:
http://www.mdgx.com/add.htm#MSE

3. MP936782 does not replace MP917734, because MP917734 is for WMP71, not for WMP9.
BTW:
I've fixed MP936782, now installs also on Win98 (FE) + 98 SP1.
Windows 98 (FE) + 98 SP1 require Unofficial WMP9 already installed:
http://www.mdgx.com/wmp.htm#WMP9
WMP90_98.EXE is a repackaged WMP9 which installs on all Win98 editions.

More updates + fixes here:
http://www.msfn.org/board/?showtopic=46581

HTH

I got it, just didn't have time to post.

Posted today [9-3-2007] all updates you guys [the_guy + erpdude8] sent me for the past 2 weeks.

Please see:
http://www.msfn.org/board/?showtopic=46581

HTH

UPDATED 9-3-2007

One more time it wanted to be thankful for the magnificent support that vocês they supply to the Windows 98. How God blesses them for this work!
He forgives my English!

You're welcome!
Thank you for your site, 98SE2ME and all your efforts that help us keep Win 9x alive and kicking!

BTW, I sent you a PM on Jul 27th... Did it reach you?

I've downloaded the Kensington mice drivers + tools you sent.

I'll post something soon.

Thanks a bunch (again).

Hi, bristols! erpdude8 is right: oleaut32.dll 2.40.4519 *is newer* than 2.40.4522!
This is just a versioning conundrum caused by M$ habit of late of releasing parallel series of updates starting at different versions for different OSes. But it can be solved, in the case of PE executables like oleaut32.dll, by looking at the file compilation dates (aka PE Timestamps, which are MUCH more stable, becuse they're tucked away in the PE header, than common file dates, which reside in the directory entry an can change easily). To see the compilation dates in readable format one must use MiTeC EXE Explorer, or PEDUMP.EXE by Matt Pietrek, a somewhat more technical console app. For the latter, try <pedump filename.dll | find /i "timedatestamp"> and consider the first value listed (the others are usually zero, anyway, because it tries to get the PE Timestamps of the .dll dependencies and fails silently... yes, they are the result of a bug...). I've compiled a list, for some versions of oleaut32.dll, so here is it:

Versions of oleaut32.dll known to work with Windows 9x/NT4/ME
==========================================
PE Timestamp 04/23/1999 16:37:36 V. 2.40.4275.1
PE Timestamp 08/31/1999 23:15:11 V. 2.40.4277.1
PE Timestamp 05/04/2001 21:34:09 V. 2.40.4517.0
PE Timestamp 03/16/2001 23:09:34 V. 2.40.4518.0
PE Timestamp 07/31/2006 18:12:40 V. 2.40.4519.0
PE Timestamp 06/20/2003 02:43:41 V. 2.40.4522.0

Of course, if one knows from which packages or updates those files came, and their relative release dates, it should not be necessary to go for the PE Timestamps, but that is not always the case. But I don't think the existence of PE Timestamps is very widely known, and this is a good exemple to show their utility. Too bad only PE executables (sometimes referred to as Win 32 executables), among all possible types of executables present in the Windows OSes carry their compilation date inside. Then again, they are becoming more and more the standard for .exe, .dll, .ocx and .tlb, and that is good news!
In a nutshell, changing oleaut32.dll form v. 2.40.4522.0 to v. 2.40.4519.0, despite all the apearances, *is an upgrade*, not a downgrade! HTH

<Additional musings... It seems there always IS something more to be said >

Relevant files found in VB6-KB924053-x86-ENU.exe, having internal name oleaut32.dll
===========================================================
PE Timestamp 07/11/2006 07:19:34 V. 2.40.4531.0 Size: 631,053 bytes Name: oa2k.dll
PE Timestamp 07/31/2006 18:12:40 V. 2.40.4519.0 Size: 626,960 bytes Name: oant4.dll
PE Timestamp 07/31/2006 18:43:21 V. 2.40.4519.0 Size: 626,960 bytes Name: oant4ts.dll

oa2k.dll was tested by erpdude8 and by MDGx, and both found it's unsuitable for use with Win 9x/ME. So I didn't test it myself but I mention it here because its version number indicates it's presently the most up-to-date version of oleaut32 in the series 4522 .... 4531, that M$ intended for Win 2k. Of these only 4522 does work with Win 9x/NT4/ME.
Now, oant4.dll and oant4ts.dll, despite having the same version number and the same size, are a long way from being the same file, because they exhibit 27,906 differences in a direct binary compare. They are both intended by M$ for NT4 systems, but oant4ts is for NT4 *Terminal Server*, which, in IMHO, is much more different from Win 9x/ME than plain-vanilla NT4, so I decided the right file to pick would be oant4.dll, which I've been using, renamed to oleaut32.dll, in my system, for some time now, without any problems. I do believe erpdude8 reasoned along these same lines to select which of the 4519 files that he tested and found it works OK. I've checked the oleaut32.dll that is inside the Unofficial 98fe SP v2.2.0, he has just released. It is the same oant4.dll that I'm currently using, from its PE Timestamp.

Now, the 4519 files are the latest in the series 4275....4518, which M$ had stopped updating for some time, but since they were released in the same update pack as 4531 I took it to mean, to me at least, that they are equivalent from the hotfix point-of-view, both being the most up-to-date at the moment, the main difference being that 4519 lacks the Win 2k specific features present in 4531, most possibly *the features* that render 4531 unusable with Win 9x/ME. Of course, this last comment is just my opinion, so YMMV.

Can you list all the updates thats included please
i'm trying to avoid installing the same updates over and over again

I think MSONSEXT.DLL installs from web folders update

WMP90_98.EXE is just the original WMP9 installer, modified to work under 98FE.

the_guy

Thanks, I ignored that. Let us hope it is more reliable with MS files than with Exe Explorer itself, as I would not think it has been compiled the 19/06/1992.

Great catch, eidenk! The people at MiTeC, of course, may have done it as a deliberate prank...
It hadn't occurred to me to use it to look for its own PE Timestamp. It can be spoofed quite easily. The only reason I think that it's usually reliable is the fact that it is a very little known detail of the PE standard, automatically set by the linker. One has to know it's there to spoof it. PEDUMP, for instance, really is from 29/08/2001, and I just found out a newer version of it (05/4/2004) in the downlodable companion file to this MSDN article, by Matt Pietrek: interestingly enough, when you run the 2001 version it says 1988 on the sign-on message, while the 2004 version says 2001. Matt Pietrek has updated that program many times, but did not update the text of the sign-on message consistenly every time... This new version still cannot find the dates of the dependencies but has improved, for, at least, it abstains from translating 00000000 as Wed Dec 31 22:00:00 1969...

UPDATED · 9-26-2007

Please see the top of this topic for most recent updates:
http://www.msfn.org/board/?showtopic=46581

What a haul this month MDGx !!!

Any further info on:

CNTROL98:
http://www.mdgx.com/web.htm#9SU
* Unofficial Windows 98/98 SP1/98 SE Control Panel Applets Lockups CONTROL.EXE 4.10.1999 Fix [63 KB]:
http://www.mdgx.com/files/CNTROL98.EXE

cheers.

EDIT:
re: the MS Paint add-on and Graphic Filters Pack ... i'm including them both as an optional update in the next v of AP, and i may as well package them together as a stand-alone MSPAINT update ... wanna beat me to it ?

edit: ie the fixed version of MSpaint.exe and also the Graphic Filters Pack.

I see the inf has the infamous ,,,4 parameter for the included files. Incidentally I have (better said, had) USP10.dll v1.0471.4030.0 installed prior to this upgrade and I had noticed no visible issues. After the upgrade I forcibly got the lower-versioned file.
Question: is this version matching required? Otherwise, why is the ,,,4 parameter used for all files in the package?

Also, as reported some time ago in some other thread around, this version of riched20.dll has issues with bad words underlining in Miranda IM's spellchecker (based on Hunspell), reason why I had been using riched20.dll v5.30.23.1221. Is there still no better version that'd be worth using instead of this one?



Nevertheless, thank you very much for all your hard work!

I may consider dropping the user.exe/user32.dll v4.10.2003 files from the next release of the unofficial Win98 FE SP since it can cause problems with Tihiy's RP pack. And I'll restore the kb891711.exe & q8917111.dll files as well.



Where the heck did you get v1.0471.4030.0 of the usp10.dll file, Drugwash? That's what I'm more worried about.

Version 5.40.11.2220 of riched20.dll is featured in the Office XP post-SP3 MS07-013 security update.
Version 5.30.23.1221 of riched20.dll is prone to security flaws mentioned in security bulletin MS07-013. Replace it with version 5.30.23.1227 which I have for my Office 2000 suite.

Newer Root Certificates update (revised August 23, 2007); file size 281kb:
http://www.msfn.org/board/ipb_seo.php?url=...%2Frootsupd.exe

To be honest, I can't remember where I got that usp10.dll version from. I don't quite keep an evidence on sources; all I'm interested in is the final result.
Here's the full info on it:

I'm positive I don't have riched20.dll 5.30.23.1227 around, otherwise I would've already had it installed. Frankly, I'd rather use one of the 5.50 versions - because of the link color fix - but those seem to have some issues of their own. This has been discussed at large some time ago.

Hi, Drugwash!
Since everybody here clearly understands .INFs better than I do, I'll just take this opportunity to ask, before I die of unsated curiousity: what do the ,,4 and ,,,4 flags mean, please? Thanks in advance and best wishes!

Ah, I'm not a specialist either - just catching some things on the fly.
As far as I understand, that parameter is used to force installation even over an existing higher build number of a file.
It should be used - at least theoretically - only when certain files strictly depend on other certain versions and mismatching would lead to unpredictable results.

@ Mdgx:

I sended you an email.

Thanks, Drugwash. You rock!

Added text 9th October 2007 - 04:25 AM:
Thanks for the links in you post below this one, soporific! They sure help a lot. You do rock too!

here's a link that explains all:
http://soporific.dsleague.com/downloads/copyfile.htm

i got it from the INF guide that MDGx keeps a copy of at this location:
http://www.mdgx.com/INF_web/INF_WEB.ZIP

K891711 (or Q891711) IS EXTREMELY DANGEROUS: DO NOT USE IT

For the second time (same problem as with the previous version 2 months ago) my computer was unable to restart and I had to reinstall windows.
It said "unable to load user.exe" then shut down in 1/10th of a second. Clack! (You know, the sound when the PC power is turned off). I didn't have the possibility to restart it! ===> Boot Floppy time!

MDCx: Please remove it from your list!!

Dunno what your problem is, but I just installed it (twice: installed, uninstalled while trying to fix some unrelated problem and reinstalled) recently and I had/have absolutely no such issues. Well, there may be problems with resources dropping quite fast, but that's something else and could be caused by any other factors as well, such as gdi.exe/gdi32.dll (updated to 4.90.3003).

Please check any possible resident/BIOS anti-virus or other applications that may block operations on system files. Or maybe some strange boot-up configuraton...

You may ask MDGx to create a debug version that'd create a log of the operations performed during install, so you could find where (and possibly why) it breaks.

Fredledingue,
See this post.

RetroOs,

I guarantee you that I installed the last september version because I remeber having read the "removed the ",,4" + ",,,4" strings " stuff before installing it: I always save all the notes posted by MDGx and save them in text files with the same name as that of the updates. Then I read each note before applying each update.

It has nothing to do with Revolution Pack because I never installed this pack on my computer.
There is a problem obviousely not related with RP.

Anyway, I don't want to hear about "explanation" or "cause that might be": What I see is that my PC crashed and destroyed my system twice already.
I have applied dozens of patches and upgrade packs, yet this is the only one which I have got troubles with.
I couldn't compare 100 computers on this patch, but I have compared 100 patches on this computer. And this patch has something realy scary in it. If it was a "very special boot up configuration", I would have had this problem more often than only when applying this patch, isn't it?

Given the seriouseness of the computer crash, it's safe to quarantine this update to the Dangerous category.
Despite the fact that others have installed it without problem. It's not like you get a temporary BSDO and then you go in safe mode:No, You just can't turn your computer on! Can you imagine that? Clack! Suddenly the machine is off as if someone pulled the power cable off the case. I NEVER have seen this effect on a PC ever.
Without a bootable floppy and some DOS knowledge I was toast. Imagine it's a newbie...

IMVHO, it should be removed from the list until it's packed into a decent installer.

I don't see how this patch could screw your system to the point you report. But maybe we are not speaking about the same thing as you haven't provided a link to the installer you claim creates such problems, if I am not mistaken.

Nor do I. But it did: user.exe was absent from my system at the time I rebooted with the floppy disk and user.dll probably too. Amd the computer turned itself the power off as i described above.
I didn't dream it (pinching myself to check ).

Here is the link of the file in question:
- USER32.DLL + USER.EXE Fix [419 KB, English]:
http://www.mdgx.com/files/Q891711.EXE

Here are MDGx's comment on this patch:



A few months ago MDGx wrote about previous versions of this patch:



===> But this was not my case: I launched the patch only once.

Fredledingue, what language version Win98 do you use? I had the same. At least you're not alone.

I rebooted immediatly after install but still. No RP installed, no exotic boot-config.
This has happened with my system with the gdi.exe/gdi32.dll update too! I blew another win98se machine with the shell32.dll fix.Somewhere the installer is going very wrong, because there are no files copied. But the originals are renamed to .98o and there you go...
Both these machines have a Dutch win98se and all these files have in common that they are kernel-system files.
I always install English fixes on my Dutch system without serious issues except for these cases. But nobody ever recommended this, I blame myself.

The blown systems can easily be fixed by extracting the files manually from the installer (the files themselves work fine) and copy them to \windir\system\ in real DOS. I learnt my lesson and will have them ready before trying to install the normal way.

Sure it would be great if this could be solved in future fixes, but we can't expect the creator of the fixes to test lots of different system-configurations let alone all.

OK, i've been on the receiving end of some USER.EXE, USER32.DLL and EXPLORER.EXE muckups quite a few times and it really is the simplest thing to fix if you know what's going on when this happens. Yes it p***es me off no end when it happens, but, again, it is the easiest thing to fix. For me. But what about others?

I think its high time the "keep Windows 98 alive" crew, which is most of us regular posters in the "Unofficial Win98 SE Service Pack" section of MSFN, create an automatic hotfix solution to fix all those caught up in the maelstrom of our system patching activities. I'm specifically talking about the USER*.* issues. Not everyone who takes a punt by installing these updates knows what to do when it all stops working, especially the problem that stops the OS from even loading. If this is your only connection to the internet, its highly inconvenient to get a fix for the problem by the usual way of asking for help online.

I know the REAL solution would be to create hotfixes that don't muck a system up, but the real world shows us its still possible. And when the solution is so easy i think its high time we provided one for the community.

So who wants the kudos for getting this fix together? I have some ideas if someone wants to help out...

I think an easy fix option is a great idea.
Exactly how this would be assembled is something to discuss.
Perhaps a separate thread?

However, I think there may be some issue that is some times appearing with the update installers.
I had a problem some weeks ago with the OLEUP update where it did not replace the files on reboot and left them missing.
See my post here. Also this post.
Maybe a recent update has caused problems with IExpress installers in some cases?
Something to look into.

MDGx: Any comments?

Well I have installed this patch in a virtual machine and there is nothing wrong with it. According to me it CANNOT do what you claim it does (the computer turned itself the power off).

Here is the inf file of this patch :



It is meant to backup (used for uninstall) and replace user.exe and user32.dll and it works as expected :

First stage of the install copies the patched versions of user.exe (as user.001) and user32.dll (as user32.001) to the system dir :



And creates a wininit.ini file in which we can see that on the next reboot the original files are going to be backed up as user.098 and user32.098 before being replaced by the new versions :



And thist is exactly what it does. System check after reboot :



You can see that the original files have appeared and have been replaced by the patched ones.

No can you please tell me what in this installer, if it would fail for a reason or another, would yeld the symptoms you report ?

According to me it CANNOT yeld all the symptoms you report. It is impossible.



With all respect due to MDGx, most of those warnings are plain nonsense IMO, especially the first one :

Indeed, the first phase of install consist only into copying two files (+ an inf file to the inf folder) and creating a wininit.ini file so that user.exe and user32.dll can be backed up and replaced on reboot. There is no risk of any lock up whatsoever here.

The second warning makes more sense as reinstalling the patch without having uninstalled it first will lead to have back up files for uninstall that are not the original ones but the patched ones as well. No risks of lockup either here.



Frankly, with no pun intended, your apparent lack of grasp of the most basic mechanisms of Windows is sometimes appaling.

Especially when considering the fact that you appear to be an experienced user who even writes complex VB scripts for checking system integrity.

From what I have read above the problem is with the wininit.ini file.

Either wininit.ini is not executed at all
Either wininit.ini execute at a later stage when user.exe is already needed by the system
Either wininit.ini wasn't written correctly by the installer.

Eidenk
It's not because a code is written, as simple as it can be, that it will always be executed as intended. There is only a relatevely high probability that the code will be executed and this probability is never 100%. Not because of the coder but because of computer imprecision, unpredictability and unknowns.
The only reason why you think that it's impossible that it's not executed properly as verified in your test, is that you ignore these concepts.

I didn't mean to offend the anonimous. I imagine that he has tested his patch before and didn't see any possible error.
Now the goal is find out the unkown and the unpredictable in order to fix it.

noguru
Thanks for sharing your experience with us. My version is english.
So I don't think it's language version issue.

RetroOs,
I also had an issue with OLEUP in the past but thanks to MDGx's infos, I could solve the problem.
The effect of the wrong install with OLEUP was not even remotely as scary as with *891711.

It's funny... I don't have user32.dll in my system.

RetroOS:
Happened to me too!
OLEDLG00.DLL is not deleted AND the new OLEDLG.DLL is not added.
I used the same workaround as you did.

But of course you do. Question is where is it. That might be a reason for the problems you reported.
I mean, mixed user.exe/user32.dll versions... Try to find it, by using LOCATE. HTH

Sorry, I found it indeed. I must have mistyped user32.dll when I searched for it.

Hey guys,

Until MDGx updates his site with unofficial IE/OE updates, the newest version of the IE updater has those updates in them.

Download from Filefront

Also, a new version of the ME SP (I will not update the main topic until MDGx posts a link on his site, consider this a pre-release special).

Download from Filefront

the_guy

I have just tried out mesp202en-b9.exe update for Windows ME. I installed it on a clean copy of windows ME with the latest versions of Internet Explorer 6.1, DirectX and Media player installed. The only problem I saw was when the program had finished installing the updates and the computer was restarted the error message "Windows could not upgrade file %1 to %2 %3" flashed up briefly on this version of the updater, Windows update now works correctly and reported the following required updates.

KB916281
KB837009
KB833989
KB917734
KB904706
KB828026 (not required)
KB887797
KB816093
Microsoft Net Framework 1.1
Windows Automatic update
Euro conversion tool

Hey MDGx,
There are regular problems being reported with the current OLEUP update not actually installing OLEDLG.DLL and leaving the old one missing...
See a number of previous posts.
Also see here for the latest one.
I think the author of this unofficial update needs to revisit it!
It's really quite useless as an update as it stands if it needs manual intervention to get back an OLEDLG.DLL file that was there before the update...

MDGx is strangely absent. He hasn't logged in for over 2 weeks (according to his profile).

It seems strange to me, since he's a moderator, and is usually so prompt when dealing with enquiries and posting new and revised updates.

Even moderators need holidays!
That might explain why the latest unofficial 9x IE6 and OE6 updates haven't shown up?
They've probably already been compiled, but haven't been posted anywhere...
Afterall, MDGx is the updates collector man!

seriously, you can set your watch by MDGx ... just not this month for the first time in ages. It just goes to show ... human beings need holidays! It's about time he took a break

We've got things covered till you get back MDGx!