20 replies to this topic

[pscEx]

When testing fxscrpt's EarlyStarter.Script (BTW: ) I had the issue that with use of FBWF shortcuts are displayed on the desktop only, not in the startmenu.
Opening the startmenu with explorer the shortcuts are there and work. On dblclick they start the according app.

W/o EarlyStarter same result. That means that EarlyStarter is not responsible for that behaviour.

I tested with WinBuilder 074: Same result.

So it seems to be a not yet known 'feature' of FBWF, at least of the CreateISO script which brings FBWF to the PE.

Any ideas?

Peter

[fxscrpt]

When testing fxprct's EarlyStarter.Script (BTW: ) I had the issue that with use of FBWF shortcuts are displayed on the desktop only, not in the startmenu.
Opening the startmenu with explorer the shortcuts are there and work. On dblclick they start the according app.

W/o EarlyStarter same result. That means that EarlyStarter is not responsible for that behaviour.

I tested with WinBuilder 074: Same result.

So it seems to be a not yet known 'feature' of FBWF, at least of the CreateISO script which brings FBWF to the PE.

Any ideas?

Peter

Hi Peter,

I got the issue only if build from XP SP2.
(not reported , because i'm busy to fix other glitches)
and
if you type the traget folder in explorer's adress bar,
iexplorer will show you this error: 'the folder is not accessible'.




Peter

[cdob]

Opening the startmenu with explorer the shortcuts are there and work. On dblclick they start the according app.

Any ideas?

FBWF dosn't handle Umlaute. At last did fail at XP SP2, no idea about XP SP3.
Do you use Startmenü at CD?

[pscEx]

FBWF dosn't handle Umlaute. At last did fail at XP SP2, no idea about XP SP3.
Do you use Startmenü at CD?

Yes, I used German source CD which has 'Startmenü' by standard.

Thanks, cdob, that is a reasonable explaination!

Peter

[pscEx]

@cdob

You are great


I wrote this small script (which also should be expandable for different languages) and some of my German FBWF problems already disappeared.

[codebox][main] Title=FBWF native Description=Removes some non ANSI characters from shell folder names Selected=True Author=Peter Schlang Level=1 Version=1 Date=2009-MAR-17 Credits=cdob for his hint that FBWF cannot handle umlauts in folder names Download_Level=1 [process] If,EXISTSECTION,%ScriptFile%,Info-%SourceLocale%,Run,%ScriptFile%,Info-%SourceLocale% If,EXISTSECTION,%ScriptFile%,Reg-%SourceLocale%,Run,%ScriptFile%,Reg-%SourceLocale% [Info-00000407] TXTReplace,%ProjectInfo%,Startmenü,Startmenue TXTReplace,%ProjectInfo%,Zubehör,Zubehoer [Reg-00000407] Run,%ScriptFile%,Startmenu-Change,Startmenü,Startmenue [Startmenu-Change] RegHiveLoad,WB-Default,%target_sys%\config\default Set,%Key%,"WB-Default\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" Set,%Type%,0x1 Run,%ScriptFile%,Do-Default,%Key%,Programs,%Type%,#1,#2 Run,%ScriptFile%,Do-Default,%Key%,"Start Menu",%Type%,#1,#2 Run,%ScriptFile%,Do-Default,%Key%,Startup,%Type%,#1,#2 Set,%Key%,"WB-Default\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" Set,%Type%,0x2 Run,%ScriptFile%,Do-Default,%Key%,Programs,%Type%,#1,#2 Run,%ScriptFile%,Do-Default,%Key%,"Start Menu",%Type%,#1,#2 Run,%ScriptFile%,Do-Default,%Key%,Startup,%Type%,#1,#2 RegHiveUnLoad,WB-Default [Do-Default] RegRead,HKLM,#1,#2,%var% StrFormat,REPLACE,%var%,#4,#5,%var% StrFormat,REPLACE,%var%,%USERPROFILE%,##$pUSERPROFILE##$p,%var%
RegWrite,HKLM,#3,#1,#2,%var%

[/codebox]

The autostart is already working with that. I'm sure that I'll have a complete solution tomorrow.

Peter

[pscEx]

Issue solved.

See here.

Peter

[cdob]

Renaming is a nice idea to get a nice work arround.
What about application shortcuts? Do they use 8-bit chars too?
What about asian languages?

A solution would be nice too.

More background: it's about file system and fbwf.

Non english PE use long file names, example WinSxS directory.

Bart did choose ISO 9660:1999 to store long names. That's a draft still.
http://www.y-adagio....romr/tocont.htm

ISO 9660:1988 is the current one.
http://www.iso.org/i...o_catalogue.htm

Ecma 119 publication is also approved as ISO 9660
http://www.ecma-inte...ds/Ecma-119.htm

ISO 9660:1988 Appendix A allows some chars only, all are 7 bit.
That's a sub set of ASCII chars.

FBWF seems to support 7 bit chars only, let's assume ASCII chars.

ISO9660:1999 draft allows more chars, but there is no hint about used charset.

Within a Directory Hierarchy that is identified in an Enhanced Volume Descriptor, a File Identifier shall not be specified as certain character sequences. These sequences shall be subject to agreement between the originator and recipient of the volume.

MS dosn't support ISO9660:1999 draft by design, usage works by chance.
Cdfs.sys calls a function RtlOemToUnicode. File names are read using OEMCP.
Startmenü is possible within cdfs.sys and OEMCP 850.

Mkisofs does support ISO9660:1999 draft.
8 bit chars are possible, I'm very confident about this.

However Fbwf behaviour is unknown.

There are other file systems too.
How does fbwf handle another file system?


Some ideas, not tested fully:

Joliet does use unicode. There is no conversion requiered. Fbwf may work or fail.
Joliet support long names, but not very long names,
Add Joliet file system, but ignore very long WinSxS names.

mkisofs -iso-level 4 -joliet-long -hide-joliet *WinSxS*

Intermediate report:
I did just create a directory "Startmenü" at booted fbwf CD.
The directory is acessable. Copy files is possible. A file can be opened.

UDF does use unicode. There is no conversion requiered. Fbwf may work or fail.

mkisofs -iso-level 4 -udf

Setupldr.bin dosn't read UDF. Try load driver udfs.sys at txtsetup.sif.

[pscEx]

What about application shortcuts? Do they use 8-bit chars too?
What about asian languages?

I tried with notepad.exe renamed to düdeldö.exe
ISO w/o FBWF: ok
ISO with FBWF: shortcut looks correct, but no reaction on dblclick.

This also answers the questions about the switches when building the ISO: They seem to be correct. The ISO w/o FBWF has no issues.
I think, that therefore the second part of your reply cannot help here.

BTW: My knowledge of Enlish language is rather small. Maybe that I did not see something important here, or did not understand correctly.

@cdob: If you have this feeling, do not worry to cry and tell me my mistake!

part #2 of the quote:
Currently w/o FBWF 8 bit names seem to be supported, under FBWF only 7 bits.
Asian languages (unicode) are a general, right now unsolved issue of WinBuilder (see here)

Peter

BTW: Since more than 30 years I am an APPLICATION programmer. My low level knowledge about booting, file systems, etc. is restricted on the old DOS programming level with hooking interrupts etc.

[cdob]

Well, file system was one idea.

This FBWF 'feature' was described previously:
http://www.911cd.net...&...st&p=119507
http://www.pebuilder...opic,15529.html
It's possible to create a directory "Startmenü", but renaming fails: read error.

Maybe fbwf.sys version is importand. I'm using 6.1.7000.0 from WAIK win7 beta.
http://www.microsoft...6C-E039E3D0DB5D

New games result to:
addional file system Joliet dosn't matter.

Plain ISO9660:1999, no additional file system used.
A link does work, a application is launched.
Renaming fails still.
Fbwf.sys dosn't support 8 bit chars still. 8 bit chars does work and fails.

[cdob]

Given: settings "Target\nativeEx_barebone\Dokumente und Einstellungen" expanded at hard disk.

ISO image builded next.
Mingw32 mkisofs does select OEM codepage from running system.
Therefore ISO9660:1999 Image uses OEM Codepage 850: there is Startmenü available.

FBWF PE booted: links does work.

[fxscrpt]

Hi,

Modelram.exe fails to expand some files to %SystemDrive% in PE.
(for all FBWF versions). No special characters like 'ü' for file names or path names used for failed files !.
The funny think is, yesterday it worked for me.

However, how to skip failed files and continue extracting?

Peter

Attached Files

•  failed.txt   2.59KB   508 downloads
•  working.txt   13.35KB   556 downloads

[Lancelot]

fxscrpt

only change i know is new version of createiso uses mkisof as default. (older one was using cdimage default)

ps: looking forward for new regfactory in 2 or more days and hoping to find time to make the contribution i have in mind.

[fxscrpt]

ps: looking forward for new regfactory in 2 or more days and hoping to find time to make the contribution i have in mind.

will do asap, currently fixing some RegFactory issues.
(if profiles on X:).


Peter

[Galapo]

only change i know is new version of createiso uses mkisof as default. (older one was using cdimage default)

Yes, that's right and it's probably introduced this result. Hopefully cdob will be able to point to a different version of mkisofs or provide details of how to get the current one working.

Regards,
Galapo.

[pscEx]

I have some new results which let appear the FBWF issue in a different point of view.

#1: An FBWF powered nativeEx based PE really can work under all (tested) circumstances only if

• FBWF version is 0965
• Source CD is XP SP2 or SP3

#2: There are case sensitivities:
(BTW: ISO is made with forced uppercase path names)

• PE of nativeEx_barebone from German XP SP3 with activated FBWF_native works perfect
• PE of nativeEx_barebone from English XP SP3 with inactivated FBWF_native (not necessary because of only-ASCII-names) shows a link for OB1 w/o icon.
  dblclick on the link does not bring any reaction
  Manually changing the link from
  

  "%SystemDrive%\Program Files\OffByOne\OB1.exe"

  to
  

  "%SystemDrive%\PROGRAM FILES\OFFBYONE\OB1.exe"

  lets the icon appear and dblclick starts the app!

What to do?
(BTW: The ISO forced uppercase path names cannot be responsible: W/o FBWF everything runs smoothly.)

Redesign nativeEx and LiveXP, rewrite a lot of scripts?

For the case that this will be necessary, I added two commands to WinBuilder:
StrFormat,UCASE,string,%var%
StrFormat,LCASE,string,%var%

Maybe it helps to use them in the API only. I do not know yet, and wait for some suggestions.

Peter

[cdob]

Some Ideas, has to be verified still:

There is a major difference at FBWF drive:

Reading from CD (image) itself:
cdfs.sys (udfs.sys) does read files.
Behaviour is known, e.g. OCEMCP used at ISO9660:1999.
There are predictable results.

FBWF.sys get data from cdfs.sys (udfs.sys).
Files are acessable.

Writing files to FBWF drive is another story.
FBWF may fails at non ASCII files.

Modelram.exe does expand files to %SystemDrive% in PE.
This is nice at a FAT/NTFS drive, but dangerous at a FBWF drive.



One approach:

Given FBWF drive and profile on %SystemDrive%:
Don't expand Modelram.exe to %SystemDrive% in PE.
Add profile files to CD image. Choose a appropiate file system.

Appropiate file system ISO9660:1999:
Read from PE HKLM\SYSTEM\ControlSet001\Control\Nls\CodePage\OEMCP
Map chars to OEMCP: e.g. -output-charset cp850
Global solution: supporting appropiate OEMCP will give some fun.

"Dokumente und Einstellungen" stored as Joliet, but not as ISO9660.
-iso-level 4 -joliet-long -hide-joliet *WinSxS* -hide "Dokumente und Einstellungen"
Booted PE does ignore "Dokumente und Einstellungen" stored as Joliet, links does not work.

Add UDF file system: PE dosn't boot at all. Ntdetect failed.


A step back, current default projects:
XP SP3, fbwf 6.1.7000.0

LiveXP:
Modelram.exe expand to %SystemDrive% in PE: profile does work


nativeEx_barebone:
Modelram.exe expand to %SystemDrive% in PE: profile does not work

CreateISO.script copied from LiveXP to nativeEx_barebone:
Modelram.exe expand to %SystemDrive% in PE: profile does work
First glance, first idea: fbwf Start is different: at boot and manual

To be continued.

[fxscrpt]

Some Ideas, has to be verified still:

...
To be continued.

cdob, excellent!
Thanks
Peter

[pscEx]

cdob, thanks for your post.

You brought a lot of aspects, and I'm going to try / test one after the other (tomorrow, now it is late enough ..)

But on the first view, I see something which is very suspicious:

LiveXP:
Modelram.exe expand to %SystemDrive% in PE: profile does work

nativeEx_barebone:
Modelram.exe expand to %SystemDrive% in PE: profile does not work

Voodoo?

Due to build, modelram.exe of both is logically identical (maybe different content)

And for me, expanding modelram.exe, under nativeEx_barebone, never brought any issue.

How can we get the background of the ?

Peter

[cdob]

NativeEx_barebone

EarlyStarter Version=7:
FBWF and ModelRam deselected: Startmenü does work
FBWF deselected, ModelRam enabled: Startmenü fails
FBWF enabled, ModelRam deselected: Startmenü does work

fxscrpt released a updated in the meantime.
http://www.boot-land...?...ost&p=62917

Added:
EarlyStarter Version=8:
FBWF enabled, ModelRam enabled: Startmenü does work
XP SP3 and FBWF version 6.1.7000.0 used.

[fxscrpt]

NativeEx_barebone

EarlyStarter Version=7:
FBWF and ModelRam deselected: Startmenü does work
FBWF deselected, ModelRam enabled: Startmenü fails
FBWF enabled, ModelRam deselected: Startmenü does work

fxscrpt released a updated in the meantime.
http://www.boot-land...?...ost&p=62917

Added:
EarlyStarter Version=8:
FBWF enabled, ModelRam enabled: Startmenü does work
XP SP3 and FBWF version 6.1.7000.0 used.

Thanks cdob.

In version 8 only some logical changes. Executable not changed.

FBWF and ModelRam deselected: Startmenü does work

thats OK, because FBWF an Modelram processed in RunOnceEx.

FBWF deselected, ModelRam enabled: Startmenü fails

thats OK, because FBWF started in RunOnceEx after Modelram processed by EarlyStarter (Modelram silently fails).

BTW: By removing all 'hiderun /w' (maybe replaced by 'cmd /k')
in HKLM\Software\EarlyStarter you can 'see' executed commands,
because the service is interactive.

FBWF enabled, ModelRam deselected: Startmenü does work

thats OK, because FBWF started by EarlyStarter first an then Modelram processed by RunOnceEx.

FBWF enabled, ModelRam enabled: Startmenü does work

Peter

[MedEvil]

Unless someone finds some problem with the codepage used to encode the file names and the one used to decode the file names. (the one used in PE)
I stick with my findings that the problem is caused by the different encodings used for cdfs (CD) and fat/ntfs (overlay file system).
I wrote a thread about that, btw.