Auto-Patcher For Windows 98se (English)

[celtish]

I've only just installed the 6.54 update - is it worthwhile to install the 6.55 update or will there be a lot of duplication?

postscriptum - please see my post earlier today which includes the log files on the three earlier version I installed

Post-postscriptum - I went ahead and installed the 6.55 and got a bundle of problems including 'explorer' error messages, 'cannot find drive C' as well as the usual 'out of environmental space' message at the head of every DOS window

Edited May 30, 2007 by plonkeroo

[soporific]

I've only just installed the 6.54 update - is it worthwhile to install the 6.55 update or will there be a lot of duplication?

postscriptum - please see my post earlier today which includes the log files on the three earlier version I installed

Post-postscriptum - I went ahead and installed the 6.55 and got a bundle of problems including 'explorer' error messages, 'cannot find drive C' as well as the usual 'out of environmental space' message at the head of every DOS window

jeepers. can you do the same as nathanson1947 and run SYSEDIT from the run dialog box and post me the text inside AUTOEXEC.BAT (post as a PM). Thanks.

NEWS: it seems i still have some work to do to solve these ES errors. I didn't have much time to test 1.96.55 out last night and its still bringing up errors. Even Just trying to set DEBUG=Y inside START_ME.bat brings up an ES message - I have to trap the Out of environment space messages everywhere, and not just where i have so far. So please bear with me.

Please only install the latest updates if you want to help solve these ES problems.

OK, the main problem is now this: if the user has used up all of the normal ES space, unless the first file (START_ME.bat) is started with its own space allocation, there is no more space to assign the necessary variables for the program to work normally. Using nathanson1947's AUTOEXEC.BAT file (with some very long PATH statements) the program can't even set DEBUG=N and so things immediately stuff up. The entire point of START_ME.bat was to give enough space to AUTOPACH.bat so all the variables would be set properly. Now the problem is I have to do this for START_ME.bat which is going to be tricky. That or i just save the path statement to a text file and reset it for the autopatch session and then reassign it at the end. Yep, i''l try that out first ... back soon ...

Well, it works ... so this is now what happens:

START_ME.bat is started and it tries to assign DEBUG=N --- the very next line it tries to find that variable and if fails, goes to the fix section. Your PATH statement is reset to the bare minimum (ie SET PATH=%windir%\command) and then the process is tried again. If you fail twice you get a message and are invited to quit. It seems to work! But i'm testing some more before posting ...

EDIT: its looking good ... -- i'm quite proud of this fix actually. It doesn't matter what sort of system you throw at me, my AP will work if its the last thing i ever do !!

Edited May 30, 2007 by soporific

[nathanson1947]

Greetings.

Firstly, thank you, Soporific, for the new AUTOEXEC.BAT text . The "too many parameters" message has been around for at least a year. The gtk was installed so that I could run the Gimp, and somehow it got installed incorrectly. I don't know if there is a connection, but I have noticed that my computer has had a tendency to crash any time I tried to view three dimensional images. Of course, that particular problem could also be due to the fact that I only have 224 MB of RAM.

In any case, after fixing AUTOEXEC.BAT, I installed and tried version 1.96.55. It worked for a while until it eventually aborted. I have attached the log file.

Jack

I_Result.Log_for_version_1.96.55.txt

[soporific]

Firstly, thank you, Soporific, for the new AUTOEXEC.BAT text . The "too many parameters" message has been around for at least a year. The gtk was installed so that I could run the Gimp, and somehow it got installed incorrectly. I don't know if there is a connection, but I have noticed that my computer has had a tendency to crash any time I tried to view three dimensional images. Of course, that particular problem could also be due to the fact that I only have 224 MB of RAM.

In any case, after fixing AUTOEXEC.BAT, I installed and tried version 1.96.55. It worked for a while until it eventually aborted. I have attached the log file.

Jack, glad to be of help. Re: v1.96.55 i know why it doesn't work ... i'm just testing out the ultimate ES error proof version now ... its way cool !! Back soon ...

[celtish]

... Run SYSEDIT from the run dialog box and post me the text inside AUTOEXEC.BAT (post as a PM) ...

