Jump to content











Photo
- - - - -

FBWF


  • Please log in to reply
20 replies to this topic

#1 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 17 March 2009 - 03:08 PM

When testing fxscrpt's EarlyStarter.Script (BTW: :good: ) 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

#2 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 17 March 2009 - 04:23 PM

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'.
:good:


^_^
Peter

#3 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 17 March 2009 - 04:30 PM

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?

#4 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 17 March 2009 - 04:49 PM

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

#5 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 17 March 2009 - 07:36 PM

@cdob

You are great ^_^
^_^ ^_^ ^_^ :good: :) ^_^ :) :)

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

#6 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 March 2009 - 01:49 PM

Issue solved. :good:

See here.

Peter

#7 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 18 March 2009 - 04:18 PM

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.

#8 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 March 2009 - 05:18 PM

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! :good:

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.

#9 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 18 March 2009 - 09:59 PM

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.

#10 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 19 March 2009 - 10:34 PM

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.

#11 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 20 March 2009 - 01:46 AM

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?
:good:
Peter

Attached Files



#12 Lancelot

Lancelot

    Frequent Member

  • .script developer
  • 5013 posts
  • Location:Turkiye/Izmir
  • Interests:*Mechanical stuff and Physics,
    *LiveXP, BartPE, SherpyaXPE,
    *Basketball and Looong Walking,
    *Buying outwear for my girlf (Reason: Girls are stupid about buying bad stuff to make themselves uglier :))
    *Girls (Lyric: Girl,...., You will be a womann, Soon)
    *Answering questions for "Meaning of life",
    *Helping people,

    Kung with LiveXP, Fu with Peter :)
  •  
    Turkey

Posted 20 March 2009 - 01:54 AM

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.

#13 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 20 March 2009 - 02:03 AM

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

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

^_^
Peter

#14 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 20 March 2009 - 02:18 AM

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.

#15 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 20 March 2009 - 05:53 PM

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

#16 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 20 March 2009 - 07:17 PM

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.

#17 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 20 March 2009 - 07:29 PM

Some Ideas, has to be verified still:

...
To be continued.


cdob, excellent!
Thanks
Peter

#18 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 20 March 2009 - 07:40 PM

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? :good:

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

#19 cdob

cdob

    Gold Member

  • Expert
  • 1440 posts

Posted 21 March 2009 - 11:11 AM

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.

#20 fxscrpt

fxscrpt

    Frequent Member

  • .script developer
  • 328 posts
  •  
    Germany

Posted 21 March 2009 - 01:32 PM

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

:good:


Peter

#21 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 02 April 2009 - 09:57 PM

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.

:good:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users