HoJoPE

first of all thanks for Winbuilder,
I've noticed that registry hives have some wrong entries
(HOJOPE bug?)

1. Problem
some entries in in hivecls.inf look like %%somthing%% e.g
HKCR,"mscfile","FriendlyTypeName",0x00020000,"@%%SystemRoot%%\system32\mmcbase.dll,-130"

"@%%SystemRoot%%\system32\mmcbase.dll,-130" should be translated : "@%SystemRoot%\system32\mmcbase.dll,-130"

2. Problem (German Source Cd's maybe other languages too)

look in file TXTSETUP.sif , section [FontListE]

"Courier 10,12,15 (VGA-Aufl”sung)" should be translated to "Courier 10,12,15 (VGA-Auflösung)"
there is a problem (font bug, all dialog fonts are bold) caused by bad font entries
under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts if tahoma font
is used as system font. (see HCU\Control Panel\Desktop\WindowMetrics\CaptionFont .....)

3.
hivedef.inf :

HKCU,"Control Panel\International","s1159",0x00000002,"%INTL_S1159%"
HKCU,"Control Panel\International","s1159",0x00000002,"%INTL_S2359%"

should result in

[HKEY_CURRENT_USER\Control Panel\International]
"s1159" = ""
because INTL_S1159 is defined in the [Strings] section


can it be fixed?

(Winbuilder 075 beta 4u / XP SP3 host and source)
(can someone confirm running winbuiler on XP x64 host?
espacially OLESupport script running redirected syswow64 software hive)

thanx

there is a problem (font bug, all dialog fonts are bold) caused by bad font entries

it is not hojope's fault (i highly believe)
anyway
issue already solved with great help by dera and galapo put it in livexp project ---->inside EsentlFonts.script

can someone confirm running winbuilder on XP x64 host?

yes i can confirm, all found compatibility issues with livexp project solved by great effort by galapo and nikzzzz
and i still use x64 as host

it is not hojope's fault (i highly believe)
anyway
issue already solved with great help by dera and galapo put it in livexp project ---->inside EsentlFonts.script


yes i can confirm, all found compatibility issues with livexp project solved by great effort by galapo and nikzzzz
and i still use x64 as host

helo Lancelot , thanx for answer.

EsentlFonts.script (version 6) does not fix the bad entries in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts,
it replaces tahoma back to arial (Control Panel\Desktop\WindowMetrics, Microsoft\Windows NT\CurrentVersion\FontSubstitutes).
it seems to work, but with selected EsentlFonts.script some programs may fail to start (Sysinternals Process Explorer).

i have tried winbuilder on x64 to and it works!!!
(i have problems with shortcuts like in regshot created via Add_Shortcut,StartMenu , no problems via Run,%BuildModelScript%,Add-Shortcut,"SM"....)

there is a problem (font bug, all dialog fonts are bold) caused by bad font entries
under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts if tahoma font
is used as system font. (see HCU\Control Panel\Desktop\WindowMetrics\CaptionFont .....)

You are absolutely right!
using WB075 beta4 (the official beta) and LiveXP with Hives Factory Version=45
tried to export the registry keys from a real OS
Microsoft\Windows NT\CurrentVersion\Fonts
Microsoft\Windows NT\CurrentVersion\FontSubstitutes
Microsoft\Windows NT\CurrentVersion\FontMapper
Microsoft\Windows NT\CurrentVersion\GRE_Initialize
Control Panel\Desktop\WindowMetrics
then deleted the original registry keys in the PE registry, and imported the keys from the real OS
via regedit.exe
and the tahoma bold issue gone!

The strange is that used the above reg keys via WB (exported the key from real OS, converted the .reg file with reg2WBS.exe to a script but didn't deleted the existing keys) but this method for me didn't solve the tahoma bold issue.

hi fxscrpt

for x64 compatilibity there are little things you should be carelful
1)
be carelful when using "get files" option as you are hosting a x64
http://www.boot-land...?...ost&p=42834
2)
be carelful about scripts that configures itsself with the existing installed utilites (rarely)
3)
because of a bug with winbuilder, an error occurs...... (for detailed look here http://www.boot-land...?...st&p=42831)
luckly this kind of usage is not popular in livexp project,
i made a small fix for opera script http://lancelot.winb...LancelotAdd.rar and there are no more known x64 comp. issue about this anymore.

dera
but this method for me didn't solve the tahoma bold issue

?????
i dont have anymore tahoma bold issue? with EsentlFonts.script enabled.
processs explorer, process monitor works nicely.

but as the main reason of tahamo bold issue seem to be found, i hope peter fix it in some latin american days Till that day changin to arial by EsentlFonts.script works fine for me.

fxscrpt
i have problems with shortcuts like in regshot created via Add_Shortcut,StartMenu

I dont have a problem with regshot or shortcut of regshot under livexp.



ps: i am using WB075 beta4 (the official beta) too

The strange is that used the above reg keys via WB (exported the key from real OS, converted the .reg file with reg2WBS.exe to a script but didn't deleted the existing keys) but this method for me didn't solve the tahoma bold issue.

yes, that's quite strange. I wonder what the reason for that behaviour is? Hopefully Peter might have an idea.

Regards,
Galapo.

I should to double check it, one sure I have script - made before - that try to set those fonts keys without success, but now I am not fully sure exactly how I made this script.
Maybe it is really HoJoPE problem, as wrote here , so that nativeEx_barebone based build use an older version of Hives Factory and in that build my fontsetting script works.

You are absolutely right!
using WB075 beta4 (the official beta) and LiveXP with Hives Factory Version=45
tried to export the registry keys from a real OS
Microsoft\Windows NT\CurrentVersion\Fonts
Microsoft\Windows NT\CurrentVersion\FontSubstitutes
Microsoft\Windows NT\CurrentVersion\FontMapper
Microsoft\Windows NT\CurrentVersion\GRE_Initialize
Control Panel\Desktop\WindowMetrics
then deleted the original registry keys in the PE registry, and imported the keys from the real OS
via regedit.exe
and the tahoma bold issue gone!

The strange is that used the above reg keys via WB (exported the key from real OS, converted the .reg file with reg2WBS.exe to a script but didn't deleted the existing keys) but this method for me didn't solve the tahoma bold issue.

hi dera,

simply adding the keys from a real OS results in a mix of
"Courier 10,12,15 (VGA-Aufl”sung)" and "Courier 10,12,15 (VGA-Auflösung)" existing both.
the bad entrie has to be deleted to avoid the font bug.

on my build process explorer (11.21) really does not start.

on my build process explorer (11.21) really does not start.

Me too!

hi dera,

simply adding the keys from a real OS results in a mix of
"Courier 10,12,15 (VGA-Aufl"sung)" and "Courier 10,12,15 (VGA-Auflösung)" existing both.
the bad entrie has to be deleted to avoid the font bug.

on my build process explorer (11.21) really does not start.

Me too!

It is really not the best idea to try to hide symptoms, rather than
fixing the root of the issue.

Peter

I've noticed that registry hives have some wrong entries
(HOJOPE bug?)
some entries in in hivecls.inf look like %%somthing%% e.g
HKCR,"mscfile","FriendlyTypeName",0x00020000,"@%%SystemRoot%%\system32\mmcbase.dll,-130"

The double percentages really seems to be wrong.
But it is written in the original delivered hivecls.inf of SP3 (SP2 does not contain).
HoJoPE only converts source CD entries to WinBuilder statements and is not allowed to replace the double percentage by a single one.
It is a feature of Billy the Door and could be changed by a tweak script in case of XP SP3.

look in file TXTSETUP.sif , section [FontListE]
"Courier 10,12,15 (VGA-Aufl"sung)" should be translated to "Courier 10,12,15 (VGA-Auflösung)"
there is a problem (font bug, all dialog fonts are bold) caused by bad font entries
under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts if tahoma font
is used as system font. (see HCU\Control Panel\Desktop\WindowMetrics\CaptionFont .....)

Similar explanation:
If you look into the original source CD: The txtsetup.sif line there is the same one.
It depends on using DOS character set rather than ANSI
Here, too, HoJoPE only transferres lines, no 'intelligent' change.

there is a problem (font bug, all dialog fonts are bold) caused by bad font entries
under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts if tahoma font
is used as system font. (see HCU\Control Panel\Desktop\WindowMetrics\CaptionFont .....)

I do not undertand competely.
Can you explain a bit more?
BTW: If you want to tell us that entries in HCU\Control Panel\Desktop\WindowMetrics are wrong:
HoJoPE again writes entries from hivedef.inf into the registry.
It is not a job of HoJoPE to modify these entries.
They must be defined by the explorer script or by tweak scripts.
Here again my opinion: The several tweak scripts disturb more issues than they fix!

HKCU,"Control Panel\International","s1159",0x00000002,"%INTL_S1159%"
HKCU,"Control Panel\International","s1159",0x00000002,"%INTL_S2359%"

should result in

[HKEY_CURRENT_USER\Control Panel\International]
"s1159" = ""
because INTL_S1159 is defined in the [Strings] section

That is wrong.
When writing the WinBuilder registry script lines, HoJoPE replaces the (language independent) labels with the corresponding (language dependent) entries in the [string] section.

Peter

It is really not the best idea to try to hide symptoms, rather than
fixing the root of the issue.

Peter

hello Peter ,
i agree.
i think TXTSETUP.SIF is not ANSI-coded and has to be translated (OEM>ANSI???) when building hives.

what about Problem 1 and 3?

Peter

hello Peter ,
i agree.
i think TXTSETUP.SIF is not ANSI-coded and has to be translated (OEM>ANSI???) when building hives.

what about Problem 1 and 3?

Peter

I think if you read my reply which crossed yours, you know more.

BTW: Look into my signature about 'Problems'

Peter

Hello Peter,

The double percentages really seems to be wrong.
But it is written in the original delivered hivecls.inf of SP3 (SP2 does not contain).
HoJoPE only converts source CD entries to WinBuilder statements and is not allowed to replace the double percentage by a single one.
It is a feature of Billy the Door and could be changed by a tweak script in case of XP SP3.

yes , it can be done by a fix ,
however many double percentages are on server2003 R2 source too and XP SP3
XP SP2 (only 1 key HKCR,"MsRcIncident\shell\open\command)

I do not undertand competely.
Can you explain a bit more?

using german source cd the build process creates some bad entries in
hklm\software\miscrosoft\windows nt\font
a)


"Courier 10,12,15 (VGA-Aufl”sung)"
"MS Sans Serif 8,10,12,14,18,24 (VGA-Aufl”sung)"
"MS Serif 8,10,12,14,18,24 (VGA-Aufl”sung)"
"Tahoma (TrueType)"
"Microsoft Sans Serif (TrueType)"

if tahoma font is not installed all seems ok , because arial is used.
if tahoma is installed (eg by EsentlFonts.script) all seems ok, because default settings of using tahoma
are overriden by EsentlFonts.script to use arial. i dont know whats wrong with EsentlFonts.script, but
running [Process-reg] in this script causes on my build a problem (Process Explorer does not start)

running EsentlFonts.script without [Process-reg] (tahoma is used) ends up
in the font bug (no EsentlFonts.script prob) , because of a)