Herewith (sorry, can't find PM sender)

C:\PROGRA~1\GRISOFT\AVG7\BOOTUP.EXE (AVG Scanner)

SET TEMP=C:\windows\temp (Found to be necessary)

SET TMP=C:\windows\temp (Found to be necessary)

SET TVDUMPFLAGS=8 (ZoneAlarm)

SET PHPRC=C:\PHP

SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\;C:\WINDOWS\SYSTEM;C:\PROGRA~1\COMMON~1\ROXIOS~1\DLLSHA~1;C:\PERL\SITE\BIN;C:\PERL\BIN

mode con codepage prepare=((850) C:\WINDOWS\COMMAND\ega.cpi)

mode con codepage select=850

keyb uk,,C:\WINDOWS\COMMAND\keyboard.sys

Keep up the good work, you're a genius at work!

[soporific]

SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\;C:\WINDOWS\SYSTEM;C:\PROGRA~1\COMMON~1\ROXIOS~1\DLLSHA~1;C:\PERL\SITE\BIN;C:\PERL\BIN

what is it with people and their humungous PATH statements in their AUTOEXEC.BAT files ? No offense Plonk me mate ... OK this advice is the definite way to temporarily solve most AP problems where it just exits out ungracefully.

If the following is true:

1) When you use AP, especially the 1.96 upgrade, it doesn't reach the end, or it doesn't even start, or you see "Out of environment space" messages.

2) Inside your AUTOEXEC.BAT file you have a "SET PATH= ...." or "SET CLASSPATH= ..." that is quite a long string of text.

You can by-pass this problem by doing the following:

1) go to START - RUN and in the Run dialog box type SYSEDIT and hit return (enter)

-- this brings up all your configuration files into like notepad type windows

2) choose the AUTOEXEC.BAT window, and any line that starts with "SET PATH= ...." or "SET CLASSPATH= ..." put the word "REM" at the start of the line.

eg

if your AUTOEXEC.BAT looks like the following:

SET BLASTER=A260 I9 D3 H3 T4

SET PATH=%PATH%;c:\progra~1\common~1\gtk\2.0\bin

SET Path=%Path%;"C:\Program Files\Executive Software\DiskeeperLite\"

SET OGRE_HOME=c:\OgreSDK

SET CLASSPATH=.;C:\PROGRA~1\ARTOFI~1\LIB\SOUND.JAR;C:\PROGRA~1\ARTOFI~1\LIB;C:\PROGRA~1\ARTOFI~1\LIB\JMF.JAR

you would then add REM words like this:

REM SET BLASTER=A260 I9 D3 H3 T4

REM SET PATH=%PATH%;c:\progra~1\common~1\gtk\2.0\bin

REM SET Path=%Path%;"C:\Program Files\Executive Software\DiskeeperLite\"

REM SET OGRE_HOME=c:\OgreSDK

REM SET CLASSPATH=.;C:\PROGRA~1\ARTOFI~1\LIB\SOUND.JAR;C:\PROGRA~1\ARTOFI~1\LIB;C:\PROGRA~1\ARTOFI~1\LIB\JMF.JAR

you don't have to REM out all the lines, just do the really big one that is causing all the fuss !! After you use AP, just return your AUTOEXEC.BAT file to the way it was by taking out the REMs. What is the effect of adding REMs? What will happen? You were wondering weren't you... it just means that the particular program that 'installed' that PATH statement (or whichever variable it is) won't be able to run normally while that REM word is there. SO this means that if a anti-virus program has added a line then maybe keep that unREMmed. Again, the easiest thing is just to REM out one line --- which line? The longest line! That's right, you there at the back.

I am writing a function that will do this as a menu option and or if you fail the ES test but until then, everybody in this situation, this is what you do!

Edited May 30, 2007 by soporific

[celtish]

@ soporific

I am writing a function that will do this as a menu option and or if you fail the ES test but until then, everybody in this situation, this is what you do!

An auto like that would certainly be useful but I've recently had a lot of grief with autoexec.bat - it periodically wipes itself clean meaning that when next rebooting the machine just flounders. See this topic at http://www.msfn.org/board/index.php?showto...st&p=659718 . A respondent wrote me a .vbs file which would reinstate its contents from autoexec.bak if it blanked out again. It must be working because this particular problem hasn't arisen since. Would the .vbs file be compatible with your proposed fix in AP? And what if AP floundered during install and left the autoexec.bat in its 'REM' state? (Sounds convoluted I know but d'you understand what I'm saying?)

(BTW, what does 'ES' mean??)

Edited May 30, 2007 by plonkeroo

[Mazabuka]

SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\;C:\WINDOWS\SYSTEM;C:\PROGRA~1\COMMON~1\ROXIOS~1\DLLSHA~1;C:\PERL\SITE\BIN;C:\PERL\BIN

