new and probably a lot faster installer

[user57]

new and probably lot faster installer
so now the story

in the past i once came across a installer or often used a different name like SP4 update pack - or in my case "SP4 by harkaz"
so to say SP4 by harkaz is a installer but it use microsofts engine or the so CALLED "INF"
so when i used it i had a problem - the install time was like super high like 6 hours it was on my weak computer past in time
that is because the method is rather a engine or a script (and these are not fast)

to mention now is that "INF" installer engine by microsoft can install either registry entrys or files

the next thing to mention is that registry entrys and file controls are always made via the same ("windows api functions") (so other installers that have a such entrys (or whatever we call them) - always use these functions (these are absolute ) (not like the installer script itself)

these always look like for example : 
HKEY_LOCAL_MACHINE (the main key)
then there are KEY ENTRYS like "MYNAMEIS" 
then these have a TYPE like dword, binary, string
as last thing there is the DATA like "true" , "1" or 0x0000000

thus an INF has :
HKLM,(subfolder), MYNAMEIS, TYPE, DATA
so one to make his own installer for this need to write something similiar
to devide the parameters (, is used by microsoft, but it tends to bug with ")
so i used a more safe method : 0, or in the compiler \0 (that method give a clear cut and is  a lot harder to bug)
after that it looks like this:
"HKLM\0,(subfolder)\0, MYNAMEIS\0, TYPE\0, DATA",
the quotes are just because you in a compiler and the ", or just the , is for the next entry

for the files "microsoft INF" snips together some information
it has an identifier for a certain path like %systemroot%
for this it use a subpath
and a filename
that it snips together to like C:\windows\a.exe (with a subpath could be like C:\windows\x\a.exe) C:\windows + \x + a.exe

so i wrote something similiar 
identifier, subpath, targetfilename, sourcefilename, sourcesubpath
(for source always the path for the executable name (aka installer.exe) is taken
so basicly it do the same thing as microsofts INF
this is like absolute - their nor other installer can do nothing else in the end

so i was working around and took the biggest upgrade i could find
that was "IE8-WindowsXP-x86-ENU.exe" around 17 MB 
that being said that update/installer has 9187 registry entrys
so have this faster i made a converter - the converter exspect the above described "inf style " registry entry´s

now here would be the next idea, the most installers use exactly that "inf style" installer methods
this means you can combine all the upgrades to just 1 installer - you just have to collect the registrys and file entrys
then you have your "sp4 update pack" 

for now i only made the that for the first IE8 installer, but combine all is possible

 

and now its time for the test 
so i made 2 versions de (german) and en_us (english)
i tested them in a virtual machine if you install DE to a us version the IE8 is bugged up so if you install the US version to a DE system
i think you need SP2 too ... (as IE8 probaly needs that)
but that is not really a question or problem because the installer just has to proof that it installs correctly (the sp2 or files what we want we can do later)
beware and use either a VM or a computer where you can try this (otherwise you overwrite a older version if IE8 (if already got a newer version)) :
(source code also included)

Blank (only IE8 without upgrades GERMAN)
https://www.file-upload.net/download-15597090/IE8_DE_part1.zip.html

Blank (only IE8 without upgrades ENGLISH)
https://www.file-upload.net/download-15597091/IE8_enUS_part1.zip.html

 

IE8-Blank + kb4467770 + kb4019276 + kb4493435 + kb2598845 (ENGLISH)

https://www.file-upload.net/download-15597216/IE8_combined_ENUS.zip.html

IE8-Blank + kb4467770 + kb4019276 + kb4493435 + kb2598845 (GERMAN)

https://www.file-upload.net/download-15597217/IE8_combined_german.zip.html

 

kb4493435 seems to have a bugged entry it contains 6.1 for windows 7 but meant is 5.1 - that was corrected

installer code (blank)

https://www.file-upload.net/download-15599014/installer.zip.html

Edited May 23 by user57

[j7n]

I believe that the update package is slow because it launches every Microsoft update separately as if they had been applied the official way. This comes with overhead of starting that many individual programs, each doing some housekeeping, enabling uninstallation of each pack. Back in the day, there was the Unofficial Service Pack for Windows 98SE. It was done differently. It combined all the files into a few big packs and copied the selected ones at once. The size on disk was also a lot smaller. Every instaler uses Windows API functions to write to registry.

Now time has moved on, computers on average are a lot faster. Same story as with most software.

I have never bothered to install the SP4. The size and inclusion of "bloatware" (media player, net framework, internet explorer) we wouldn't put on weaker XP-period machines was an immediate turn-off for me. Having all that defeats the purpose of using Windows XP. Instead I put on a handful of Microsoft updates that brought essential functionality.

[NotHereToPlayGames]

I personally always felt that "installing" update hotfixes had a major tendency to SLOW DOWN my computer.

But the same EXACT "hotfix" SLIPSTREAMED into my XP install disk, REFORMAT then REINSTALL from that SLIPSTREAMED disk always presented a MUCH FASTER computer.

RyanVM.net was always a good source for "update packs" to SLIPSTREAM.

 

I always felt that installing hotfixes one by one resulted in an OS that had to zig-zag between pointers to find anything, instead of the faster straight line approach with no zig-zags.

[tekkaman]

I also noticed that Setups with updates preinstalled is much faster than installing them later. I had an XP 64 disc with all the updates that version could take preapplied and it was much better. 

[user57]

the good with my installer is that you dont need to install anything first - directly and everything

no zick zacks, no start ups, no weird slow engine

that 9187 entrys where progressed with a 1 core cpu in around 0,3 seconds - thats very acceptable

lets say all registry entrys would have 91870 in total it would be 3 seconds 

for files it it will be a little different story - but a lot of steps should also be faster 

 

it seems to work at least with the few tests i did

i have the IE6 as test installed and then installed on a english system and a german system :

https://www.directupload.eu/file/d/9256/hw59rpff_jpg.htm
https://www.directupload.eu/file/d/9256/rrtwbm7c_jpg.htm
https://www.directupload.eu/file/d/9256/6vtmdi6l_jpg.htm
https://www.directupload.eu/file/d/9256/ld8onvao_jpg.htm
https://www.directupload.eu/file/d/9256/trh8q5hi_jpg.htm

 

now it would be a question of collecting the registrys entrys and files entrys and then a sp4 or something would have a nice solution

a such list is used with a .iso often

[Start Me Up]

Is there any way to apply the progress you made to the operating system itself?

If I understood the situation correctly, then you are replacing Microsoft's update.exe with your installer.exe. However, every Windows update comes with update.exe so you would need to re-release every update. Is it update.exe that is so slow or is it a function from Windows' API that is slow and you are using something else to speed up the installation?

Edited April 18 by Start Me Up

[user57]

it can replace system files or protected registry files like a trusted installer can do (inf is probaly a trusted installer)

 

those KBXXXXXX upgrades are like a zip file (actually you can open these with a winrar or something)

those come always with that update.exe - what is microsofts inf engine installer (it can do the same - registry and files)

the problem with it is it calls up many internal functions, and also read the entrys from a file (memory is a lost faster) - its like a engine with a lot side stuff and bounces around very much

(to bring them into memory with a very fast progress i brought them to the compiler itself - so i also needed a engine that can do similiar to microsofts)

 

exactly this problem sum´s up, i have seen around 150+ kbXX upgrades - that being done with harkaz method took me 4 hours in the past

that being said 9187 entrys took the installer from me 0,3 seconds 

 

in the very past i did something like this in the past (it was a programm and i readed out its registry entrys and files, just not "inf style like")

the install time gone down from 12 min to 8 seconds

 

so that being said even 1 min install time would be a lot better then that - far away from 240 mins

 

it certainly would be possible to use the code from me in a different installer and compile it up there

 

so now the next important part

you have like many KBXXXXXX upgrades with always a update.exe and the registry and file entry´s are contained not at update.exe but in a file with a .INF ending

and here is the thing - if you collect these entrys you can combine that entrys to 1 installer = SP4 installer (aka 150+ kb upgrades installed with just 1 installer)

if you just want to do IE8 (with all the other side upgrades) then only IE8 

you also use that installer code to install a few registry settings - or a programm you like to - you just have to know the registry and file entrys

[Start Me Up]

3 hours ago, user57 said:

inf is probaly a trusted installer

I don't think that the concept or the mechanism of a "trusted installer" exists.

I once wrote a Windows update myself without an inf file. The challenge was more about knowing how for example Windows 2000 or Windows XP expects a correct installation of a system file. There are differences between Windows versions. A correct installation leads to the outcome that the installation is possible and that the file protection system accepts the new version.

However, if you wrote the installer yourself then you are probably aware of what is involved.

---

If I understood your comment correctly, then the speed gain you achieved mainly comes from a faster way when it comes to dealing with the registry. The underlying API to interact with the registry does not seem to be the problem but rather what update.exe does.

In this case it would not be possible to improve Windows XP itself but you would need to re-release every Windows update. That is a bit sad because you are probably not going to do this. Also, there are other operating systems, like Windows 2000, which probably have the same problem with it's updates, too.

Or is the speed problem with big inf files? I would be a bit surprised if that was the case because I once wrote a 500 KB inf file which was processed in about 2 seconds on my 1.5 GHz Intel Atom. However, it does not contain many registry keys and values. Also, my inf file is not read by update.exe.

Edited April 18 by Start Me Up

[NotHereToPlayGames]

3 hours ago, user57 said:

exactly this problem sum´s up, i have seen around 150+ kbXX upgrades - that being done with harkaz method took me 4 hours in the past

that being said 9187 entrys took the installer from me 0,3 seconds 

 

in the very past i did something like this in the past (it was a programm and i readed out its registry entrys and files, just not "inf style like")

the install time gone down from 12 min to 8 seconds

 

so that being said even 1 min install time would be a lot better then that - far away from 240 mins

 

It sounds to me like you are removing all of the pre-requisite checks.

Microsoft KBxx updates don't "install" just because you double-click them, they analyze your system and run checks to see if the update even qualifies for your system.

Those checks take time that have nothing to do with writing a file or registry entry.

[user57]

to me the normal ones with update.exe seems to be made with Install Shield from VS6
it generally is not very fast
the inf file you showed to me might got 500KB but only contain 10 registry entrys
the newer ones seems to be made with install shield from VS2010 - that one is even slower
how we would call them "install makers ?" 

the sfc manager 
https://en.wikipedia.org/wiki/System_File_Checker#Usage
might complains that its files have been replaced, but it cannot undo the install because the ones in dllcache are also overwritten
either way if you reboot, clicked it away or accept - the installation has worked at least in my tests

if you remember how to skip the sfc manager (from what i remember in the past it was a registry entry)
i would be happy to know it again
i useally dont have the sfc manager on - it takes cpu power and diskspace

but even for a iso i reconized a lot longer install time
the iso however works with the same filesize (often like 650 mb for a CD) - this is just because it dont replace the files - it just has the files 
the registry entrys are certainly more but still if mine can install in 0,3 seconds or 3 seconds for 91870 for 60 seconds it would be 1,8 million 
why the one from microsoft - still would take a lot longer?
 

[Start Me Up]

1 hour ago, NotHereToPlayGames said:

It sounds to me like you are removing all of the pre-requisite checks.

Microsoft KBxx updates don't "install" just because you double-click them, they analyze your system and run checks to see if the update even qualifies for your system.

Quote

either way if you reboot, clicked it away or accept - the installation has worked at least in my tests

If the theory of NotHereToPlayGames is correct and you are facing problems with the file protection mechanism so the user has to click away the replacement message or has to deactive the mechanism then you are distributing updates that work on your computer and maybe only on your computer.

However, the pre-requisite checks should not take that long. It's mostly just checking for a file version or a registry value. It costs time but not hours.

Edited April 18 by Start Me Up

[NotHereToPlayGames]

There is also the way that Windows has to wait for a previous "installer" to completely terminate before another "installer" can begin.

Same goes for when you go to "uninstall" something.  You can only uninstall one at a time or get hit with a message to wait for the first to complete.

The standard "WaitToKillAppTimeout" is TWENTY SECONDS.

So if you are installing 150 installers sequentially, 150*20/60 is FIFTY MINUTES of just waiting for those timeouts.

 

I can't speak for ever witnessing these sorts of KBxx install durations because I never install KBxx's.

I sometimes slipstream into my install disk, but for the most part I only run "first release" versions of Windows and NEVER UPDATE THEM.

The only time I ever "update" Windows is when I go from FIRST RELEASE of a 2016 version of Win10 to a FIRST RELEASE of a 2022 version of Win10.

In my XP days, I *NEVER* updated via KBxx.  I installed XP.  Formatted, installed XP+SP1.  Formatted, installed XP+SP2.  Formatted, installed XP+SP3.

Never anything past SP3 (including never installing any of the "illegal" PosReady2009 stuff).

Edited April 18 by NotHereToPlayGames

[Start Me Up]

27 minutes ago, NotHereToPlayGames said:

The standard "WaitToKillAppTimeout" is TWENTY SECONDS.

So if you are installing 150 installers sequentially, 150*20/60 is FIFTY MINUTES of just waiting for those timeouts.

Is the update pack doing a reboot after every update? I thought the "WaitToKillAppTimeout" value was the maximum time an application was given to postpone a reboot or shutdown.

Edited April 18 by Start Me Up

[NotHereToPlayGames]

Ah yes, that is correct.

BUT...  there's still a finite amount of time when one installation ENDS *before* a second can BEGIN.

[NotHereToPlayGames]

1 hour ago, Start Me Up said:

then you are distributing updates that work on your computer and maybe only on your computer.

Bingo!