28 replies to this topic

[MedEvil]

Hi,
did some extensive testing yesterday and found a bunch of quirks, when i use nativeEx with FBWF instead of Ramdisk.

1.) Since FBWF always needs to be the same letter as PEDriveLetter, i would love it, when the RamDiskLetter would really only be used for the RamDisk.

2.) Peter you create ModelRam.exe and extract it to RamDisk. Very good, but why does the same happen with FBWF?
There is no need for extracting anything! 'documents and Settings could just be on the CD.

3.)
Any idea how the content of drive X can end up in 'My Documents'?

4.)
In the above pic you see nativeEX with FBWF, but i extracted ModelRam.exe to CD before burning and deleted the archive.
As you can see the names of some folders have changed. (to capital letters) Since this capture was done right after the start, there must have been a bunch of writes to those folders at boot time. I thought all shortcuts are created now at build time?
The error message comes from clicking 'Erweitert' on the Startmenu configuration dialog.
Still the most puzzeling error to me, as i can navigate to that folder with explorer and cmd without problems.

5.)
The above pictures show 'documents and settings' once on ramdrive B in a running system and once extracted from Modelram.exe. They are not identical.
I would have imagined that the complete 'documents and settings' would be in Modelram.exe. Why this mixed creating?

[smiley]

2.) Peter you create ModelRam.exe and extract it to RamDisk. Very good, but why does the same happen with FBWF?
There is no need for extracting anything! 'documents and Settings could just be on the CD.

It is needed because except for empty folers, it contains also links .

[MedEvil]

It is needed because except for empty folers, it contains also links .

And those links can't be on the CD because?

[pscEx]

@MedEvil, thanks for your tests (alter Nörgler ).

2.) Peter you create ModelRam.exe and extract it to RamDisk. Very good, but why does the same happen with FBWF?

This is because I'm trying to build a system where every module works independent of every module (Of course there are some dependencies).

Therefore the buildModel mechanism expands into a 'writable documents and settings' folder. And it does not matter whether this folder is a RAM drive or a virtual drive built by FBWF.
To make an exception with FBWF would hurt the above rule.
If an FBWFx module is invented, I have to change my source code, same with FBWFy etc. ...

3.)Any idea how the content of drive X can end up in 'My Documents'? wink.gif

Please explain a little bit more. I do not understand your question.

4.)In the above pic you see nativeEX with FBWF, but i extracted ModelRam.exe to CD before burning and deleted the archive.
As you can see the names of some folders have changed. (to capital letters) Since this capture was done right after the start, there must have been a bunch of writes to those folders at boot time. I thought all shortcuts are created now at build time?
The error message comes from clicking 'Erweitert' on the Startmenu configuration dialog.
Still the most puzzeling error to me, as i can navigate to that folder with explorer and cmd without problems.

You disturbed the logic (see my first answer). If the provided logic is not respected, the results are random.

5.) The above pictures show 'documents and settings' once on ramdrive B in a running system and once extracted from Modelram.exe. They are not identical.
I would have imagined that the complete 'documents and settings' would be in Modelram.exe. Why this mixed creating?

The '...\default user\...\maintenance entry is coming from the source CD and added by the created hives.

Maybe that can be omitted and added by buildModel if necessary.

Peter

[MedEvil]

@MedEvil, thanks for your tests (alter Nörgler ).

Danke für die Blumen!

This is because I'm trying to build a system where every module works independent of every module (Of course there are some dependencies).

Therefore the buildModel mechanism expands into a 'writable documents and settings' folder. And it does not matter whether this folder is a RAM drive or a virtual drive built by FBWF.
To make an exception with FBWF would hurt the above rule.
If an FBWFx module is invented, I have to change my source code, same with FBWFy etc. ...

I don't see your point, if someone invents a RAMdrivex module, you will have to adapt as well.

Please explain a little bit more. I do not understand your question.

This refers to 3.) Please look at the pic. In Explorer Treeview, there is 'Meine Dateien' selected. Now look at the right side at the content of that folder! The complete contents of drive X is in 'Meine Dateien'!

You disturbed the logic (see my first answer). If the provided logic is not respected, the results are random.