what is it with people and their humungous PATH statements in their AUTOEXEC.BAT files ? No offense Plonk me mate ... OK this advice is the definite way to temporarily solve most AP problems where it just exits out ungracefully.

If the following is true:

1) When you use AP, especially the 1.96 upgrade, it doesn't reach the end, or it doesn't even start, or you see "Out of environment space" messages.

2) Inside your AUTOEXEC.BAT file you have a "SET PATH= ...." or "SET CLASSPATH= ..." that is quite a long string of text.

You can by-pass this problem by doing the following:

1) go to START - RUN and in the Run dialog box type SYSEDIT and hit return (enter)

-- this brings up all your configuration files into like notepad type windows

2) choose the AUTOEXEC.BAT window, and any line that starts with "SET PATH= ...." or "SET CLASSPATH= ..." put the word "REM" at the start of the line.

eg

if your AUTOEXEC.BAT looks like the following:

SET BLASTER=A260 I9 D3 H3 T4

SET PATH=%PATH%;c:\progra~1\common~1\gtk\2.0\bin

SET Path=%Path%;"C:\Program Files\Executive Software\DiskeeperLite\"

SET OGRE_HOME=c:\OgreSDK

SET CLASSPATH=.;C:\PROGRA~1\ARTOFI~1\LIB\SOUND.JAR;C:\PROGRA~1\ARTOFI~1\LIB;C:\PROGRA~1\ARTOFI~1\LIB\JMF.JAR

you would then add REM words like this:

REM SET BLASTER=A260 I9 D3 H3 T4

REM SET PATH=%PATH%;c:\progra~1\common~1\gtk\2.0\bin

REM SET Path=%Path%;"C:\Program Files\Executive Software\DiskeeperLite\"

REM SET OGRE_HOME=c:\OgreSDK

REM SET CLASSPATH=.;C:\PROGRA~1\ARTOFI~1\LIB\SOUND.JAR;C:\PROGRA~1\ARTOFI~1\LIB;C:\PROGRA~1\ARTOFI~1\LIB\JMF.JAR

you don't have to REM out all the lines, just do the really big one that is causing all the fuss !! After you use AP, just return your AUTOEXEC.BAT file to the way it was by taking out the REMs. What is the effect of adding REMs? What will happen? You were wondering weren't you... it just means that the particular program that 'installed' that PATH statement (or whichever variable it is) won't be able to run normally while that REM word is there. SO this means that if a anti-virus program has added a line then maybe keep that unREMmed. Again, the easiest thing is just to REM out one line --- which line? The longest line! That's right, you there at the back.

I am writing a function that will do this as a menu option and or if you fail the ES test but until then, everybody in this situation, this is what you do!

Soporific. Last night I spent some time working with AP 1.96.52 because this version contains the "debugging" code you inserted for Nathanson1947, I think it was, saving me the trouble of having to insert the code myself.

In running my tests I made use of "Strings.com" as well as the "Set" command which I used to list the environment variables that were defined at the time I invoked the Set command, the output of which was redirected to a text file.

The results of the limited testing I did were very interesting and showed that the "Start.exe" command that you use to launch some of your batch files does not function in the way one would expect. The use of Start.exe is (was?) in fact one of the reasons that AP unexpectedly runs out of ES.

Here's an extract of some of the code from AP 1.95.55 AutoPatch.bat =>

:RESTART8
:: pause a bit
"%LOC8%\bin\WAIT" 1.2

:: clear environment values starting the next file to ensure variables don't have a 'no memory' excuse for not setting.
FOR %%! in (ZZ ZY ZX) DO SET MD%%!=
FOR %%! in (00 01 02 03 04 05 06 07) DO SET MD%%!=
FOR %%! in (08 09 10 11 12 13 14 15 16) DO SET MD%%!=
FOR %%! in (0201 0202 0203 0204 0205 0206 0207 0208 0209) DO SET OP%%!=
FOR %%! in (0601 0602 0603 0604) DO SET OP%%!=
FOR %%! in (0901 0902 0903 0904 0905 0906) DO SET OP%%!=
FOR %%! in (1201 1202 1203 1204 1205) DO SET OP%%!=
FOR %%! in (1401 1402 1403 1404 1405 1406 1407 1408 1409 1410) DO SET OP%%!=
FOR %%! in (1411) DO SET OP%%!=
FOR %%! in (1501 1502 1503 1504 1505 1506 1507) DO SET OP%%!=
FOR %%! in (WillBe WontBe NoSave YeSave CULOR MM) DO SET %%!=
FOR %%! in (MyDayN MyDay MyMon MyYear NSec NMin NHour) DO SET %%!=

