Auto-Patcher For Windows 98se (English)

[soporific]

Took me AGES to download, even with Flashget using ten jets, it started fine but the server was getting really slow and exhausted towards the end! When I came to install it I thought I'd be sitting at the machine all night, all that rebooting and updating! It got really scary at times!!

Just out of interest, does your computer reboot to the desktop without having to log in or anything like that? I would imagine that for people who have to do something (ie press a button) for the desktop to finish loading would get a wee bit frustrated with all the reboots. There is maybe room to save on one or two reboots, but most of them are still required ... the fact that Microsoft didn't have to do that much to create an OS that didn't have to reboot so often really puts a rumoured quote from one of their hapless way-down-the-corporate-ladder employees into context ... "Windows 98 is a toy operating system" he was supposed to have said --- what does that make WinXP "a toy operating system that doesn't reboot so often"?

Heh.

[soporific]

I got this email from someone just recently, I thought I'd post for the information and hopefully the solution for all to read...

email 1

I have installed your Auto-patcher for Windows 98SE, latest edition downloaded some days ago, on two computers.

It worked perfectly on one, but doesn't run on the other. Both have Win98SE installed from the same installation CD.

Config.sys and Autoexec.bat are almost the same (the "PATH" is the same in both Autoexec.bat).

Auto-patcher is installed under the same location on both computers.

One is an older lap-top and the Auto-patcher worked without problems. The other is a very new and fast desktop on which I have Win98SE + Windows 2000 Pro in a dual-boot.

On the desktop I get, when I double-click StartPch.bat: "Bad command or file name"...

I have compared the installations of the Auto-patcher, and they seem identical. I have uninstalled and again installed the Auto-patcher, but it doesn't help.

Kind regards and thanks a lot in advance

email 2

I again uninstalled Autopatcher 1.8 and installed it anew in C:\Autopach instead of the location proposed by your program. It didn't help. All essential entries are the same on both computers in CONFIG.SYS, AUTOEXEC.BAT and MSDOS.SYS.

Just to try, I then double-clicked AutoPach.bat instead, but it reported that a parameter is missing.

If I understand right, ASET.EXE locates where Auto-patcher is installed and then sets a parameter indicated by %LOCATE%.

Could it be that that parameter becomes wrong? Could I not run AutoPach.bat with a manually added parameter? Which should the parameter be?

The new and fast desktop has a motherboard that is not really designed for Win98SE and 2 GB RAM. Win98SE first didn't install because it cannot handle so much RAM. So I took one RAM bar out, and then it installed. After putting the second RAM bar back in, it still worked. (I found this trick in the Internet.) But I find it hard to believe that this would affect running the Auto-patcher.

In CONFIG.SYS I have the entry DEVICE=C:\WINDOWS\EMM386.EXE V. If I add NOEMS, it doesn't boot and reports problems which will have to do with too much RAM (the same report I had when I tried to install the first time with 2 GB RAM). So I leave NOEMS out. If I leave it out on the lap-top, Auto-patcher still runs, anyway... So that will not cause the problem.

Kind regards

Hmmm, OK lets try a few things:

1) Turn on debugging - if you edit any of the .bat files in the CODE folder you'll see a variable setting near the top -- SET DEBUG=N ... change this to SET DEBUG=Y (the text case doesn't matter) --- but in your case this isn't going to help much because your problem is way before any debugging can start. However, I have modified StartPch.bat to include debugging and I've already turned it on. Download the attachment and overwrite the appropriate file in the program folder. Run the program as normal and the two essential variables that should be the cause of the problem will be shown for you to see. Report back how you go and what happened.

2) Find the program directory and open the CODE folder. Now open a command prompt (and you should already be at the CODE folder in DOS) and type "Autopach <Locate>" where Locate is the path to the program directory. Eg if the program is in c:\autopach then use "autopach c:\autopach" and see what happens

3) Don't use the COMSPEC variable in StartPch --- replace %COMSPEC% with c:\windows\command.com or whatever the path is to command.com and see what happens.

4) The only other thing I can think of is that this is a disk drive problem --- and that your shiny new motherboard is making my DOS programming go haywire.

See how you go with all that ...

Sop.

StartPch.zip

Edited February 2, 2007 by soporific

[soporific]

The "Installation count" feature I mentioned in an earlier post has now been implemented. And also I've done a significant clean up of the program code --- my goodness there were some weird leftovers from previous incarnations of this project. But in particular, the program was using multiple locations OUTSIDE of the program location to do some stuff. No more. Only one file is now created outside of the program folder and that is to restart the program after a reboot. It is written to the root of the C drive and is deleted before the end of the autopach process.

