32 replies to this topic

[MedEvil]

Since my last tests with CD-DVD bootimes, i gave this topic a lot of thought.
And think, the reason that boot times take as long as they do is, that we (needlessly?) perform 2 independant hardware detections and 2 driver installations. (At least on XP/w2k3 projects)

nativeEX_barebone does not boot faster because it supports less hardware, but because it only performs 1 hardware detection and 1 driver installation.

Just try the following. Put HwPnP into your nativeEx_barebone and run it. You will not gain any funktionality, but burn lot's of time.

So by moving the whole hardware detection/driver installation to the same process, we should speed up the boot time considerably.

[pscEx]

Since my last tests with CD-DVD bootimes, i gave this topic a lot of thought.
And think, the reason that boot times take as long as they do is, that we (needlessly?) perform 2 independant hardware detections and 2 driver installations. (At least on XP/w2k3 projects)

nativeEX_barebone does not boot faster because it supports less hardware, but because it only performs 1 hardware detection and 1 driver installation.

Just try the following. Put HwPnP into your nativeEx_barebone and run it. You will not gain any funktionality, but burn lot's of time.

So by moving the whole hardware detection/driver installation to the same process, we should speed up the boot time considerably.

As you already mentioned wit '1 hardware detect ...':
In nativeEx_barebone there is also an app like HwPnP (called StartPNP).

But it is only only copied to PE if bearwindows's Universal Video Driver script is selected and started to detect this driver. Therefore the app's code is limited to look into the 'video' class.

HwPnP looks into much more classes, depending on cmd line.

I'm sure that a well suited HwPnP script with options for all required classes (and switch off of StartPNP), can reduce the amount of boot time remarkably.

Peter

[MedEvil]

As you already mentioned wit '1 hardware detect ...':
In nativeEx_barebone there is also an app like HwPnP (called StartPNP).

But it is only only copied to PE if bearwindows's Universal Video Driver script is selected and started to detect this driver. Therefore the app's code is limited to look into the 'video' class.

HwPnP looks into much more classes, depending on cmd line.

I'm sure that a well suited HwPnP script with options for all required classes (and switch off of StartPNP), can reduce the amount of boot time remarkably.

Peter

So you mean, to split the hardware detect clearly between those 2 detection methodes should possibly bring the same effect?

[pscEx]

So you mean, to split the hardware detect clearly between those 2 detection methodes should possibly bring the same effect?

No, I meant that it can save a lot of time if you start HwPnP with a cmd line which only checks the wanted HW classes.

(I remember that anywhere I read a HWPnp cmd line syntax description, which makes this possible)

Peter

BTW: If you us HWPnP, StartPNP is not possibel. Therefore a script scheduling HWPnP in RunOnce, should look for StartPNP in RunOnce and remove it from the target registry.

That again remembers me on some of my (unpublished) concerns, that RunOnce must be organized by as 'preISO' script.

@Holger: I just see you in the list of visitors:

Is it possible to include your PENetwork PnP detection (optional) into such a script, too?

[MedEvil]

That again remembers me on some of my (unpublished) concerns, that RunOnce must be organized by as 'preISO' script.

But how would that script know the right order? It's not like RunOnce entries would work in any order.

[Holger]

I will think about to include an ('cmdline') option to start a different hardware detection program - if this is what you mean.

[pscEx]

But how would that script know the right order? It's not like RunOnce entries would work in any order.

That again remembers me on some of my (unpublished) concerns, that RunOnce must be organized by as 'preISO' script.

Since a while I'm thinking about to organize that (writing requests into a file, comparable with the autostart mechanism) and finally write the reg entries by an app which uses this file.

But I always have some issues with priority. Currently priority #1 is 'Native Launch App'. And if you have read all posts about that, currently there is a goal of 7 months ...

Peter

[MedEvil]

I will think about to include an ('cmdline') option to start a different hardware detection program - if this is what you mean.

btw, Holger can you do me favour and include a little fix in your script?
Since you don't use anymore a seperate program to make the unicode patch, the script does not work anymore under XPSP1.

Maybe a nice little checkmark?

[Holger]

Hi Med

just want to let you know that it seems to be no problem with my script.
Here some infos - I did only tests with the "LiveXP"-project:

I did some tests again with XPSP1 and got the problem of system hangups/frozen state while starting DHCP client (was it your problem too?).
So it took a while to found the problem.

