HoJoPE
#1
Posted 15 September 2008 - 06:49 PM
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
#2
Posted 15 September 2008 - 07:16 PM
it is not hojope's fault (i highly believe)there is a problem (font bug, all dialog fonts are bold) caused by bad font entries
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 nikzzzzcan someone confirm running winbuilder on XP x64 host?
and i still use x64 as host
#3
Posted 15 September 2008 - 08:20 PM
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"....)
#4
Posted 15 September 2008 - 10:14 PM
You are absolutely right!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 .....)
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.
#5
Posted 15 September 2008 - 11:52 PM
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.
I dont have a problem with regshot or shortcut of regshot under livexp.fxscrpt
i have problems with shortcuts like in regshot created via Add_Shortcut,StartMenu
ps: i am using WB075 beta4 (the official beta) too
#6
Posted 16 September 2008 - 12:25 AM
yes, that's quite strange. I wonder what the reason for that behaviour is? Hopefully Peter might have an idea.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.
Regards,
Galapo.
#7
Posted 16 September 2008 - 05:20 AM
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.
#8
Posted 16 September 2008 - 05:40 AM
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.
#9
Posted 16 September 2008 - 05:42 AM
Me too!on my build process explorer (11.21) really does not start.
#10
Posted 16 September 2008 - 06:51 AM
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.
It is really not the best idea to try to hide symptoms, rather thanMe too!
fixing the root of the issue.
Peter
#11
Posted 16 September 2008 - 08:06 AM
The double percentages really seems to be wrong.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"
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.
Similar explanation: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 .....)
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.
I do not undertand competely.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 .....)
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!
That is wrong.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
When writing the WinBuilder registry script lines, HoJoPE replaces the (language independent) labels with the corresponding (language dependent) entries in the [string] section.
Peter
#12
Posted 16 September 2008 - 08:11 AM
hello Peter ,It is really not the best idea to try to hide symptoms, rather than
fixing the root of the issue.
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
#13
Posted 16 September 2008 - 08:14 AM
I think if you read my reply which crossed yours, you know more.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
BTW: Look into my signature about 'Problems'
Peter
#14
Posted 16 September 2008 - 09:34 AM
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
#15
Posted 16 September 2008 - 09:50 AM
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
#16
Posted 16 September 2008 - 11:17 AM
Navigate to Basic > Build > BuildModel and uncheck "Do not refresh shortcuts on ISO boot".have no icons. the icons are restored on first cklick. its no problem for me and maybe a problem with my host os.
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
#17
Posted 16 September 2008 - 11:21 AM
ok. That seems to be a bug.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%
If the [strings] value is not defined, the label's name is used.
I'll check.
Thanks
Peter
#18
Posted 16 September 2008 - 02:24 PM
-
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.
#19
Posted 16 September 2008 - 02:44 PM
hi deraI 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]
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
#20
Posted 16 September 2008 - 02:54 PM
That cannot be true.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"
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
#21
Posted 16 September 2008 - 03:01 PM
There is ONLY ONE difference: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]
In WB the line
"Symbol 8,10,12,14,18,24 (VGA res)"="SYMBOLE.FON"
is missing.
Peter
#22
Posted 16 September 2008 - 04:45 PM
thank you Peterok. That seems to be a bug.
If the [strings] value is not defined, the label's name is used.
I'll check.
Thanks
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
#23
Posted 16 September 2008 - 04:59 PM
You are rather new in this forum. Therefore you cannot know my opinion, well based on a lot of experiences: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
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
#24
Posted 16 September 2008 - 05:08 PM
yes , i did (there is only 1 build and both changes made after fresh build)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
please dont forget to delete the font key for each reg import.
Peter
#25
Posted 16 September 2008 - 05:16 PM
Thanks, that seems to be serious, not voodoo.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.
I'll try to reproduce this situation on my system.
One question:
How can I recognize the 'Font Bug'?
Peter
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users