As soon as I have tested the new code for stability, I'll release a v1.9 update containing all the new stuff. Should be only a few days... i'm probably going to release the next full version as Preview Release 2 and hopefully just rename it to Final if no bugs are forthcoming ...

Now to the point, while I'm still around:

- negotiat.dll 5.00.2195.1 (Win2000)

- dscsetup.dll does not exist on my system However, in my Add/Remove panel I can clearly see "DS Client For Windows 98". Maybe it's an older version?

OK, firstly dscsetup.dll won't be on your system becuase its only used to install the update (i didn't check before suggesting it) And secondly, can you confirm you have the LATEST "DS Client For Windows 98" as apparently there are 4 or 5 versions floating around. Use my complete hotfixes list to get the download. If you install that manually and STILL get the update listed as missing in your report, I'll EAT MY SHORTS!! You may need to un-install the old one first, but tell me if you need to do that as that will make things a bit harder.

Edited February 2, 2007 by soporific

[soporific]

see the post above

Edited February 2, 2007 by soporific

[allesok]

I got this email from someone just recently, I thought I'd post for the information and hopefully the solution for all to read...

email 1

I have installed your Auto-patcher for Windows 98SE, latest edition downloaded some days ago, on two computers.

It worked perfectly on one, but doesn't run on the other. Both have Win98SE installed from the same installation CD.

Config.sys and Autoexec.bat are almost the same (the "PATH" is the same in both Autoexec.bat).

Auto-patcher is installed under the same location on both computers.

One is an older lap-top and the Auto-patcher worked without problems. The other is a very new and fast desktop on which I have Win98SE + Windows 2000 Pro in a dual-boot.

On the desktop I get, when I double-click StartPch.bat: "Bad command or file name"...

I have compared the installations of the Auto-patcher, and they seem identical. I have uninstalled and again installed the Auto-patcher, but it doesn't help.

Kind regards and thanks a lot in advance

email 2

I again uninstalled Autopatcher 1.8 and installed it anew in C:\Autopach instead of the location proposed by your program. It didn't help. All essential entries are the same on both computers in CONFIG.SYS, AUTOEXEC.BAT and MSDOS.SYS.

Just to try, I then double-clicked AutoPach.bat instead, but it reported that a parameter is missing.

If I understand right, ASET.EXE locates where Auto-patcher is installed and then sets a parameter indicated by %LOCATE%.

Could it be that that parameter becomes wrong? Could I not run AutoPach.bat with a manually added parameter? Which should the parameter be?

The new and fast desktop has a motherboard that is not really designed for Win98SE and 2 GB RAM. Win98SE first didn't install because it cannot handle so much RAM. So I took one RAM bar out, and then it installed. After putting the second RAM bar back in, it still worked. (I found this trick in the Internet.) But I find it hard to believe that this would affect running the Auto-patcher.

In CONFIG.SYS I have the entry DEVICE=C:\WINDOWS\EMM386.EXE V. If I add NOEMS, it doesn't boot and reports problems which will have to do with too much RAM (the same report I had when I tried to install the first time with 2 GB RAM). So I leave NOEMS out. If I leave it out on the lap-top, Auto-patcher still runs, anyway... So that will not cause the problem.

Kind regards

Hmmm, OK lets try a few things:

1) Turn on debugging - if you edit any of the .bat files in the CODE folder you'll see a variable setting near the top -- SET DEBUG=N ... change this to SET DEBUG=Y (the text case doesn't matter) --- but in your case this isn't going to help much because your problem is way before any debugging can start. However, I have modified StartPch.bat to include debugging and I've already turned it on. Download the attachment and overwrite the appropriate file in the program folder. Run the program as normal and the two essential variables that should be the cause of the problem will be shown for you to see. Report back how you go and what happened.

2) Find the program directory and open the CODE folder. Now open a command prompt (and you should already be at the CODE folder in DOS) and type "Autopach <Locate>" where Locate is the path to the program directory. Eg if the program is in c:\autopach then use "autopach c:\autopach" and see what happens

3) Don't use the COMSPEC variable in StartPch --- replace %COMSPEC% with c:\windows\command.com or whatever the path is to command.com and see what happens.

4) The only other thing I can think of is that this is a disk drive problem --- and that your shiny new motherboard is making my DOS programming go haywire.