:: start the current module
START %COMSPEC% /E:2048 /K "%LOC8%\code\Run-Mod.bat" Fullup %WINDRIVE% %WINDODIR% "%LOC8%"

Because Start.exe does make use of the environment space available to AutoPatch.bat, nor the variables defined within AutoPatch.bat, nor those defined within the Batch files that launched AutoPatch.bat, clearing the environment variables using the FOR loops shown above does not make additional ES space available to Run-Mod.bat prior to it being launched. In other words, had you left your code the way you had it in versions of AP prior to 1.96.55, you would have achieved exactly the same result as you do with AP 1.96.55. So AP 1.96.55's code would be just as effective written this way =>

:RESTART8
:: pause a bit
"%LOC8%\bin\WAIT" 1.2

:: start the current module
START %COMSPEC% /E:2048 /K "%LOC8%\code\Run-Mod.bat" Fullup %WINDRIVE% %WINDODIR% "%LOC8%"

:: clear environment values starting the next file to ensure variables don't have a 'no memory' excuse for not setting.
FOR %%! in (ZZ ZY ZX) DO SET MD%%!=
FOR %%! in (00 01 02 03 04 05 06 07) DO SET MD%%!=
FOR %%! in (08 09 10 11 12 13 14 15 16) DO SET MD%%!=
FOR %%! in (0201 0202 0203 0204 0205 0206 0207 0208 0209) DO SET OP%%!=
FOR %%! in (0601 0602 0603 0604) DO SET OP%%!=
FOR %%! in (0901 0902 0903 0904 0905 0906) DO SET OP%%!=
FOR %%! in (1201 1202 1203 1204 1205) DO SET OP%%!=
FOR %%! in (1401 1402 1403 1404 1405 1406 1407 1408 1409 1410) DO SET OP%%!=
FOR %%! in (1411) DO SET OP%%!=
FOR %%! in (1501 1502 1503 1504 1505 1506 1507) DO SET OP%%!=
FOR %%! in (WillBe WontBe NoSave YeSave CULOR MM) DO SET %%!=
FOR %%! in (MyDayN MyDay MyMon MyYear NSec NMin NHour) DO SET %%!=

Before I get into any explanations, I think it best to describe the tests I set up.

First test

I modified the code in AutoPatch.bat as follows:

:: start the current module
c:\Program Files\AutoPatch98\Bin\Strings envsize
c:\Program Files\AutoPatch98\Bin\Strings envfree
set > "c:\Program Files\AutoPatch98\Logs\envpatch.txt"
pause
START "%LOC8%\code\Run-Mod.bat" Fullup %WINDRIVE% %WINDODIR% "%LOC8%"
%WINDODIR% "%LOC8%"
pause
Goto End

In Run-Mod.bat, after the CLS command I inserted the following code:

c:\Program Files\AutoPatch98\Bin\Strings envsize
c:\Program Files\AutoPatch98\Bin\Strings envfree
set > "c:\Program Files\AutoPatch98\Logs\envmod.txt"
pause

2nd Test

I modified the code in AutoPatch.bat as follows:

:: start the current module
c:\Program Files\AutoPatch98\Bin\Strings envsize
c:\Program Files\AutoPatch98\Bin\Strings envfree
set > "c:\Program Files\AutoPatch98\Logs\envpatch.txt"
pause
CALL "%LOC8%\code\Run-Mod.bat" Fullup %WINDRIVE% %WINDODIR% "%LOC8%"
pause
Goto End

In Run-Mod.bat, after the CLS command I inserted the following code:

c:\Program Files\AutoPatch98\Bin\Strings envsize
c:\Program Files\AutoPatch98\Bin\Strings envfree
set > "c:\Program Files\AutoPatch98\Logs\envmod.txt"
pause

Results of 1st Test

Run-Mod.bat gave two "out of environment space" warnings

Envsize in AutoPatch.bat was 4112 bytes

Envfree in AutoPatch.bat was 2330 bytes

Envpatch.txt listed all the environment variables that had been defined by AP prior to Run-Mod.bat being invoked

Envsize in Run-Mod.bat was 1456 bytes

Envfree in Run-Mod.bat was 1008 bytes

Envmod.txt did not list any of the environment variables that had been defined by AP prior to Run-Mod being invoked.

This was a very suprising result to me because I had expected Envsize to be the same in both AutoPatch.bat and Run-Mod.bat. I had also expected the contents of Envmod.txt to be exactly the same as those in Envpatch.txt which they were not.