However, I just replaced the file "NTKRNLMP.EXE" (1850KB) in the target folder with a same named file (1997KB) of the "SP1.cab".
After rebuilding the ISO I did not get hangups anymore (like in the screenshot).

I took a look (that seems to be wrong language ) into the "TXTSETUP.SIF" of the XPSP1-source and found the following string: "ntkrnlmp.exe = 100,,,,,,2_,2,3".
So because at the beginning of the setup file DirID 100 is set to: "100 = %spcdname%,%spcdtagfilei%,,\i386,1" I come to the conclusion that it is an error here in one script.

At the moment I don't know why the line in the "Copy and Expand" script is used:
If,%OS%,Equal,XP,If,%SP%,Equal,SP1,CopyOrExpand,%source_win%\NTKRNLMP.EXE,%target_sys%
I think this should be corrected.

Maybe it's just an old error which is/was already fixed...
What I have also no idea of is the fact that these "ntkrnl...exe's" are always in the "i386" dir and one more in the "SPX.cab" file.

Greets
Holger

Attached Thumbnails

• 

[pscEx]

However, I just replaced the file "NTKRNLMP.EXE" (1850KB) in the target folder with a same named file (1997KB) of the "SP1.cab".
After rebuilding the ISO I did not get hangups anymore (like in the screenshot).
...

What I have also no idea of is the fact that these "ntkrnl...exe's" are always in the "i386" dir and one more in the "SPX.cab" file.

First: There are trobles only with XP2 SP1

In my source CD (XP Professional German with slipstreamed SP1) both "NTKRNLMP.EXE" are identical:
Size: 1.893.888 bytes Version: 5.1.2600.1106

I have a hang with 'Install clients for microsoft networks', that is before the DHCP stuff.

At the moment I don't know why the line in the "Copy and Expand" script is used:
If,%OS%,Equal,XP,If,%SP%,Equal,SP1,CopyOrExpand,%source_win%\NTKRNLMP.EXE,%target_sys%

I'm the author of that line.
Reason:
Even, if in HAL, Special files etc. all multiprocessor stuff is removed from txtsetup.sif, during boot in SP1 the missing NTKRNLMP.EXE is complained.

BTW: I changed the line to

If,%OS%%SP%,Equal,XPSP1,ShellExecute,"hide","expand.exe","#$q%source_win%\%spFile%#$q -F:NTKRNLMP.EXE #$q%target_sys%#$q"

Next delivery i'll move it to the server.

Peter

[Holger]

Hi
@Peter:

First: There are trobles only with XP2 SP1

I'm a little bit confused now - do you mean with XPSP2 only or XPSP1?
Can you please then give me some details so I can reproduce this fail behaviour?

@Med:

Since you don't use anymore a seperate program to make the unicode patch, the script does not work anymore under XPSP1.

Please can you also give me some more details (project) for reproducing.

Thank you both and greets
Holger

[pscEx]

I'm a little bit confused now - do you mean with XPSP2 only or XPSP1?
Can you please then give me some details so I can reproduce this fail behaviour?

Sorry about my

First: There are trobles only with XP2 SP1

Should be

First: There are trobles only with XP SP1

Peter

[MedEvil]

Hi
@Med:

Please can you also give me some more details (project) for reproducing.

No need to anymore, since i upgraded in february to version 24 of PENetwork things work flawless even under XPSP1. Before i always had to downgrade to version 10 or 11.

[cdob]

If,%OS%,Equal,XP,If,%SP%,Equal,SP1,CopyOrExpand,%source_win%\NTKRNLMP.EXE,%target_sys%

XP SP1 and 2003 gold setupldr.bin read file name ntkrnlmp.exe.
However that's a renamed ntosknrl.exe at WinPE.

Setupldr.bin select uni processor HAL from default txtsetup.sif.
Uniprocessor HAL and multiprocessor kernel fails at network: system freeze.
Don't mix uniprocessor HAL and multiprocessor kernel.

Use Uniprocessor HAL togehter with uniprocessor kernel.

As for turbo booting:
don't register a single dll at boot time
use as less PNP as possible
create a valid infcache.1, this includes *.inf file timestamps
sort file layout at CD

[pscEx]

XP SP1 and 2003 gold setupldr.bin read file name ntkrnlmp.exe.
However that's a renamed ntosknrl.exe at WinPE.

Setupldr.bin select uni processor HAL from default txtsetup.sif.
Uniprocessor HAL and multiprocessor kernel fails at network: system freeze.
Don't mix uniprocessor HAL and multiprocessor kernel.