See how you go with all that ...

Sop.

Thanks a lot fort your kind reply.

1. Debugging showed:

LOCATE is: C:\AUTOPACH

COMSPEC is: C:\COMMAND.COM

Press any key to continue

Bad command or file name

2. autopach c:\autopach gave:

Out of environment space

Out of environment space

C:\WINDOWS

Unfortunately this project version needs to be able to access the system drive!

Setup will now exit .... etc.

3. Replacing %COMSPEC% with C:\COMMAND.COM changed nothing.

Greetings

Jan Erik

[Drugwash]

OK, I scoured through all the official and unofficial updates I have around and I found a dsclient.exe package that contains negotiat.dll 5.00.2195.4784 - I suppose that's what the patcher's looking for. Haven't installed it yet, will do later on.

But now there's one question that springs to mind: could you make so that the report - as it should be as accurate as possible - would say that there is some version (and exactly which one) of the respective update installed, but not the latest?

I suppose that'd clear out some misunderstandings such as the current situation when user knows he's got something installed, the Add/Remove panel confirms, but the auto-patcher denies it. I agree it would add to the report's length, but IMHO it's worth it. Tell me what you think.

Oh and while we're at DS Client update, I've read somewhere around that the correct install order would be:

1. IE6-SP1

2. DUN 1.4 Upgrade

3. DS Client for Windows98

I hope this sequence is being followed in auto-patcher.

[soporific]

1. Debugging showed:

LOCATE is: C:\AUTOPACH

COMSPEC is: C:\COMMAND.COM

Press any key to continue

Bad command or file name

2. autopach c:\autopach gave:

Out of environment space

Out of environment space

C:\WINDOWS

Unfortunately this project version needs to be able to access the system drive!

Setup will now exit .... etc.

3. Replacing %COMSPEC% with C:\COMMAND.COM changed nothing.

OK, there may be two problems here --- 1, there may be a problem with how your computer is processing certain DOS commands, and 2, your computer may be going too fast for a particular routine that is critical for the program to work. In the attachment there is an update to AutoPach.bat that now has a delay included where the problem should be (if the problem is speed). Also included is a replacement start-up file called Manual_Start.bat which should be run from the same location as Startpch.bat --- there is less code to stuff things up. When you run the file it will tell you the instructions but here they are now -- you need to install the program (copying/moving the files is fine) to a specific location which is: c:\autopach

The other thing to try is to type out the 3rd last line of Manual_Start.bat in a DOS box and see what happens. ie type %COMSPEC% /E:2048 /C "C:\AUTOPACH\CODE\AUTOPACH.BAT" C:\AUTOPACH

But now there's one question that springs to mind: could you make so that the report - as it should be as accurate as possible - would say that there is some version (and exactly which one) of the respective update installed, but not the latest?

Can you give me an example of what you mean? I don't think this is possible because it would mean recording all this other extra info about each update, and I'm just not going to spend my time on that. Maybe I'm wrong which is why i'm asking for an example. I'm not worried in the slightest about long reports.

Oh and while we're at DS Client update, I've read somewhere around that the correct install order would be:

1. IE6-SP1

2. DUN 1.4 Upgrade

3. DS Client for Windows98

I hope this sequence is being followed in auto-patcher.

Nope, its:

1. DUN 1.4 Upgrade (Auto-Patcher asks you to install it first)

2. IE6-SP1

3. DS Client for Windows98

I haven't experienced any problems with this order. Anyone comment? If we could somehow get a silent installer for DUN14 we could choose the order.

Fix_for_no_start.zip

Edited February 2, 2007 by soporific

[Drugwash]

I've already given examples in my posts earlier: DUN 1.4, DS Client, 7-Zip (that one actually is a newer version, not older), 2GB patch (checkable only by extra version string, maybe)... I also offered the registry paths where their installation can be checked.

I'm thinking there may be - rare or not - reasons for someone not to install a certain version of an update, while he already has one installed that would serve the purpose and not interfere with the other updates.

In the case of DUN 1.4, for example, running the report would return "DUN 1.4 not installed" and then running it, auto-patcher would ask for its installation. The user may forget for a moment that he shouldn't do that (for some reason such as software conflicts or whatever) and he borks the system.

There's no need for deep digging if it would take too much; just saying "older version found" instead of "not installed" would be enough in such cases. Or just the version of the checked file, as in the above DS Client case, so the user would have a clue on what he got and what he should do further.

If you can't/won't do it, fine - it was just an idea.