The error message happens even when i keep your logic intact.
But my problem is more with the fact that there are lots of writes to 'Dokumente und Einstellungen' at startup, when there should be none!

The '...\default user\...\maintenance entry is coming from the source CD and added by the created hives.

There are lots of folders created in default user, not to mention that All Users is created completely new.

[pscEx]

I don't see your point, if someone invents a RAMdrivex module, you will have to adapt as well.

Here you are wrong. The RAMDrivex module has to accept the rules of the RAMDrive module: 'Documents and Settings' is expanded into a writable drive with letter '?', usually B: or in case of FBWF, propably X:

This refers to 3.) Please look at the pic. In Explorer Treeview, there is 'Meine Dateien' selected. Now look at the right side at the content of that folder! The complete contents of drive X is in 'Meine Dateien'!

Sorry, I did not recognice before. I currently have no idea how it happens. I'll check.

The error message happens even when i keep your logic intact.
But my problem is more with the fact that there are lots of writes to 'Dokumente und Einstellungen' at startup, when there should be none!

$ModelBuild.exe self expands into 'documents and settings' and that are a lot of writes.
If there are additional writes caused by the 'nativeEx core', please post them here.

There are lots of folders created in default user, not to mention that All Users is created completely new.

Until now I did not worry about Bill G's creation of folders, as long they did not bring our system to crash.
If somebody wants to prohibit the creation of unnecessary folders:
I would not worry to implement new software.ctl, setup.ctl, setupreg.hiv.ctl or txtsetup.ctl files for the hivesfactory (If they pass my intl checks).

Peter

[MedEvil]

$ModelBuild.exe self expands into 'documents and settings' and that are a lot of writes.
If there are additional writes caused by the 'nativeEx core', please post them here.

I will do a more thorough check and most back.

Until now I did not worry about Bill G's creation of folders, as long they did not bring our system to crash.
If somebody wants to prohibit the creation of unnecessary folders:
I would not worry to implement new software.ctl, setup.ctl, setupreg.hiv.ctl or txtsetup.ctl files for the hivesfactory (If they pass my intl checks).

Sorry, this is not really a problem, just something my orderly german nature sees as a problem.
There should be only 1 process which creates documents and settings. And as we choose this process to be ModelRam.exe. there should be no other processes alowed or needed to fiddle with those folders.

The reason i bring this up is also, that without the extra fiddeling, FBWF might work without problems, as long as we don't create any new folders with non english characters.

[pscEx]

IThere should be only 1 process which creates documents and settings. And as we choose this process to be ModelRam.exe. there should be no other processes alowed or needed to fiddle with those folders.

The reason i bring this up is also, that without the extra fiddeling, FBWF might work without problems, as long as we don't create any new folders with non english characters

I'll try to remember this on future developments.
But that's difficult ....

Peter

[MedEvil]

Ok, bad news for Mr. Paperclip.
FBWF has none of the mentioned problems on WB 052 Standard project!
Though it sports far more than just the default scripts, it includes none, that i do not also have in my nativeEx one.

Any idea how to find the problem?

I made two directory listings of i386 one of nativEX with FBWF and one of Standard project with FBWF.
Hope you can make use of it, till i have time to join.
 nativeEX.txt   24.76KB   445 downloads  Standard.txt   24.6KB   441 downloads

[MedEvil]

I build a nativeEx project with FBWF and included the whole WinSxS folder from the Standart project.
Result:
No problem anymore with foldernames comtaining non english characters.
We still have the problem that the contents of the folders gets not updated without pressing F5.
So i guess we're missing some Registry entries too.

Anyone any idea?



edit:
Forget the above! Things a far weirder than i thought.
The only real difference i could find between the old Standard project with FBWF and nativeEx with FBWF is that there seems to be an update problem in the explorer in nativeEX that wasn't there in the old Standart project.

Aside from this: the both behave the same!
In the most peculiar fashion, but equal!

In the german language only the letters ü,ö,ä make problems, but not €,ß,Ü,Ö,Ä!!!

If someone can explain this to me, please do! I don't have any clue as to how this can happen!

[MedEvil]