Hi cdob,

nice to see the 'newbie' under your name

If you have a look at my post #10

Even, if in HAL, Special files etc. all multiprocessor stuff is removed from txtsetup.sif, during boot in SP1 the missing NTKRNLMP.EXE is complained.

Should I deliver a copy of ntoskrnl.exe renamed to ntkrnlmp.exe?

Peter

[cdob]

nice to see the 'newbie' under your name

Can you do a favour? Fix this newbie title for future? I'm learning PE still.
I knew some PE background, but can't answer a lot of questions.

Should I deliver a copy of ntoskrnl.exe renamed to ntkrnlmp.exe?

Yes, that's it.
Or deliver a ntkrnlmp.ex_, containing a ntoskrnl.exe.
Be aware kernel ntoskrnl.exe can be ntoskrnl.ex_ or ntoskrnl.exe. A SP use ntoskrnl.ex_. A slipstreamed hot fix use ntoskrnl.exe.
How do you do this at WinBuilder? Remeber I'm a newbie only.

Or find and fix the true reason: why does network fail at multiprocessor kernel mixed with uniprosessor HAL?
I don't knewa reason and fix.

[Alexei]

I've already mentioned t once some time ago, but anyway...
PE boots slowly because necessary drivers are getting installed. "Normal" Win verifies current hardware, but it boots faster, I think, because necessary drivers are already pre-installed.
Why MS uses Drivers.cab instead of having all drivers pre-installed. I believe, because of historical reasons (i.e. from pre-NTFS compression) times and necessety to run on FAT
NTFS compression of pre-installed drivers may very well replace drivers.cab. Same with slow networking startup. Why should we install AFD, TCP/IP, Server, and a lot of other drivers/services at runtime? With "normal" windows we don't re-install everything network-related just because of different NIC. INFs are very flexible, and we pay for this flexibility at each PE boot

Alexei
PS
You can do a simple experiment to verify my proposal:
- Boot PE on one PC, start Network. When startup is finished unload the registry to a .reg
- Do the same on very differnt PC
- Compare two dumps.
You should see the differences are much less, then between the registry we pre-build in WB and what we have at PE runtime.

[pscEx]

Can you do a favour? Fix this newbie title for future? I'm learning PE still.
I knew some PE background, but can't answer a lot of questions.
The forum's server will will you upgrade to 'Member' automatically with your 10th post.

Yes, that's it.
Or deliver a ntkrnlmp.ex_, containing a ntoskrnl.exe.
Be aware kernel ntoskrnl.exe can be ntoskrnl.ex_ or ntoskrnl.exe. A SP use ntoskrnl.ex_. A slipstreamed hot fix use ntoskrnl.exe.
How do you do this at WinBuilder? Remeber I'm a newbie only.
CopyOrExpand,%source_win%\NTKRNLMP.EXE,%target_sys%

Or find and fix the true reason: why does network fail at multiprocessor kernel mixed with uniprosessor HAL?
I don't knewa reason and fix.
Me neither!

Peter

[MedEvil]

I've already mentioned t once some time ago, but anyway...
PE boots slowly because necessary drivers are getting installed. "Normal" Win verifies current hardware, but it boots faster, I think, because necessary drivers are already pre-installed.
Why MS uses Drivers.cab instead of having all drivers pre-installed. I believe, because of historical reasons (i.e. from pre-NTFS compression) times and necessety to run on FAT
NTFS compression of pre-installed drivers may very well replace drivers.cab. Same with slow networking startup. Why should we install AFD, TCP/IP, Server, and a lot of other drivers/services at runtime? With "normal" windows we don't re-install everything network-related just because of different NIC. INFs are very flexible, and we pay for this flexibility at each PE boot

Alexei
PS
You can do a simple experiment to verify my proposal:
- Boot PE on one PC, start Network. When startup is finished unload the registry to a .reg
- Do the same on very differnt PC
- Compare two dumps.
You should see the differences are much less, then between the registry we pre-build in WB and what we have at PE runtime.

I think, as i already wrote in some other topic, there are 3 ways to get drivers working in PE.
1. install through txtsetup.sif - (easiest way, nochance of using parameters)
2. install through HwPnP - (takes the longest, but installs all features)
3. preinstallation into registry - (fastest to boot, all features available)