[celtish]

Just out of interest, does your computer reboot to the desktop without having to log in or anything like that? I would imagine that for people who have to do something (ie press a button) for the desktop to finish loading would get a wee bit frustrated with all the reboots.

You're right but actually just as anxious as frustrated!

We talking Win98SE here, right? My machine always auto-reboots into Desktop albeit slowly because I have all the DOS windows showing up first each time. (Don't know if this is native Windows behaviour of whether it's because of some third-part programme e.g. X-Setup.)

Great programme!

[allesok]

OK, I scoured through all the official and unofficial updates I have around and I found a dsclient.exe package that contains negotiat.dll 5.00.2195.4784 - I suppose that's what the patcher's looking for. Haven't installed it yet, will do later on.

But now there's one question that springs to mind: could you make so that the report - as it should be as accurate as possible - would say that there is some version (and exactly which one) of the respective update installed, but not the latest?

I suppose that'd clear out some misunderstandings such as the current situation when user knows he's got something installed, the Add/Remove panel confirms, but the auto-patcher denies it. I agree it would add to the report's length, but IMHO it's worth it. Tell me what you think.

Oh and while we're at DS Client update, I've read somewhere around that the correct install order would be:

1. IE6-SP1

2. DUN 1.4 Upgrade

3. DS Client for Windows98

I hope this sequence is being followed in auto-patcher.

I have put the new AutoPach.bat in, in place of the old one, and also Manual_Start.bat.

No matter if I run the latter or Startpch.bat, I always get: "Bad command or file name".

I also tried running %COMSPEC% /E:2048 /C "C:\AUTOPACH\CODE\AUTOPACH.BAT" C:\AUTOPACH

from DOS, with the same result.

I suppose that there is a problem with memory handling under Win98SE and DOS in my desktop. Even though I have essentially the same settings in CONFIG.SYS and AUTOEXEC.BAT on both computers. If I in SYSTEM.INI leave out MaxPhysPage under [386Enh], Win98SE doesn't boot. If I set it at MaxPhysPage=40000 (which appears to be the maximum accepted), it boots. I tried MaxPhysPage=3C000 (1 GB, using only the first RAM bar), and that was OK. I tried MaxPhysPage=20000 (512 MB) and then Startpch.bat reported that there would be too little memory to run it! But in the lap-top I have only 64 MB RAM... and that works...

One of these days I'll try taking out the second 1GB RAM bar and leave out MaxPhysPage, but I would be surprised if it would help...

One more thing I may try later, not expecting much from it, is this. Just a wild guess. Since I run Win98SE and Win2000Pro in dual-boot, I also have a neat application "MountEvereything 3", which allows Win98SE to both read from and write to NTFS. Thus Win98SE works as a "boot CD on the harddisk" for Win2000. This is a main reason why I wish to have both (it is rarely but sometimes useful for doing something in Win2000, one very simple example: If a file refuses to be deleted in Win2000, being "in use", I can delete it from Win98SE, it can also be useful for certain forms of patching experiments). Who knows how much memory that application uses... I may try to uninstall MountEverything and run Auto-patcher, and then reinstall MountEverything. But again I would be surprised if that works.

Does anyone have any further advice?

Thanks for taking time for me

JE

[SoftPedia]

