[tomasz86]

Yzöwl, on 28 June 2011 - 07:58 AM, said:

I'm interested to know which projects you've done!

Most of them are in my signature

except of these also several unofficial updates for Win2k...

[Yzöwl]

Thanks for the reply, I didn't realise you were classing those as projects.

[tomasz86]

Yzöwl, on 28 June 2011 - 10:32 AM, said:

I didn't realise you were classing those as projects.

Should I not?

Alternatively you can say it's just a one big project called "Let's keep Windows 2000 alive!".

[jaclaz]

NOT the intended "final" result, ONLY "intermediate steps".
Find attached three batches.

• splitinf.cmd - to split an existing .inf (run it with one parameter, the original .inf)
  
• join_inf.cmd - to join the split parts created by the above (run it with one parameter, the SPLIT_ directory)
  
• beautify.cmd - to make the result more readable and reset some changes I have to do to the Split parts to process them easily in batch

gsar is needed:
http://home.online.no/~tjaberg/

Basically:

• create a directory (please NO spaces in paths or filenames) like C:\INFTEST
  
• put in it the batches, gsar.exe and the (basis)Windows2000-KB891861-v2-x86-ENU.EXE.inf (please rename it to something manageable, like "base2K.inf"), never use in filenames characters that are parsed by the command line, like "(", ")", "&" "|" and interpreted like commands or are however part of syntax or need to be escaped normally, even if allowed on the filesystem, see here:
  http://en.wikipedia.org/wiki/Filename
  (please note how right now the batches do use "[" and "]" so may be not good on a FAT filesystem, please use them on a NTFS one)
  
• open a command prompt and navigate to the directory you made:
  

  CD /D C:\INFTEST
  

  
  
• run:
  

  splitinf.cmd base2K.inf
  

  
  

  join_inf.cmd SPLIT_base2K
  

  
  

  beautify.cmd JOINED_base2K.inf
  

  
  
• the "end result", i.e. BEAUTY_JOINED_base2K.inf should be comparable with the original base2K.inf and be a "fully" working .inf file

If not, post which problems there are.
Once we get these steps working successfully, we will talk about the actual merging of the "base" with another "split" file....
Also, I have noticed that in some of the "example files" there are many "empty" sections, are they actually *needed* (right now they are mantained as they are)?


Please note how the above are early, preliminary tests and the actual .cmd's need to be cleaned and polished a lot (and quite a bit of "error controls" need to be added to them).

jaclaz

Attached File(s)

•  split_inf.zip (3.74K)
  Number of downloads: 3

This post has been edited by jaclaz: 12 July 2011 - 10:37 AM

[tomasz86]

Wow

I've just done four tests:

1. A simple update.inf from a single W2K update - w2k_KB838989.inf

No problems. The only difference was in the number of spaces under [Version].



2. Update.inf from Update Rollup 1 for W2K - w2k_KB891861-v2.inf

There are two problems:

- "==" changes to "§#§"
- "&" changes to "§##§"



3. Update.inf from Update Rollup 2 for W2K - w2k_KB891861-UR2-v2.inf

First of all, I got this when doing splitinf.cmd



It continued after that. No problems occured during join_inf.cmd and beautify.cmd.

In the final file:

- "ECHO is off." was inserted several times in many different places.



- one line is missing (?)



- "mod by jaclaz" at the end of the file



4. Update.inf from SP4 for W2K - w2k_SP4.inf

- In SP4's update.inf there is [SourceDisksFiles] twice (each of them is different). One of them was changed.





As for the empty sections, they are not needed when empty and needed when not empty. There are some sections that are almost never used but there can be just one update that uses such a section. I think it's better to have them all

This post has been edited by tomasz86: 12 July 2011 - 10:24 PM

[jaclaz]

#1 is expected behaviour.
#2 is strange, the "beautify.cmd" is the one that should revert the "§#§" and "§##§" to their original values.

::Restore changes made to make the .inf "batch compatible"

::Replace dummy string "§#§" with "=="
CALL :run_gsar :xa7:x23:xa7 :x3d:x3d

::Replace dummy string "§##§" with stoopid "&"
CALL :run_gsar :xa7:x23:x23:xa7 :x26

Are you sure you did run the beatify.cmd on the file?
Anyway I will try to reproduce and fix.
#3 should mean that somehow something was a-miss (a variable got a value of "space" or "tab") I will try to reproduce and fix , the other quirks should be easily fixable
#4 yes, this was expected in case of duplicated sections, I'll put a check for such duplicated entries so that these sections will be merged when split (I do know that is sounds queer, but it is how it will work )

jaclaz