Found some more strangeness.
Did you know that Windows can distinguish between folders with capital letters and folders without!? I thought only ???ix machines can do that!


Here the same in the explorer. The Startmenü in all capital letters comes from Medelram.exe no idea who created the other one.


Thought maybe Windows itself did it but:

Here i created the before missing Autostart folder in STARTMENÜ and put 'documents and settings' even directly on the CD to make sure that whenever Windows checks it will find the folders. (just in case there would be some timing problem)
As you can see, Startmenü\Autostart is still created. This can only be done from a software that can distinguish between capital and normal letters else it should see the folder as already present.

Can Autoit distinguish between the two?

[Holger]

Normally for "Autoit" these both folders are the same (didn't read all this thread) but if you compare two strings case sensitive with "==".

[pscEx]

This refers to 3.) Please look at the pic. In Explorer Treeview, there is 'Meine Dateien' selected. Now look at the right side at the content of that folder! The complete contents of drive X is in 'Meine Dateien'!

Here the reason:
Explorer.script has a line

RegWrite,"HKLM",0x2,"WB-Default\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders","Personal","%temp%"

"Personal" in your system is 'Meine Dateien'
"%temp%" is anywhere else defined as %RamDrive% and:
%Ramdrive% in case of FBWF is X:
Once again a reason not to try to use FBWF running 100% satisfying.
Besides legality questions, FBWF is really neither XP nor W2003 native!

Peter

Peter

[phox]

Once again a reason not to try to use FBWF running 100% satisfying.
Besides legality questions, FBWF is really neither XP nor W2003 native!

Peter

What could replace FBWF?

[pscEx]

What could replace FBWF?

If somebody wants to use the Vista-imported functionality, than he/she has to live with the fact that there are some uncomfortabilites.

Peter

[MedEvil]

If somebody wants to use the Vista-imported functionality, than he/she has to live with the fact that there are some uncomfortabilites.

Peter

And why is this quirk new to nativeEX? The Standard project did not have this problem.
So it does not seem like it is the fault of FBWF.

Besides FBWF is not a Vista only component, XPEmbedded comes also with it. So saying that it was never ment to work with XP and therefore there have errors to occur, is wrong!

PS What has FBWF done to you, that you fight it so hard, Peter?

[pscEx]

And why is this quirk new to nativeEX? The Standard project did not have this problem.
So it does not seem like it is the fault of FBWF.

Besides FBWF is not a Vista only component, XPEmbedded comes also with it. So saying that it was never ment to work with XP and therefore there have errors to occur, is wrong!

PS What has FBWF done to you, that you fight it so hard, Peter?

What is wrong with my opinion

Besides legality questions, FBWF is really neither XP nor W2003 native!

Peter

[MedEvil]

What is wrong with my opinion
Peter

Nothing, it's just that FBWF is native XP, when it is included in XPEmbedded bulder pack, wouldn't you say so?

Here the reason:
Explorer.script has a line

RegWrite,"HKLM",0x2,"WB-Default\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders","Personal","%temp%"

"Personal" in your system is 'Meine Dateien'
"%temp%" is anywhere else defined as %RamDrive% and:
%Ramdrive% in case of FBWF is X:

Sorry, somehow overlook this post before.
This is, as you can clearly see, not a fault in FBWF.script but in Explorer.script as Personal should point to 'documents and settings\default User\my documents' and not to temp!
Should i correct the script or do you wanna do it yourself?



PS: Any theory on the character thing? Still have no hypothesis why Ö works and ö does not.

[pscEx]

Nothing, it's just that FBWF is native XP, when it is included in XPEmbedded bulder pack, wouldn't you say so?

If it would be, I could find it on my CD

Sorry, somehow overlook this post before.
This is, as you can clearly see, not a fault in FBWF.script but in Explorer.script as Personal should point to 'documents and settings\default User\my documents' and not to temp!
Should i correct the script or do you wanna do it yourself?

I usually feel not free to debug scripts of somebody else. I only give hints and the author can change.
For me there is only one reason to change scripts made by a different author: To adapt to new functionality in the project.

PS: Any theory on the character thing? Still have no hypothesis why Ö works and ö does not. frusty.gif

