93 replies to this topic

[pscEx]

phox, thanks for your detailful reply.

autoUPX is my baby, so my reply.

6.1. There is still mistake in my_UPX-Able_DLL.txt (instead of Diskcopy.dl_ there is Diskcopy:dl_ and as a result Diskcopy.dll is not UPXed).

6.2. The my_UPX-Able_DLL.txt is still ignored and 28 dlls are not UPXed:

advapi32.dll
advpack.dll
authz.dll
browselc.dll
clb.dll
comctl32.dll
comdlg32.dll
crypt32.dll
cryptui.dll
ginaorg.dll
iernonce.dll
lsasrv.dll
mpr.dll
msasn1.dll
msprivs.dll
msvcrt.dll
ole32.dll
oleaut32.dll
regapi.dll
rpcrt4.dll
rpcss.dll
secur32.dll
shdoclc.dll
shlwapi.dll
ulib.dll
urlmon.dll
winsta.dll
xpsp2res.dll

6.3. Three biggest dlls in WinSxS folder (Mfc42.dll, Mfc42u.dll and Comctl32.dll) are not UPXed.

6.1: Im going to fix it ASAP

6.2: I used the list Oscar in the 911CD forum published.
Maybe that inside the Standard project files can be UPXed which in BartPE or Reatogo cannot.
To be on the safe side i did not include other files than those from the list.

The my_UPX-Able_DLL.txt file is not longer supported. To include files of your choice into UPXing you have to define them in ProjectInfo.ini (see here or click the Help button in autoUPX.Script.

6.3: Same as 6.2.

If I get some more posts asking for it, I'll include the above files in the UPXable internal list.

Peter

[smiley]

psc: you link has twice the http://

[phox]

If I get some more posts asking for it, I'll include the above files in the UPXable internal list.

Please do it and remove accompanying text from UPX-Able_DLL.txt.
It is simplest way to reduce size of the build!

Thanks, phox.

[TheHive]

If I get some more posts asking for it, I'll include the above files in the UPXable internal list.

Please do it and remove accompanying text from UPX-Able_DLL.txt.
It is simplest way to reduce size of the build!

Thanks, phox.

If it reduces size and doesnt mess anything up that would be good to try. I vote
You could creat a seperate test beta Script with these changes. That way they can be tested but not update the actual script untill we make sure that it doesnt cause anyone any problems.

[was_jaclaz]

This is a part of NTOSKRNL.EXE we'd have to add a /bootlogo parameter to the osloadoptions:

;TXSETUP.SIF extract

[setupdata]; I think that's the section name

osloadoptions="/fastdetect /minint /bootlogo=foo.bmp";I think - from memory this :)

TheHive, you're apparently the resident graphical artist. Do you have time to create a bootlogo for winbuilder's PE build? IIRC, the image needs to be a 16 color .bmp, 640x480 pixels large. That MAY be incorrect though-

I think that it is not so easy, if I am not wrong there are two ways:
1) hexedit ntkrnlmp.exe (potentially illegal)
2) using a third party app (stardock bootskin):
http://www.911cd.net...showtopic=11436
which is however free for non-commercial use:
http://www.stardock....ducts/bootskin/


The one you are referring to, is probably this setting in boot.ini:
http://www.sysintern...on/bootini.html

/BOOTLOGO
Use this switch to have Windows XP or Windows Server 2003 display an installable splash screen instead of the standard splash screen. First, create a 16-color (any 16 colors) 640x480 bitmap and save it in the Windows directory with the name Boot.bmp. Then add "/bootlogo /noguiboot" to the boot.ini selection.

but it appears not to be working if /minint switch is used, or however if used in txtsetup.sif instead of boot.ini:
http://www.911cd.net...p...=8343&st=30
http://www.911cd.net...showtopic=15140

Besides, I wouldn't be so sure it is legal to take off
"Copyright © Microsoft Corporation"
"Microsoft ®"
Windows® XP"
and the "TM" mention

So, if I am wrong, i.e. changing the bootlogo is an easy thing to do, and if TheHive will take the graphical part in his hands , I do suggest to keep the above information in the bootscreen.

jaclaz

[pscEx]

psc: you link has twice the http://

Thaks, smiley, fixed!

@phox, TheHive etc:

What do you think about

It gives to both conservative and progressive users to process like they want.

Peter

[smiley]

@Jacklaz: I remember in the past that Sherpya had created a replacement for bootvid but i havn't tested it...
It may be what we need.

[smiley]

Thaks, smiley, fixed!

@phox, TheHive etc:

What do you think about

It gives to both conversative and progressive users to process like they want.

Peter

[was_jaclaz]

@Jacklaz: I remember in the past that Sherpya had created a replacement for bootvid but i havn't tested it...
It may be what we need.

Yep, it is in one of the links I posted above:
http://www.911cd.net...&showtopic=8343

but I didn't try it.

It works by replacing BOOTVID.DLL, which not being the original one, can be "Resource Hacked" to insert custom image.

Download is here:
http://oss.netfarm.i...npe/plugins.php
http://sourceforge.n...ckage_id=140742

jaclaz

[smiley]

I'll try it right now and post the results!

[phox]

It gives to both conservative and progressive users to process like they want.

If "Aggressively" means UPXing Additional 28 files from system32 folder and three files
from WinSxS folder (Mfc42.dll, Mfc42u.dll and Comctl32.dll) I vote for it!

[TheHive]

Same here about the UPXing.

If you guys can take care of the technincal side and it will be easy to implement a more universal image then you can post results on the new thread.
http://www.boot-land...p?showtopic=339

[phox]

If you guys can take care of the technincal side and it will be easy to implement a more universal image then you can post results on the new thread.