[tomasz86]

jaclaz, on 13 July 2011 - 03:12 AM, said:

#2 is strange, the "beautify.cmd" is the one that should revert the "§#§" and "§##§" to their original values.

Are you sure you did run the beatify.cmd on the file?

You're right It was my fault. Everything O.K after running beautify.cmd.

Quote

#4 yes, this was expected in case of duplicated sections, I'll put a check for such duplicated entries so that these sections will be merged when split (I do know that is sounds queer, but it is how it will work )

The problem is that (not 100% sure) this sourcedisksfiles has to be present twice in SP4's update.inf. The first one is related to the /integrate option if you want to integrate SP into W2K source CD and the other one is a normal sourcedisksfiles used when installing the update. I'm not sure but from analysing other SP's and Gurgelmeyer's USP5.1 I can say that both SourceDisksFiles are always present.

[jaclaz]

tomasz86, on 13 July 2011 - 04:05 AM, said:

The problem is that (not 100% sure) this sourcedisksfiles has to be present twice in SP4's update.inf. The first one is related to the /integrate option if you want to integrate SP into W2K source CD and the other one is a normal sourcedisksfiles used when installing the update. I'm not sure but from analysing other SP's and Gurgelmeyer's USP5.1 I can say that both SourceDisksFiles are always present.

I doubt it.
There is nothing that can differentiate the two sections in themselves.
With the "Install XP from USB" consolidating Sections (with FEDIT) did not produce any unwanted effect, I can also mantain them "separate" by temporarily renaming them, but as I see it it would be philosophycally wrong.
I would keep the current (see attachment) consolidating approach and, once we will have solved the actual merging of two files, you will need to test if it works (as it should) with no duplicate sections.
Issue #3 was caused mainly by a question mark "?", which now is fixed.

The new version should work allright with the 4 mentioned .inf's, try with some other ones and let me know....

jaclaz

Attached File(s)

•  split_inf_2.zip (3.67K)
  Number of downloads: 4

[tomasz86]

I haven't got time to check everything thoroughly yet... but I think I found a bug

1. "<=" and ">=" get changed to "< =" and "> =" respectively.

Operation = CheckFileVer, MSOERT2.DLL, >= , 6.0.0.0

becomes

Operation = CheckFileVer, MSOERT2.DLL, > = , 6.0.0.0

It doesn't work with update.exe. It must be written together.


2. I tried to merge the [SourceFilesDisks] in SP4 and indeed it doesn't seem to make any difference


3. Your script can already be used to merge files :> I tried some tricky thing but very simple :

copy *.inf update.inf

About 100 inf became a one big file (3000 kB). Next step was to process this file by your script. It took long time and the output file was > 250 MB but the final file was sth I was looking for. Everything was merged under proper headings, the only problem was that everything was duplicated x 100 times. I used Notepad++'s sorting (TextFX) on each section separately and was able to remove duplicates this way. Still not perfect but it can save a lot of time. Your script is also very good at removing all the unnecessary spaces from an inf file.

4. I don't know why yet but the "echo is off." line is still present sometimes. Also when doing splitinf I have to press a key twice (somewhere in the middle) to make the script go on.

This post has been edited by tomasz86: 15 July 2011 - 05:35 AM

[jaclaz]

1. other two "exception" that need to be taken into consideration in the batch
2. Good.
3. Hmmm, don't think it is very productive, but the fact that the batch worked (though slowly) on a 250 Mb files is good news , it means that there are no strange "overflows" or something the like
4. The "ECHO OFF" line is good (actually "bad" ) news, it means that the variable that was supposed to be echoed got a null value. I need to have the .inf on which this happens, as it marks the place where the problem is. (just like #3 in previous bug report)

If you use your "inappropriate" way depicted in #3 above, and, once you create the "original" BIG MERGED file you apply to it the splitinf.cmd, then go to the SPLIT_whatever directory you should be able to process the single section files, but I don't see how by sorting them you can know which one is the line relative to the single update .inf.

jaclaz

[tomasz86]

By doing the steps described in #3 I get sth like this

1) two updates.infs

[IE6.System32.Files]
 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
 
 [IE6.Cache.Files]
 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL

&

 [IE6.System32.Files]
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL
 
 [IE6.Cache.Files]
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

2) copy *.inf update.inf

[IE6.System32.Files]
 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
 
 [IE6.Cache.Files]
 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
 
 [IE6.System32.Files]
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL
 
 [IE6.Cache.Files]
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

2) After your script:

[IE6.System32.Files]

 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL


[IE6.Cache.Files]

 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL


[IE6.System32.Files]

 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL


[IE6.Cache.Files]

 BROWSEUI.DLL, xpsp2_binarydrop\BROWSEUI.DLL
 CDFVIEW.DLL, xpsp2_binarydrop\CDFVIEW.DLL
 DANIM.DLL, xpsp2_binarydrop\DANIM.DLL
 DXTMSFT.DLL, xpsp2_binarydrop\DXTMSFT.DLL

If you remove the second duplicated [IE6.System32.Files] & [IE6.Cache.Files] (and use Notepad++'s sorting if necessary) the file will be merged. Of course there may be some other work necessary if the file is complicated but still it works for me I can save time by using your script even now.

[jaclaz]

tomasz86, on 15 July 2011 - 07:45 AM, said:

If you remove the second duplicated [IE6.System32.Files] & [IE6.Cache.Files] (and use Notepad++'s sorting if necessary) the file will be merged. Of course there may be some other work necessary if the file is complicated but still it works for me I can save time by using your script even now.

Well, you can dedupe the [1ndex] by processing it with FEDIT.

Try the attached join_dedupe_inf.cmd instead of join_inf.cmd, I modified it a little bit to create (hopefully) a deduped [1NDEX] fie (actually called [2NDEX] ):

::BEGIN MODIFIED
ECHO [DUMMY_SECTION]>%Split_dir%[2NDEX]%Source%
FOR /F "skip=2 tokens=1 delims= " %%A IN ('FIND "[" %Split_dir%[1NDEX]%Source%') DO (
SET string=%%A
SET string=!string:[=!
SET string=!string:]=!
ECHO Processing %%A....
Fedit -f %Split_dir%[2NDEX]%Source% -add -once -create -l "dummy"  -s "!string!"
Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "dummy"  -s "!string!"
)
Fedit -f %Split_dir%[2NDEX]%Source% -rem -l "[DUMMY_SECTION]"
ECHO.
ECHO.
ECHO TYPE %Split_dir%[2NDEX]%Source%
ECHO.
TYPE %Split_dir%[2NDEX]%Source%
ECHO.
FOR /F %%A in (%Split_dir%[2NDEX]%Source%) DO (
ECHO COPY /B %Work%+%Split_dir%%%A%Source% %Work%
COPY /B %Work%+%Split_dir%%%A%Source% %Work%
)
::END MODIFIED

But the problem I see in "real life" is the order in which you copy together the single .inf files.
Wouldn't it be possible that a newer update line is overwritten by an older one (if by chnace a file is copied in the "wrong" order)?

I will add the <= and >= provision.



jaclaz

Attached File(s)

•  join_dedupe_inf.zip (1.1K)
  Number of downloads: 4

[Yzöwl]

Of course there's a chance, I highlighted that fact towards the beginning of this Topic.

Even simple things such as this are a problem:

Quote

[Version]

Signature = "$Windows NT$"
LanguageType = %LangTypeValue%
NtBuildToUpdate = 2195
NtMajorVersionToUpdate = 5
NtMinorVersionToUpdate = 0
MaxNtBuildToUpdate = 2195
MaxNtMajorVersionToUpdate = 5
MaxNtMinorVersionToUpdate = 0
MinNtServicePackVersion = 1024
MinNtServicePackVersion = 768
MaxNtServicePackVersion = 1024
MaxNtServicePackVersion = 1536
ThisServicePackVersion = 1280
ThisServicePackVersion = 1024
CatalogFile = %SP_CAT_NAME%.cat
CatalogFile = sp4.cat

[tomasz86]

Yzöwl,

but these are simple things I can easily sort manually

jaclaz,

fantastic work The new split_dedupe_inf only removes the duplicated sections, not duplicates in the same section. Am I right?

"Echo is off." in this file.

Is "==" also in exlusions?

like this one

Operation = CheckFileVer, atapi.sys, ==, 5.0.2195.5762

I'll do more tests tomorrow.

This post has been edited by tomasz86: 15 July 2011 - 10:57 AM

[jaclaz]

Yzöwl, on 15 July 2011 - 10:46 AM, said:

Of course there's a chance, I highlighted that fact towards the beginning of this Topic.

Even simple things such as this are a problem:[

Exactly

tomasz86, on 15 July 2011 - 10:54 AM, said:

Yzöwl,

but these are simple things I can easily sort manually

I may be wrong, but the actual fun in using batches to automate things is to actually automate them.

tomasz86, on 15 July 2011 - 10:54 AM, said:

fantastic work The new split_dedupe_inf only removes the duplicated sections, not duplicates in the same section. Am I right?

Actually it simply "dedupes" the index of sections, so that each "split" file is only processed once.

tomasz86, on 15 July 2011 - 10:54 AM, said:

"Echo is off." in this file.

I'll check. Checked, they are stoopid [TAB]'s. Will add.

tomasz86, on 15 July 2011 - 10:54 AM, said:

Is "==" also in exlusions?

like this one

Operation = CheckFileVer, atapi.sys, ==, 5.0.2195.5762

Yes:

::Final adjustments to be run ONLY once
::run Once
::Replace "==" with a dummy string "§#§"
CALL :run_gsar :x3d:x3d  :xa7:x23:xa7

jaclaz

This post has been edited by jaclaz: 15 July 2011 - 11:11 AM

[Yzöwl]

tomasz86, on 15 July 2011 - 10:54 AM, said:

Yzöwl,

but these are simple things I can easily sort manually

No they are not, basically there are lines in each inf which are pertinent only to that inf. Once you merge them into one you are unable to track information between each file. When the inf is run it will use the value last recorded for a particular piece of data. If you run a line which was intended only for minimum service pack version 1024 against a machine at 768 then you can do untold damage to their system.

I'm aware that the exact case above is relatively simple to fix manually but that is only based on the first section at the top of each of the four files you've linked to, what about every other section and every other update.

I'm fairly certain that the work needed to do what you want in a scripting language, (and probably a real programming language), will be greater than simply running the updates in sequence as they are now.

It appears that you wish to not do that so that you can be the champion of a new unofficial service pack project; But at what cost, especially to those who have done all of the donkey work for you!

BTW, I've attached a copy of the resulting file from merging the four samples you provided using my own batch only script. There were errors so the output is incorrect but it was a simple test in order to provide some output for the purposes of this post. I've no real intention of fixing these errors right now. What I'd like from you is an explanation of how you intend to ensure that information from one original file will not overwrite or break that of another section.

Attached File(s)

•  MERGED.rar (78.84K)
  Number of downloads: 5

This post has been edited by Yzöwl: 15 July 2011 - 01:20 PM
Reason for edit: Attachment and info added

[tomasz86]

Yzöwl, on 15 July 2011 - 12:30 PM, said:

tomasz86, on 15 July 2011 - 10:54 AM, said:

Yzöwl,

but these are simple things I can easily sort manually

No they are not, basically there are lines in each inf which are pertinent only to that inf. Once you merge them into one you are unable to track information between each file. When the inf is run it will use the value last recorded for a particular piece of data. If you run a line which was intended only for minimum service pack version 1024 against a machine at 768 then you can do untold damage to their system.

In such case only 1024 must be used to prevent problems. What I do is to check every section manually and see if there is something wrong with it. Once you've got accustomed to them it's relatively easy to know instantly which lines are correct and which ones are not. Also when running the update.exe it checks if the .inf file is correct and reports an error if there are problems.

Also one more info: the order of lines in each section doesn't matter at all. I've already checked that. They can be sorted alphabetically.

Quote

It appears that you wish to not do that so that you can be the champion of a new unofficial service pack project; But at what cost, especially to those who have done all of the donkey work for you!

I don't really understand why you're writing something like this... especially considering that I've already made HBR Mini Rollup & IE / OE Mini Rollup (100% manual work by myself) and UR2 for Win2k (107 updates merged; used HFSLIP's script for merging files and manually merged update.infs).

I have enough knowledge about update.infs to merge them myself manually but it requries a lot of time and work which could be simplified using such a script like this one created by jaclaz. I don't know how to write such a script myself so I asked for help here. Is there anything wrong about it?


jaclaz,

there is one big problem when merging something like this

Spoiler

    HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%",,,"%COMPID%"
    HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","IsInstalled",0x10001,01,00,00,00    
    HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","Version",,"%VERSION%"
    HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","ComponentID",,"%COMPID%"
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed",0x10001,1
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Comments",0,%SP_TITLE%
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Backup Dir",0,""
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Fix Description",0,%SP_TITLE%
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed By",0,""
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed On",0,""
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"IE Service Pack",0x10001,%SERVICE_PACK_NUMBER%
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Service Pack",0x10001,%OS_SERVICE_PACK_NUMBER%
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Valid",0x10001,1
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"Flags",0,""
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"New File",0,""
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"New Link Date",0,""
    HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%\File 1\,"Old Link Date",0,""
    HKLM,SOFTWARE\Microsoft\Updates\%SourceDiskName%\SP%SERVICE_PACK_NUMBER%\%SP_SHORT_TITLE%,"Description",,%SP_TITLE%
    HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%SP_SHORT_TITLE%,"DisplayIcon",,"%11%\msiexec.exe"

%(...)% are defined in [Strings]

Spoiler

    STR_PROGRAMF_DIR    = "Program Files"
    STR_COMMON_DIR      = "Common Files"
    STR_MAILNEWS_DIR    = "Outlook Express"
    STR_SHARED_DIR      = "Microsoft Shared"
    STR_MSINFO_DIR      = "MSInfo"
    STR_VGX_DIR	        = "VGX"
    SourceDiskName      = "Internet Explorer 5.01"
    STR_SYSTEM_DIR      = "Common Files\System"
    LangTypeValue =0x09
    LCID =0409
    W32ID =0x09
    Compid ="KB938127"
    Version ="5,0,3854,2500"
    Guid ={90b0bef8-22d6-40a8-92c8-155434fc112f}
    SP_SHORT_TITLE ="KB938127-IE501SP4-20070626.120000"
    SP_SHORT_TITLE_DISPLAY ="KB938127"
    HELPLINK ="http://support.microsoft.com/?kbid=938127"
    BUILDTIMESTAMP =20070626.120000
    SERVICE_PACK_NUMBER =4
    OS_SERVICE_PACK_NUMBER =5
    IeRegKey ="Software\Microsoft\Windows\CurrentVersion\App Paths\iexplore.exe"
    URLInfoAbout ="http://support.microsoft.com"    
    ServicePackSourceFiles="Windows 2000 Hotfix Source Files"
    SP_TITLE="Windows 2000 Hotfix - KB938127"

Almost all Win2k updates use such a structure but if you merge them the data is lost. If I wanted to process updates by your script I would have to change manually each updates' data to sth like before merging them:

Spoiler

 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Backup Dir",0,""
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Comments",0,"Windows 2000 Hotfix - KB938127"
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Fix Description",0,"Windows 2000 Hotfix - KB938127"
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","IE Service Pack",0x10001,4
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Installed By",0,""
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Installed On",0,""
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Installed",0x10001,1
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Service Pack",0x10001,5
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000","Valid",0x10001,1
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","Flags",0,""
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","New File",0,""
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","New Link Date",0,""
 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB938127-IE501SP4-20070626.120000\File 1\","Old Link Date",0,""

Is it even possible to do such a thing automatically or would it require too much work?

This post has been edited by tomasz86: 15 July 2011 - 11:04 PM

[Yzöwl]

tomasz86, on 15 July 2011 - 10:38 PM, said:

I don't really understand why you're writing something like this... especially considering that I've already made HBR Mini Rollup & IE / OE Mini Rollup (100% manual work by myself) and UR2 for Win2k (107 updates merged; used HFSLIP's script for merging files and manually merged update.infs).

I have enough knowledge about update.infs to merge them myself manually but it requries a lot of time and work which could be simplified using such a script like this one created by jaclaz. I don't know how to write such a script myself so I asked for help here. Is there anything wrong about it?

Of course there is!

The project is basically the script, but you've not done it, someone else has, at the moment it's jaclaz's work

The same as your roll up script which was in the majority a copy of the work done by others on the HFSLIP project.

[tomasz86]

I didn't use any script when making HBR Mini Rollup & IE / OE Mini Rollup.

As for HFSLIP:

Quote

You are free
(1) to Share - to copy, distribute and transmit HFSLIP (the work)
(2) to Remix - to adapt the work

Under the following conditions:
(1) Attribution. You must attribute the work in the manner specified by the
author or licensor (but not in any way that suggests that they endorse
you or your use of the work).
(2) Noncommercial. You may not use this work for commercial purposes.
(3) Share Alike. If you alter, transform, or build upon this work, you may
distribute the resulting work only under the same or similar license to
this one.

In the very beginning (in this topic) I stated that the script is a part of the HFSLIP's script. I didn't write anywhere that it was my work.

TO prevent further problems:

Jaclaz, is it O.K to use your script when merging updates in order to make update rollups for Win2k?

[jaclaz]

tomasz86, on 16 July 2011 - 12:15 AM, said:

Jaclaz, is it O.K to use your script when merging updates in order to make update rollups for Win2k?

As long as you comply with my Careware License , yes, of course :
http://jaclaz.alterv...s/careware.html
but - as said - at the moment we are very little beyond the "proof of concept" stage.

Can you assemble together a "fake" update .inf file with all the lines that you find needing manual correction (i.e. the ones that result as "different" in the re-joined file?
This way I can have all in one source the "problematic parts" and test the batches more easily....
IN other words, if you could manually assemble a fake "difficult" file, it will be faster for me.

jaclaz