its only been up for a day or so and already hundreds have downloaded it, and the page has been viewed by nearly a thousand, so a big thank you to Randy Rivers for uploading the program to SoftPedia (it was you wasn't it?) and it's also listed in the 'Week's best' column to the right of the Windows apps section.

Are you sure it was him?

Did you receive our award notification email?

[soporific]

Did you receive our award notification email?

Yes i did, thanks !

[soporific]

Known bugs in v1.9 BETA

* i've somehow managed to break the report function in v1.9 BETA --- will fix ASAP.

Edited February 5, 2007 by soporific

[allesok]

1. Debugging showed:

LOCATE is: C:\AUTOPACH

COMSPEC is: C:\COMMAND.COM

Press any key to continue

Bad command or file name

2. autopach c:\autopach gave:

Out of environment space

Out of environment space

C:\WINDOWS

Unfortunately this project version needs to be able to access the system drive!

Setup will now exit .... etc.

3. Replacing %COMSPEC% with C:\COMMAND.COM changed nothing.

OK, there may be two problems here --- 1, there may be a problem with how your computer is processing certain DOS commands, and 2, your computer may be going too fast for a particular routine that is critical for the program to work. In the attachment there is an update to AutoPach.bat that now has a delay included where the problem should be (if the problem is speed). Also included is a replacement start-up file called Manual_Start.bat which should be run from the same location as Startpch.bat --- there is less code to stuff things up. When you run the file it will tell you the instructions but here they are now -- you need to install the program (copying/moving the files is fine) to a specific location which is: c:\autopach

The other thing to try is to type out the 3rd last line of Manual_Start.bat in a DOS box and see what happens. ie type %COMSPEC% /E:2048 /C "C:\AUTOPACH\CODE\AUTOPACH.BAT" C:\AUTOPACH

But now there's one question that springs to mind: could you make so that the report - as it should be as accurate as possible - would say that there is some version (and exactly which one) of the respective update installed, but not the latest?

Can you give me an example of what you mean? I don't think this is possible because it would mean recording all this other extra info about each update, and I'm just not going to spend my time on that. Maybe I'm wrong which is why i'm asking for an example. I'm not worried in the slightest about long reports.

Oh and while we're at DS Client update, I've read somewhere around that the correct install order would be:

1. IE6-SP1

2. DUN 1.4 Upgrade

3. DS Client for Windows98

I hope this sequence is being followed in auto-patcher.

Nope, its:

1. DUN 1.4 Upgrade (Auto-Patcher asks you to install it first)

2. IE6-SP1

3. DS Client for Windows98

I haven't experienced any problems with this order. Anyone comment? If we could somehow get a silent installer for DUN14 we could choose the order.

I got my answer under the wrong quote...

So I repeat it:

I have put the new AutoPach.bat in, in place of the old one, and also Manual_Start.bat.

No matter if I run the latter or Startpch.bat, I always get: "Bad command or file name".

I also tried running %COMSPEC% /E:2048 /C "C:\AUTOPACH\CODE\AUTOPACH.BAT" C:\AUTOPACH

from DOS, with the same result.

I suppose that there is a problem with memory handling under Win98SE and DOS in my desktop. Even though I have essentially the same settings in CONFIG.SYS and AUTOEXEC.BAT on both computers. If I in SYSTEM.INI leave out MaxPhysPage under [386Enh], Win98SE doesn't boot. If I set it at MaxPhysPage=40000 (which appears to be the maximum accepted), it boots. I tried MaxPhysPage=3C000 (1 GB, using only the first RAM bar), and that was OK. I tried MaxPhysPage=20000 (512 MB) and then Startpch.bat reported that there would be too little memory to run it! But in the lap-top I have only 64 MB RAM... and that works...

One of these days I'll try taking out the second 1GB RAM bar and leave out MaxPhysPage, but I would be surprised if it would help...

One more thing I may try later, not expecting much from it, is this. Just a wild guess. Since I run Win98SE and Win2000Pro in dual-boot, I also have a neat application "MountEvereything 3", which allows Win98SE to both read from and write to NTFS. Thus Win98SE works as a "boot CD on the harddisk" for Win2000. This is a main reason why I wish to have both (it is rarely but sometimes useful for doing something in Win2000, one very simple example: If a file refuses to be deleted in Win2000, being "in use", I can delete it from Win98SE, it can also be useful for certain forms of patching experiments). Who knows how much memory that application uses... I may try to uninstall MountEverything and run Auto-patcher, and then reinstall MountEverything. But again I would be surprised if that works.

Does anyone have any further advice?

Thanks for taking time for me

JE

[Drugwash]

@ soporific:

Looking through AutoPach.bat, I see you're checking for DUN 1.4 presence by %windir%\msdun\msdun98.cat. One glance and I noticed MSDUNSE.INF in the same folder, which contains the following lines:

OLD_DUN_VERSION = "2.1"

NEW_DUN_VERSION = "2.2"

I guess this would be enough information to know both previous and current versions of DUN, in case you decide to raise report verbosity or just to make sure the right version is installed.

However, you're looking for the string 6,660 (representing file length) in DIR "%windir%\msdun\msdun98.cat" | Find /i "6,660" >nul, which it cannot find, because of two reasons:

1. Syntax is incorrect - the right one is DIR "%windir%\msdun" | Find /i "6,660" >nul (without the catalog file name)

2. My regional settings that swap the decimal symbol with the digit grouping symbol. So the right string to search for would be "6.660", but this is only available on certain Windows setups. Apparently you have to change the detection routine to something that doesn't rely on variable settings, or at least perform the same operation twice, with the two different strings.

I'll do further digging.