That is wrong.
When writing the WinBuilder registry script lines, HoJoPE replaces the (language independent) labels with the corresponding (language dependent) entries in the [string] section.

in my case HoJoPE does not.
in the [Strings] section (XP SP3) INTL_S1159 is set to "" (empty string) , but in the registry
the value is %INTL_S1159%

Peter

hi fxscrpt

for x64 compatilibity there are little things you should be carelful
1)
be carelful when using "get files" option as you are hosting a x64
http://www.boot-land...?...ost&p=42834
2)
be carelful about scripts that configures itsself with the existing installed utilites (rarely)
3)
because of a bug with winbuilder, an error occurs...... (for detailed look here http://www.boot-land...?...st&p=42831)
luckly this kind of usage is not popular in livexp project,
i made a small fix for opera script http://lancelot.winb...LancelotAdd.rar and there are no more known x64 comp. issue about this anymore.



?????
i dont have anymore tahoma bold issue? with EsentlFonts.script enabled.
processs explorer, process monitor works nicely.

but as the main reason of tahamo bold issue seem to be found, i hope peter fix it in some latin american days Till that day changin to arial by EsentlFonts.script works fine for me.


I dont have a problem with regshot or shortcut of regshot under livexp.



ps: i am using WB075 beta4 (the official beta) too

Lancelot, thanx you for hints.

building from x64 (XP german mui, Server2003 eng.) shurcuts created via Add_Shortcut,StartMenu
have no icons. the icons are restored on first cklick. its no problem for me and maybe a problem with my host os.

Peter

have no icons. the icons are restored on first cklick. its no problem for me and maybe a problem with my host os.

Navigate to Basic > Build > BuildModel and uncheck "Do not refresh shortcuts on ISO boot".

Then you have the icons from the very beginning (but the boot needs some seconds more time, depending on the number of icons; in a small nativeEx_barebone the time is not measurable)

Peter

in my case HoJoPE does not.
in the [Strings] section (XP SP3) INTL_S1159 is set to "" (empty string) , but in the registry
the value is %INTL_S1159%

ok. That seems to be a bug.
If the [strings] value is not defined, the label's name is used.

I'll check.

Thanks

Peter

fxscrpt
-
i guess Peter's advice solve your problem with shorcut?

Navigate to Basic > Build > BuildModel and uncheck "Do not refresh shortcuts on ISO boot".

-
forgot long time before and remembered today by noticing sth, autolocalization script cause problem with x64 host (at least with me), i guess galapo will put require adding to prevent users enableing autolocalization script when host is x64 in nearfeature, it is my fault not to mention before.
Anyway Shortly, disable autolocalization script

-
dont worry fxscrpt, winbuilder with x64 host is fine, i use it all the time
with reports of you and me, it will be finer



fxscrpt & dera:
can you post a log file of livexp you use (with disable ing autolocalization script) so i can try to reproduce process exp problem you have.

I am using WB075 beta4 (the official beta) and LiveXP with Hives Factory Version=45, only for English source
Here is my Fonts test script[attachment=6329:tahomabd.7z]

hi dera

after some testing i have found : the entry order is essential

first load into registry

"Tahoma (TrueType)"="TAHOMA.TTF"

then
"Microsoft Sans Serif (TrueType)"="MICROSS.TTF"

Peter

after some testing i have found : the entry order is essential

first load into registry

"Tahoma (TrueType)"="TAHOMA.TTF"

then
"Microsoft Sans Serif (TrueType)"="MICROSS.TTF"

That cannot be true.

The registry at boot time is always the same, independent from the order the entries have been made.

You should test with 'Fresh' builds: Delete Workbench and Temp before the next trial build.

Peter

I am using WB075 beta4 (the official beta) and LiveXP with Hives Factory Version=45, only for English source
Here is my Fonts test script[attachment=6329:tahomabd.7z]

There is ONLY ONE difference:

In WB the line
"Symbol 8,10,12,14,18,24 (VGA res)"="SYMBOLE.FON"
is missing.

Peter

ok. That seems to be a bug.
If the [strings] value is not defined, the label's name is used.

I'll check.

Thanks

Peter

thank you Peter

That cannot be true.

The registry at boot time is always the same, independent from the order the entries have been made.

You should test with 'Fresh' builds: Delete Workbench and Temp before the next trial build.

Peter

steps to reproduce:

run EsentlFonts.script with tahoma enabeled, but disable two lines:

If,%pCheckBox21%,Equal,True,If,%check%,Equal,0,Run,%ScriptFile%,Process-reg
If,%pCheckBox22%,Equal,True,If,%check%,Equal,0,Run,%ScriptFile%,Process-reg

make a new LiveXp

mount target\...\software as new hive a
delete \software\microsoft\windows nt\fonts from mounted hive

import this file (replace (Alle Auflösungen) > (VGA res) for english source, not tested for english source)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\a\Microsoft\Windows NT\CurrentVersion\Fonts]
"Arial (TrueType)"="ARIAL.TTF"
"Arial Black (TrueType)"="ariblk.TTF"
"Arial Fett (TrueType)"="ARIALBD.TTF"
"Arial Fett Kursiv (TrueType)"="ARIALBI.TTF"
"Arial Kursiv (TrueType)"="ARIALI.TTF"
"Courier New (TrueType)"="COUR.TTF"
"Courier New Fett (TrueType)"="COURBD.TTF"
"Courier New Fett Kursiv (TrueType)"="COURBI.TTF"
"Courier New Kursiv (TrueType)"="COURI.TTF"
"Modern (Alle Auflösungen)"="MODERN.FON"
"Roman (Alle Auflösungen)"="ROMAN.FON"
"Script (Alle Auflösungen)"="SCRIPT.FON"
"Small Fonts (VGA-Auflösung)"="SMALLE.FON"
"Tahoma Fett (TrueType)"="tahomabd.TTF"
"WST_Czec (Alle Auflösungen)"="wst_czec.FON"
"WST_Engl (Alle Auflösungen)"="wst_engl.FON"
"WST_Fren (Alle Auflösungen)"="wst_fren.FON"
"WST_Germ (Alle Auflösungen)"="wst_germ.FON"
"WST_Ital (Alle Auflösungen)"="wst_ital.FON"
"WST_Span (Alle Auflösungen)"="wst_span.FON"
"WST_Swed (Alle Auflösungen)"="wst_swed.FON"
"Microsoft Sans Serif (TrueType)"="MICROSS.TTF"
"Tahoma (TrueType)"="TAHOMA.TTF"
"MS Sans Serif 8,10,12,14,18,24 (VGA-Auflösung)"="SSERIFE.FON"
"MS Serif 8,10,12,14,18,24 (VGA-Auflösung)"="SERIFE.FON"
"Courier 10,12,15 (VGA-Auflösung)"="COURE.FON"