I really did not think about this until now. But when you imagine that the currently used FBWF is English, why do you wonder?
In my opinion here is the old 'unicode' issue, this time with real ASCII (not Ansi!) characters used in several functions.
If that is reality, no chance from outside!

Peter

[MedEvil]

If it would be, I could find it on my CD

Naseweis!

I usually feel not free to debug scripts of somebody else. I only give hints and the author can change.
For me there is only one reason to change scripts made by a different author: To adapt to new functionality in the project.

Well, i just thought because you were the one who adopted the script that you were also the one who introduced this code fragment.
But after some comparing, i find the same line in script v15 in Standard project too. But there it does not lead to the same conequences.

I really did not think about this until now. But when you imagine that the currently used FBWF is English, why do you wonder?
In my opinion here is the old 'unicode' issue, this time with real ASCII (not Ansi!) characters used in several functions.
If that is reality, no chance from outside!

I feared as much, but the 'english only' or '7bit ascii' explainations are out of the window, as they fail to explain why €,ß,Ü.Ö.Ä work, while ü,ö,ä don't.
The last character working in german is 223, while 228 is the first not to work.

[pscEx]

Naseweis!

To explain for non-German-speaking people:
That means something like a small child that everything knows better.
This is a cookie sometimes exchanged between 'me Devil' sorry MedEvil and me.
It is just thought as a joke, no attack, no hurting.
Now to the more serious themes:

But after some comparing, i find the same line in script v15 in Standard project too. But there it does not lead to the same conequences. confused1.gif

This look serious. I'll have a look into it.

I feared as much, but the 'english only' or '7bit ascii' explainations are out of the window, as they fail to explain why €,ß,Ü.Ö.Ä work, while ü,ö,ä don't.
The last character working in german is 223, while 228 is the first not to work. confused1.gif

This also seems to be serious. But I think:
If somebody 'steels' an English module, he cannot assume that this module will work correctly in German and Chinese and ...
Maybe we can adjust something, but I'm in doubt.

Peter

[MedEvil]

This is a cookie sometimes exchanged between 'me Devil' sorry MedEvil and me.

medieval me Devil is medium evil!

This look serious. I'll have a look into it.

I guess the line is eigther ineffective doe to some reason in stabdart p. or is later overwritten, for example by the localize scripts.

If somebody 'steels' an English module, he cannot assume that this module will work correctly in German and Chinese and ...

With chinese i agree, as chinese is unicode. And if ÖÜÄ would make problems too, i would also agree with the english only or the 7bitASCII theory. But that ÖÜÄ work means, that at least 8bit ASCII/ANSI is used.
But why we get then problems with öüä? No clue. It's absolutely unlogical!

[Brito]

This is just a wild thought, but can't we assume that the chinese FBWF is compatible with all our language types since it fully supports unicode?

[MedEvil]

This is just a wild thought, but can't we assume that the chinese FBWF is compatible with all our language types since it fully supports unicode?

Nice idea!
But i somehow doubt that this is really the fault of FBWF.
Never heared of a country specific HDD driver!

Besides i did just some test in the command prompt. Result: creating -, changing into - and deleting folders with the letters üöä work. That is far better than the explorer can do.
Only renaming with the move command wouldn't work. (can't find folder)

One of the more puzzeling things about this is, how i can have a folder called Startmenu and a folder called STARTMENÜ in the same folder. I can't do that on my normal XP!
Seems we have improved the XP file system to unix quality!

further tests:
I can rename and delete a folder called ü, as long as i have a folder called Ü in the same folder.
Once i remove Ü, ü can't be deleted or renamed anymore.
Not that you think the system would maybe make a mistake and confuse the two. It doesn't!
As the content of the two folders clearly shows.
ü-Ü, ö-Ö, ä-Ä are the only letters nativeEX does not identify as being the same!

[pscEx]

With chinese i agree, as chinese is unicode. And if ÖÜÄ would make problems too, i would also agree with the english only or the 7bitASCII theory. But that ÖÜÄ work means, that at least 8bit ASCII/ANSI is used.
But why we get then problems with öüä? No clue. It's absolutely unlogical!

Ask Bill G.

Peter