Results of 2nd Test

Run-Mod.bat did not give any "out of environment space" warnings

Envsize in AutoPatch.bat was 4112 bytes

Envfree in AutoPatch.bat was 2330 bytes

Envpatch.txt listed all the environment variables that had been defined by AP prior to Run-Mod.bat being invoked

Envsize in Run-Mod.bat was 4112 bytes

Envfree in Run-Mod.bat was 2330 bytes

Envmod.txt listed exactly the same set of environment variables as those listed Envpatch.txt

This result was in line with what I had expected. It was also the result I had expected from the 1st test.

Also you can see that using CALL instead of START to launch Run-Mod.bat resolved the "out of environment space" warnings previously output by Run-Mod.bat in the 1st test.

Ok, so what's going on here?

Before I can answer that I need to provide another piece of information.

In the first test the values of Envsize and Envfree in Run-Mod.bat as well as the contents of Envmod.txt were strangely familiar to me. After some time puzzling over the familiarity, I realised that the values of Envsize and Envfree were exactly the same values I would get if I used Strings.com to check my environment space immediately after booting up SE. In addition, the environment variables listed in Envmod.txt were exactly same as those that would be listed if I used the Set command to list the environment variables defined immediately after booting up SE.

Taking cognisance of everthing I described above, here's what I conclude from my tests =>

1. Start.exe actually spawns Run-mod.bat off as a separate process that is totally independent of AutoPatch.bat
   
2. Because Run-mod.bat is spawned off as a separate process, SE has to allocate it an initial amount of ES space. By default the amount of space allocated is exactly the same as that allocated at the time SE boots up.
   
3. Because Run-mod.bat is spawned off as a separate process, the environment variables defined in AP are not available to Run-mod.bat as global variables. The only environment variables available to Run-Mod.bat are those defined at the time SE boots up, and those passed as parameters to Run-Mod.bat.
   
4. A command such as
   

   START %COMSPEC% /E:2048 /K "%LOC8%\code\Run-Mod.bat" Fullup %WINDRIVE%

   
   can only be used in situations where the batch file being launched does not need to make use of more than 8 (or is it 9?) environment variables defined by AP prior to launching the batch file. The values of the environment variables can of course be passed as parameters to the batch file as happens in this particular command, but then no more than 8 (9?) values can be passed in this way
   

5. If on being launched the batch file needs to make use of more than 8 (9?) environment variables, then the CALL command must be used instead of the START command. If the CALL command is used, then the amount of free environment space available to the batch file being launched will be the same or similar to that available in the batch file that initiated the launch
   

Edited June 3, 2007 by Tarun
Shrank post size by adding codeboxes.

[Kelsenellenelvian]

man CODE TAGS!!!

[soporific]

Taking cognisance of everthing I described above, here's what I conclude from my tests =>

1. Start.exe actually spawns Run-mod.bat off as a separate process that is totally independent of AutoPatch.bat

2. Because Run-mod.bat is spawned off as a separate process, SE has to allocate it an initial amount of ES space. By default the amount of space allocated is exactly the same as that allocated at the time SE boots up.

3. Because Run-mod.bat is spawned off as a separate process, the environment variables defined in AP are not available to Run-mod.bat as global variables. The only environment variables available to Run-Mod.bat are those defined at the time SE boots up, and those passed as parameters to Run-Mod.bat.

4. A command such as

START %COMSPEC% /E:2048 /K "%LOC8%\code\Run-Mod.bat" Fullup %WINDRIVE%

can only be used in situations where the batch file being launched does not need to make use of more than 8 (or is it 9?) environment variables defined by AP prior to launching the batch file. The values of the environment variables can of course be passed as parameters to the batch file as happens in this particular command, but then no more than 8 (9?) values can be passed in this way

5. If on being launched the batch file needs to make use of more than 8 (9?) environment variables, then the CALL command must be used instead of the START command. If the CALL command is used, then the amount of free environment space available to the batch file being launched will be the same or similar to that available in the batch file that initiated the launch

That's excellent investigation ... i was trying lots of things all over the place without pausing to think it through ... eg clearing the variables before running the next bat file ... as you noticed i only recently did that to try to solve the problems. I never did quite get a complete handle on everything to do with environment space (ES) so this post is a wealth of information. I completely buggered up my current version of code last night as i was trying to fix this problem so i'm going to totally junk last nights work and start again using the above info. Maybe another version later today...

