29 replies to this topic

[pscEx]

Some minutes ago I delivered a new version of HoJoPE PicoXP
This version does not need the encoded (from BartPE?) setupreg.hiv anymore.
setupreg.hiv now is created using only the setup CD and a controlfile 'setupreg.hiv.ctl'.

Now we are only one step away (software.hiv) from being completely independent from any xxxPE

'setupreg.hiv.ctl' manages:
Which keys may be deleted from the setupreg.hiv copied from the install CD

[Remove]

HKLM,"SYSTEM\CurrentControlSet\Control\HAL"@1

HKLM,"SYSTEM\CurrentControlSet\Control\IDConfigDB"@1

...

Which keys are copied from different files of the setup CD

[DMREG.INF]DM.AddReg

HKLM,"SYSTEM\CurrentControlSet\Services\dmboot"@1

HKLM,"SYSTEM\CurrentControlSet\Services\dmadmin"@1

HKLM,"SYSTEM\CurrentControlSet\Services\dmio"@1

...

[HIVESYS.INF]AddReg

HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}@1

HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}@1

...

Which additional entries are necessary to bring the build to run (this code is complete)

[Add]
HKLM,"SYSTEM\Setup","OsLoaderPath",,"\"@1
HKLM,"SYSTEM\Setup","SetupType",0x00010001,1@1
HKLM,"SYSTEM\Setup","SystemSetupInProgress",0x00010001,1@1

Enjoy testing!

Peter

BTW @1 again means PicoXP, @2 will be Standard etc ...

[Draugen]

Good work!

psc, would you mind terribly much if i lift the relevant .reg entries into ModPE? if possible, i might even just 'exec' your script i'll see what works best for me 8)

//martin

[pscEx]

Good work!

psc, would you mind terribly much if i lift the relevant .reg entries into ModPE? if possible, i might even just 'exec' your script i'll see what works best for me 8)

//martin

I wouldn't mind when you use it.
But I think, it's too early. The current functionality is for PicoXP only - no graphical interface etc.

But would be great, if you enlarge the setupreg.hiv.ctl for these issues.

Peter

[Brito]

Excellent work!!


Worked really good at the first time without any visible errors.

The ISO was sized in 18,26Mb and booted just as usual, took a bit longer since it was generating the hives, but this is very normal on a slow PIII (~50 seconds), I guess on a standard desktop this should be around 2~5 seconds or less.


Can you also add a script for chkdsk as an option?

Is this project only compatible with the updated reg commands on the winbuilder.exe I've posted yesterday?

If so, here it is..


Overall: This is really looking great!

[pscEx]

The ISO was sized in 18,26Mb and booted just as usual, took a bit longer since it was generating the hives, but this is very normal on a slow PIII (~50 seconds), I guess on a standard desktop this should be around 2~5 seconds or less.

Remember: Currently I'm delivering 'functionalty only'. In the final version I want to have stored *.hiv - es, which are generated only if either the OS or the language or the version of the script has changed. So delivering of the hive is only a copy from ...\HoJoPE.

Is this project only compatible with the updated reg commands on the winbuilder.exe I've posted yesterday?

Yes, it is. Without these changes some RegWrites will bring unusable results.
BTW My '0x0' wish would save 2 seconds on my 2.4 Gig P IV - each ShellExecute Reg takes about half a second.

[Can you also add a script for chkdsk as an option?

It's a question of a separare script.
I had some problems to remove the autochk functionality. So I know how to bring back and use chkdisk. Later ..., Next step is replacing encoded software.hiv.

Peter

[Alexei]

Now we are only one step away (software.hiv) from being completely independent from any xxxPE

My congratulations

BTW @1 again means PicoXP, @2 will be Standard etc ...

I'm afraid, after "Standard"(and maybe even before) it could be several branches (by major components), such as Disk Manager, Networking, Notepad, etc. .
I'd like to be able to specify corrections to common .ctl file by providing overrides specific to particular project or script (it's also good for testing). This way @1..N would correspond" to basic level" of the project, still leaving ability to "fine tune" Script that adds some entries deleted by .ctl doesn't look as good solution to me Usually, excessive entries in registry are harmless, but...

Alexei

[pscEx]

My congratulations
I'm afraid, after "Standard"(and maybe even before) it could be several branches (by major components), such as Disk Manager, Networking, Notepad, etc. .
I'd like to be able to specify corrections to common .ctl file by providing overrides specific to particular project or script (it's also good for testing). This way @1..N would correspond" to basic level" of the project, still leaving ability to "fine tune" Script that adds some entries deleted by .ctl doesn't look as good solution to me Usually, excessive entries in registry are harmless, but...

Alexei

Let me simplify:
@1 means that txtsetup.sif, setupreg.hiv, software hive are nearly the same like the currently encoded files, but are created from scratch (just cmd level, no graphics).
@2 means that txtsetup.sif, setupreg.hiv, software hive, default hive are nearly the same like the currently encoded files, but are created from scratch (level with graphics).
@3 I currently do not know ...