unmount and create new iso > font bug

repeat with this file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\a\Microsoft\Windows NT\CurrentVersion\Fonts]
"Arial (TrueType)"="ARIAL.TTF"
"Arial Black (TrueType)"="ariblk.TTF"
"Arial Fett (TrueType)"="ARIALBD.TTF"
"Arial Fett Kursiv (TrueType)"="ARIALBI.TTF"
"Arial Kursiv (TrueType)"="ARIALI.TTF"
"Courier New (TrueType)"="COUR.TTF"
"Courier New Fett (TrueType)"="COURBD.TTF"
"Courier New Fett Kursiv (TrueType)"="COURBI.TTF"
"Courier New Kursiv (TrueType)"="COURI.TTF"
"Modern (Alle Auflösungen)"="MODERN.FON"
"Roman (Alle Auflösungen)"="ROMAN.FON"
"Script (Alle Auflösungen)"="SCRIPT.FON"
"Small Fonts (VGA-Auflösung)"="SMALLE.FON"
"Tahoma Fett (TrueType)"="tahomabd.TTF"
"WST_Czec (Alle Auflösungen)"="wst_czec.FON"
"WST_Engl (Alle Auflösungen)"="wst_engl.FON"
"WST_Fren (Alle Auflösungen)"="wst_fren.FON"
"WST_Germ (Alle Auflösungen)"="wst_germ.FON"
"WST_Ital (Alle Auflösungen)"="wst_ital.FON"
"WST_Span (Alle Auflösungen)"="wst_span.FON"
"WST_Swed (Alle Auflösungen)"="wst_swed.FON"
"Tahoma (TrueType)"="TAHOMA.TTF"
"Microsoft Sans Serif (TrueType)"="MICROSS.TTF"
"MS Sans Serif 8,10,12,14,18,24 (VGA-Auflösung)"="SSERIFE.FON"
"MS Serif 8,10,12,14,18,24 (VGA-Auflösung)"="SERIFE.FON"
"Courier 10,12,15 (VGA-Auflösung)"="COURE.FON"

create new iso > no font bug

Peter

steps to reproduce:

run EsentlFonts.script with tahoma enabeled, but disable two lines:

...

unmount and create new iso > font bug

repeat with this file

...

create new iso > no font bug

You are rather new in this forum. Therefore you cannot know my opinion, well based on a lot of experiences:

Sometimes there is some voodoo in WinBuilder!
BTW: This emoticon was added by the moderators on my personal wish

But joke away: Did you do a 'Fresh' build (like I described above) in both cases?

Peter

You are rather new in this forum. Therefore you cannot know my opinion, well based on a lot of experiences:

Sometimes there is some voodoo in WinBuilder!
BTW: This emoticon was added by the moderators on my personal wish

But joke away: Did you do a 'Fresh' build (like I described above) in both cases?

Peter

yes , i did (there is only 1 build and both changes made after fresh build)
please dont forget to delete the font key for each reg import.

Peter

yes , i did (there is only 1 build and both changes made after fresh build)
please dont forget to delete the font key for each reg import.

Thanks, that seems to be serious, not voodoo.

I'll try to reproduce this situation on my system.

One question:
How can I recognize the 'Font Bug'?

Peter