PS - please trim your posts a little before posting. --- and these are some useful tags to use: [ quote ] & [ /quote ] and [ code ] & [ /code ] but without the spaces.

eg

example using "quote"

 example using "code"

it helps navigation and readability! Thanks again for such an awesome post!

[submix8c]

soporific :

Actually, I have always wondered why you utilized "START" as opposed to "CALL", as this is the exact reason for "skipping" from one DOS screen to the next. The bad news is you would probably have to revamp a huge amount of code, i.e. restructuring as follows (an simplified example only) :

- Initialize first-time/default variables

- Overlay with Saved variables/selections

- Display selections screen

- Read-in selections

- Test selections (against Force?) and Set Selections / Reinitalize Screen

- Install Selected (ONLY!)

- All done (throw up the report)

Sorry if this seems simplified but (this is NOT a slam!) more than likely you have modded the original AP from the "first draft" that was never envisioned to go this far! If you had originally had the time you would more than likely followed "old school" methodology of "How do I structure this" (Structured Programming 101, flowcharts and all) and wrote AP accordingly.

This has always been the bane of a good programmer's existence; a user says "Quick! I need something to do such-and-such", you whip it together post-haste, then other peeps see it and go "Wow! Do this, too!" and you do. Finally you wind up with "Oh, man this is cludgy! Should I completely rewrite it so it makes more sense?".

Don't feel like you're the only one. I've wound up completely revamping several entire (mainframe) subsystems just so it worked more efficiently AND was easier to maintain/enhance. I had found many instances of "clone" code that I had to rip out and place into common "called" subroutines, even changed the programming language. I even coded in my sleep!

Take heart, bud; there IS light at the end of the tunnel (not the train)! Once you have THIS version bug-free, THEN breathe easy, take a step back, rethink, and (maybe) rewrite "silently" (v2.0 that is easier to patch-up/enhance?). It may be worth your while to check into "CALL" vs "START" and using more modularization of those pariticular modules (the Process Selections ones).

Edited May 31, 2007 by submix8c

[soporific]

Take heart, bud; there IS light at the end of the tunnel (not the train)! Once you have THIS version bug-free, THEN breathe easy, take a step back, rethink, and (maybe) rewrite "silently" (v2.0 that is easier to patch-up/enhance?). It may be worth your while to check into "CALL" vs "START" and using more modularization of those pariticular modules (the Process Selections ones).

Thanks for your comments, don't worry i have already taken a little break, i haven't touched the code for a full day ... towards the end there i was going totally stir crazy -- my 'builds' were getting progressively worse ... i've actually worked out where and when all the problems started ... i was using %COMSPEC% /C in all places and only recently changed some of them to %COMSPEC% /K but Mazabuka and yourself have correctly pointed out i should have been using CALL instead. I will return to this tomorrow and hopefully a version soon ... thanks again for the words of encouragement.

EDIT: i meant to say 'changed to %COMSPEC% /K' in the post above (i have made the change)

Edited June 1, 2007 by soporific

[soporific]

NEWS: hoh boy, the new version rocks. No more DOS windows dancing around the screen!! I've never been able to compare the two methods before and i must say i like the screen staying where it is the entire time. It doesn't move once! I've finally got some semblance of control over my pet bat files, naughty little buggers they are. Run-Mod.bat has been fired and shown the door. Totally surplus to requirements. And Fullup.bat, always the odd one out in the modules folder (its not a modules file), has been moved up a directory level where it always should have been, and renamed ModMenu.bat

The other improvement is the report function now reports more missing updates. It wasn't counting the ones that you couldn't install because other things were missing. It is usually only a few updates so its easy to miss. It will mean some of your figures of what is actually missing compared to what the report says, will now make sense. Hopefully.

So thanks for all the most recent posts, the new version is much better as a result. It will be out soon ...

Edited June 2, 2007 by soporific

[submix8c]

soporific :

I just knew you could get it squared away! Congratulations .

But, dang it now I have to wait...

Oh well; never rush the cook, eh? ("Earned" my star and am now a Junior! have a decent signature now and will scan the JusTus back-drop and add it soon...)

[soporific]

But, dang it now I have to wait...

Yes, yes you do. You may find this funny ... a bug i just fixed then: I have a function called NiceTime that converts a 6 digit time into something less specific .. ie a nice time. Anyway, it rounds the seconds either up or down depending if its under or over 30. And i left it at that. So just then i started a report at 1:59:46 and this gave me the very normal looking time of 1:60pm ... the chance of that happening is 1 in 120 if my math serves me correctly. Has now been fixed.