In Explorer script you could select "Show Windows version on Desktop"
and will get inscription "Windows XP Professional". I don't think that MS will like it.

I suggest to change it to show WinBuilder version number.

[smiley]

In Display Properties script you could select “Show Windows version on Desktop”
and will get inscription “Windows XP Professional…”. I don’t think that MS will like it.

I suggest to change it to show WinBuilder version number.

Is this possible?

[was_jaclaz]

Is this possible?

The "regTweak" is this one:
http://www.security-...pic.php?t=37229

Show Windows Version On Desktop
Key: HKCU\Control Panel\Desktop
Value Name: PaintDesktopVersion
Value Type: REG_DWORD
Set To: 1 to enable, 0 to disable (0 Default)
Notes: Displays the current Windows version on top of the desktop wallpaper.

but cannot say from where the info is taken.

jaclaz

[Draugen]

I believe - although this is speculation/educated guesswork - (most of) the information is taken from
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Changing some of the strings here - for example the 'ProductName' key - might change the output of 'win ver on desktop'. Note, might

i'll not get around to testing this myself before tuesday at the earliest though. Busy busy

//martin

[Alexei]

/noguiboot - no splash screen (booting from mem you have to add it in MkISOfs.script).
As I remember, it's bootvid.dll that shows MS picture. Using its clone from ReactOS may be the solution.
As I know, patched bootvid.dll is not legal in most countries, unless you patch it in memory after loading (by custom kernel driver you have to write), though /noguiboot works fine for me
BTW, can UPX patch while unpacking, would it be always "legal"?

Alexei

[Brito]

Well.. I think using a cloned file from the ReactOS project would be an excellent solution since it would definitively put everything on a legal base without objections..

If I recall correctly, one could use resource hacker to replace the logo for a customized one. This program was coded in delphi also. I'll look for some routines to handle resources within dll's and exe's to see if this can also be added as a script command option..

[pscEx]

If "Aggressively" means UPXing Additional 28 files from system32 folder and three files
from WinSxS folder (Mfc42.dll, Mfc42u.dll and Comctl32.dll) I vote for it!

See here

Once again (from post #51)

6.2: I used the list Oscar in the 911CD forum published.
Maybe that inside the Standard project files can be UPXed which in BartPE or Reatogo cannot.
To be on the safe side i did not include other files than those from the list.

Peter

[Moon Goon]

WinBuilder no longer crashes when WinBuilder.INI is not present.

but..

If WinBuilder.INI or any script.project files are set as read-only it barfs.

Not a biggie but someday I'd like to try using WinBuilder from a BartPE disc - which is usually read-only

[Brito]

Moon Goon, thanks for noticing it, I'll repeat the same steps and work until it is supported!


In the meanwhile:

I've pratically finished the script dependencies. If a script is included in the dependencies list of another script, winbuilder will try to find it, three situations may occur:

1) script is found on list - always enable it
2) script is not found on list - go look for it on the archive folder (if found add a link)
3) script is not found in neither locations - show error message, but allow to continue


Is this the expected behavior or there is anything else needed to add on this?


just to avoid uploading a few betas with minor changes..

[smiley]

@Nuno: I think that it must ask the user if he wants the script to be activated

[Brito]

Hmm.. I've also thought on that, but imagine the explorer script: how would it work without having the ramdisk.script also enabled?

[Draugen]

In the above situation, tell the user that the explorer script (for example) needs (for example) ramdisk.script to be enabled, and ask if that's OK. If that's NOT ok, tell the user that this will cripple the (for example) explorer script, which may or may not have unforeseen consequences. At this point ask the user if he wants to continue anyway, or just disable the script with an unmet dependency.

Disabling the script with an unmet dependency may seem harsh, but a dependency is a dependency. Now, if WB at some point supports OPTIONAL dependencies (and the current concept of 'dependencies' become 'requirements'), that might change.

If the script is not found at all, an idea (for WB 051+n) is to ask the user if it should be downloaded.

[Brito]

In the above situation, tell the user that the explorer script (for example) needs (for example) ramdisk.script to be enabled, and ask if that's OK. If that's NOT ok, tell the user that this will cripple the (for example) explorer script, which may or may not have unforeseen consequences. At this point ask the user if he wants to continue anyway, or just disable the script with an unmet dependency.

Disabling the script with an unmet dependency may seem harsh, but a dependency is a dependency. Now, if WB at some point supports OPTIONAL dependencies (and the current concept of 'dependencies' become 'requirements'), that might change.

I agree, the script should not be enabled unless all needed scripts are also available.

If the script is not found at all, an idea (for WB 051+n) is to ask the user if it should be downloaded.

This is a very good sugestion indeed!

Perhaps using a section called [process-dependencies] wich could be run whenever this sort of issue ocorred. This way each developer could define his prefered way to do things - much alike alexei is developing at this moment.

On the other hand, one could settle a "fixed" way of doing this, thus easing the life of those who could take advantage of this already being implemented and using standard procedures instead of having to make one themselves.

Where should the dependency file be downloaded from?

update.boot-land.net is likely the right place to add this sort of information, but I'm afraid in the future this system would have to be much more flexible to allow other ways of doing things, not to mention the fear of having an updates.ini sized in a few Mb's after a few years..

I guess I'll likely follow a mixed updates/dependencies section approach for now:

[dependencies]

...

myApp.zip=http://www.somewhere.com/myApp.zip

myDLLfile.dll=http://www.somewhere.com/myCurrentDLLfile.dll

...

This way whenever a needed file wasn't found there would still be an alternative to download it.. (as long as web acess is also available)

What do you think?