Applications like Notepad etc. do not affect HoJoPE, they are just added like now. So you can replace inside an project the text.script, hives.script, localization.script and whatever.script-s by the new HoJoPE scripts and everything works like before!

Peter

[TheHive]

You added your Dokumente und Einstellungen. Folders are empty but just wanted to mention it.

Created a working PicoXP.

The Run ISO in Qemu layout looks bad but seems to run.


Log reports 1 error
#480 [Failed] RegWrite - Failed to write REG key in root key: [HKLM] Type: [0x4] Section: [WB_System\ControlSet001\Services\NDIS\Parameters] Key: [ProcessorAffinityMask=4294967295..]

[pscEx]

You added your Dokumente und Einstellungen. Folders are empty but just wanted to mention it.

Created a working PicoXP.

The Run ISO in Qemu layout looks bad but seems to run.

Log reports 1 error
#480 [Failed] RegWrite - Failed to write REG key in root key: [HKLM] Type: [0x4] Section: [WB_System\ControlSet001\Services\NDIS\Parameters] Key: [ProcessorAffinityMask=4294967295..]

@TheHive,

Many thanks for your careful tests.
(Sometimes I have the opinion: If you do not post, everything is ok )
I'm glad: Your post shows me that with my HoJoPE delivering everything seems to be ok.

The 'confused' screen I transfer to Nuno. I yesterday once got a similar result in a different task: Sometimes (If I would know when I would post) a GUI is overlapped by the output of a different GUI.

The error in the log is caused by the version of WinBuilder you have.
It is supposed to be a 'feature' of the currently released WinBuilder version. Nuno already posted a beta version which handles this issue correct. I think that this version will become the official version soon.

You added your Dokumente und Einstellungen. Folders are empty but just wanted to mention it.

Is there anything German (would be dreadful)?

Peter

[Brito]

The Run ISO in Qemu layout looks bad but seems to run.

The interface bug strikes again..

[TheHive]

@TheHive,

Many thanks for your careful tests.
(Sometimes I have the opinion: If you do not post, everything is ok )
I'm glad: Your post shows me that with my HoJoPE delivering everything seems to be ok.

The error in the log is caused by the version of WinBuilder you have.
It is supposed to be a 'feature' of the currently released WinBuilder version. Nuno already posted a beta version which handles this issue correct. I think that this version will become the official version soon.

I was testing with latest beta 4 version. But the version you linked to, seems to build without reporting any errors in the log. .

Is there anything German (would be dreadful)?

Not dreadful. Just wont be able to understand all of it very well.

[Alexei]

I was testing with latest beta 4 version. But the version you linked to, seems to build without reporting any errors in the log. .
Not dreadful. Just wont be able to understand all of it very well.

Same happend with me
BTW, WinBuilder needs to show full version id in the title
Unfortunately, still doesn't look good, see attached
But it works

Alexei

Attached Thumbnails

• 
• 
• 

[Brito]

It doesn't look good indeed.. I wonder why?

Full version on title should provide better info on the currently used beta, I'll add it!


I've also noticed that you're using a system font and no XP themes, can you describe a little the specs of your machine and OS to get a better idea on the differences from my own?

Perhaps this way I can figure where to adapt the interface..

[Alexei]

It doesn't look good indeed.. I wonder why?

Full version on title should provide better info on the currently used beta, I'll add it!
I've also noticed that you're using a system font and no XP themes, can you describe a little the specs of your machine and OS to get a better idea on the differences from my own?

Perhaps this way I can figure where to adapt the interface..

It's 2003, "Large Size(120DPI)", 1280x768-32bit,
Modified "Windows Classic style" theme:
ActiveTitleBar[20] - Microsoft Sans Serif[9,B]
Message Box[20] - MS Sans Serif[8]
Menu[20] - MS Sans Serif[8,B]
Icon[32] - Microsoft Sans Serif[8,B]
Caption Buttons[20]
Icon Spacing H=50 V=50
Scroll Bar[20]
Active Window Border[1]
, where in Item[S] - Font[N,B] S-size, N-font size, B-bold

Another one is similar, but it's W2K, 1152x864, 120DPI, size 22-10, large fonts
another - 1260x768, sizes 8-10 and 20-11, small fonts
another - 1024x768, sizes 18-10 and 22-12, small fonts

When you say it's ready I would test on all of them

It's rather unusual way of doing this, but you can adjust font size to fit window (also on "resize"-event). That would eliminate the problem However, max font N should be defined, to avoid comic look after "Maximize"

Sorry, bothering you with my custom settings

Alexei

Also:

Attached Thumbnails

• 
• 

[Brito]

Thanks for the details!!

I'll work on them..

[smiley]

Doeas this copy all the contents of the ***hive.inf in the hives?

[pscEx]

Doeas this copy all the contents of the ***hive.inf in the hives?

No.
It first copies setupreg.hiv and deletes unnecessary keys.
Then it includes only those keys from hivesys.inf and dmreg.inf which are necessary to build a new setupreg.hiv suited to run PicoXP.

Peter

[smiley]