The problem with version 3 is that it's not that easy.
A. How does one easily install a driver during build time?
B. You might noticed once, that when you plug in your USB printer or scanner in a different port, XP will tell you it found a 'new' hardware and will start installing the driver again. I guess the same would happen with all preinstalled drivers in a universal PE.
C. Is it possible to preinstall all the drivers of driverpacks or would they interfere with eachother?

If A, B and C can be solved 3 would be without a doubt the best and fastest choice.

[pscEx]

I think, as i already wrote in some other topic, there are 3 ways to get drivers working in PE.
1. install through txtsetup.sif - (easiest way, nochance of using parameters)
2. install through HwPnP - (takes the longest, but installs all features)
3. preinstallation into registry - (fastest to boot, all features available)

The problem with version 3 is that it's not that easy.
A. How does one easily install a driver during build time?
B. You might noticed once, that when you plug in your USB printer or scanner in a different port, XP will tell you it found a 'new' hardware and will start installing the driver again. I guess the same would happen with all preinstalled drivers in a universal PE.
C. Is it possible to preinstall all the drivers of driverpacks or would they interfere with eachother?

If A, B and C can be solved 3 would be without a doubt the best and fastest choice.

There must be another secret:

I recorded the work of PENetwork during PE boot.

The attached script and files contain everything PENetwork changed.

Opinion: If I do these changes during build, the execution of PENetwork during boot can be replaced.
Test results = :

• No valid network in PE
• Start of PENetwork aborts with 'error with service TCPIP (2)'

BTW: What is (2)?

Maybe somebody else does some more tests with the attachement.

Peter

 presetNet.zip   49.98KB   527 downloads

[MedEvil]

Peter did you check that, before starting network, the registry settings are still like they should be?
With our boot time install of files, we tend to overwrite a lot of registry entries.

Noidea what TCPIP(2) means, but i got this error too, when i tried to integrate aNet.script into naughtyPE.

[pscEx]

Peter did you check that, before starting network, the registry settings are still like they should be?
With our boot time install of files, we tend to overwrite a lot of registry entries.

No I didn't. I'm currently in the very beginning of 'how to use trackWBInstall'.
I just wanted to give this hint here.

Maybe if I remove several registry entries around 'Cryptic' etc. it will work.
Give me some time.

Peter

[Galapo]

I think, as i already wrote in some other topic, there are 3 ways to get drivers working in PE.
1. install through txtsetup.sif - (easiest way, nochance of using parameters)
2. install through HwPnP - (takes the longest, but installs all features)
3. preinstallation into registry - (fastest to boot, all features available)

Not all drivers may be installed by the third method, ie preinstallation into the registry at build time. I've been trying to do this with mass storage drivers the last couple of days. I can get drivers installed correctly as they would be under a normal full OS, ie with CriticalDeviceDatabase entries, service entries, etc. What works on a normal XP does not work for an XP PE (but does for Vista PE). Mass storage drivers entered into txtsetup.sif are used at boot and drivers are available, but with CriticalDeviceDatabase entries, service entries, etc they are not used at boot and drives are not available? What is different so that txtsetup.sif works but the other fails?

Regards,
Galapo.

[MedEvil]

Not all drivers may be installed by the third method, ie preinstallation into the registry at build time. I've been trying to do this with mass storage drivers the last couple of days. I can get drivers installed correctly as they would be under a normal full OS, ie with CriticalDeviceDatabase entries, service entries, etc. What works on a normal XP does not work for an XP PE (but does for Vista PE). Mass storage drivers entered into txtsetup.sif are used at boot and drivers are available, but with CriticalDeviceDatabase entries, service entries, etc they are not used at boot and drives are not available? What is different so that txtsetup.sif works but the other fails?

Where exactly is the CriticalDeviceDatabase in the registry found?
I usually simply set start to boot for a driver and it works.

But what i would love to know is, how can i start a service or a driver manually after i wrote all necessary data into the registry of a running system, without a reboot!
"net /start service" does not work unless the service was already at boot up in the registry defined.

[Galapo]

Where exactly is the CriticalDeviceDatabase in the registry found?

HKLM\system\ControlSet001\Control\CriticalDeviceDatabase

I usually simply set start to boot for a driver and it works.

Yes, but are these drivers mass storage drivers, which are needed at boot?

But what i would love to know is, how can i start a service or a driver manually after i wrote all necessary data into the registry of a running system, without a reboot!
"net /start service" does not work unless the service was already at boot up in the registry defined.

Yes, I've wondered the same. Some drivers by 'default' seem to require a reboot.

Regards,
Galapo.