Can you make one to aork for the standard project like tihis?
-The script will tell to the program which .inf files to open
-The script will have the option to copy all the contents of the inf files
-The hives.script will have advanced options to select some parts of the infs not to include.


Smiley

[pscEx]

Can you make one to aork for the standard project like tihis?
-The script will tell to the program which .inf files to open
-The script will have the option to copy all the contents of the inf files
-The hives.script will have advanced options to select some parts of the infs not to include.
Smiley

Step bys Step ...
First I'll finish the PicoXP part:
- The software hive is still encoded.
- The logical flow of the project has to be tuned: Generate hives, txtsetup.sif etc. only when necessary (after a install CD change or with a new version of the script). In the other cases just do a copy of the existing files.

Next will be the Standard project. But that will be done by only adding several @2 lines to the existing control files, no logic or program changes..

If you have a look into txtsetup.ctl and setupreg.hiv.ctl you see what I mean. These .ctl files are substitutes for the options you mentioned.

Peter

[Alexei]

- The logical flow of the project has to be tuned: Generate hives, txtsetup.sif etc. only when necessary (after a install CD change or with a new version of the script). In the other cases just do a copy of the existing files.

I completely disagree
Everything must be created from scratch at each build. The reason is simple - realibility! If you make the build depend on results of previous ones (that's what "if necessary" actually means), you would end up with less reliable solution (regardless of how careful you're gonna track changes, analyze the situation, or whatever...)
If general statements do not work for you, here some examples: SP was applied to the source, user placed updated source to the same place, other scripts updated, whole PC restore from backup, experiments with cloned project, debugging/testing, and many other situations that you have to support
Dealing with "system" stuff we should always prefer stability to timing issues. Yes, always
Sorry, if it sounds too agressive/pushy/emotional...

Alexei
PS
However, if you want to save developer's time you may allow him to disable "preparation" script manually, which should lead to using already created files/scripts. That would be clean solution, kind of "you got what you asked for" , with possible error message "File *** does not exist, please enable *** script"

[pscEx]

I completely disagree
Everything must be created from scratch at each build. The reason is simple - realibility! If you make the build depend on results of previous ones (that's what "if necessary" actually means), you would end up with less reliable solution (regardless of how careful you're gonna track changes, analyze the situation, or whatever...)
If general statements do not work for you, here some examples: SP was applied to the source, user placed updated source to the same place, other scripts updated, whole PC restore from backup, experiments with cloned project, debugging/testing, and many other situations that you have to support
Dealing with "system" stuff we should always prefer stability to timing issues. Yes, always
Sorry, if it sounds too agressive/pushy/emotional...

Alexei
PS
However, if you want to save developer's time you may allow him to disable "preparation" script manually, which should lead to using already created files/scripts. That would be clean solution, kind of "you got what you asked for" , with possible error message "File *** does not exist, please enable *** script"

You completely misunderstood:
The previously encoded setupreg.hiv, software and txtsetup.sif are now generated once depending on the install CD.
Whenever the user wants he can creating them again by clicking a button.

Of course every build starts with these standards, no dependency on a previous build!

Peter

[Alexei]

If you have a look into txtsetup.ctl and setupreg.hiv.ctl you see what I mean. These .ctl files are substitutes for the options you mentioned.

So, how to get control over contents of the .ctl files?
What support you plan to offer to include/exclude "components"?
Somebody wants to boot from 1394 (txtsetup issue), what he should do?
Somebody wants to access exotic SCSI (setupreg issue), what he should do?
In general, let's make it modular
I mean having several .ctl files and giving user control over which to include into what
For example (not good example though): USB support choises: txtsetup/setupreg/drivers/ignore
How would you support such stuff otherwise?
If you mean developers would write updates to results of already processed .ctl, that's not good because: 1. to much work, 2. tends to duplications 3. changes in core (.ctl) may require changes in updating scripts. Not good
What do you think?

Alexei

[pscEx]

So, how to get control over contents of the .ctl files?
What support you plan to offer to include/exclude "components"?

No support scheduled! Once again: The files are used to generate the basic files which currently are encoded.

Somebody wants to boot from 1394 (txtsetup issue), what he should do?
Somebody wants to access exotic SCSI (setupreg issue), what he should do?

Same way like it works now: He has to write a script, doing the necessary copies, registry entries etc.

In general, let's make it modular
I mean having several .ctl files and giving user control over which to include into what

Waiting for your detailed concept to be posted here.

Peter

[Alexei]

You completely misunderstood:

Maybe

The previously encoded setupreg.hiv, software and txtsetup.sif are now generated once depending on the install CD.

When they were ecoded, they were created (extracted from the script) at each build Does "generated once" means "generated by one of presious previous builds"?

Whenever the user wants he can creating them again by clicking a button.

Do you mean "Run" button?

It may be just terminology, though I call "build" the process that is started by clicking "Run" button. It would be logical to call it "building", but "building" means the thing that was built ***ing english
So, to me, if something was created by clicking "Run" and then used after second click on "Run" means the Build uses results of previous Build. And that's what I meant in my previous post.

Alexei

[pscEx]

As one sample - for me the finish of this discussion

Peter