8 replies to this topic

[pscEx]

When trying to solve the Win7PE issues when WinBuilder is installed on a 64 bit host OS, I found this fact, which in the first time generated the idea to buy a package of dynamite, put it to my PC and

What happenned:

The mkisofs script did not work correctly (My test PC has Win7 RC1 German installed)

I tried to execute mkisofs by command line in order to see error messages.

The command line has been:

mkisofs -iso-level 4 -force-uppercase -volid "nativeEx" -b bootsect.bin -no-emul-boot -boot-load-size 4 -hide bootsect.bin -hide boot.catalog -duplicates-once -o "C:\Users\Peter\Desktop\WinBuilder\ISO\nativeEx_barebone.iso" "C:\Users\Peter\Desktop\WinBuilder\Target\nativeEx_barebone"

Here "C:\Users\Peter\Desktop\WinBuilder" is %BaseDir%, queried by WinBuilder as startup directory.

I got the error message:

mkisofs: No such file or directory. Unable to open disc image file 'C:\Users\Peter\Desktop\WinBuilder\ISO\nativeEx_barebone.iso'.

When I looked into my PC by explorer, there really is no "...\Users\..." directory. There is a "...\Benutzer\..." directory.

"Benutzer" is the German translation of "user"

Maybe some users judge me as crazy, but under these circumstances I do not want to fix WinBulder work under special 64 bit non-English OS.
I think it is not inside WinBuilder's (or it's scripts) responsibility to develop work arounds for Billy the Door's actual (failing) routines which can be changed tomorrow in the next SP.

If it works, ok ...
If it does not work, ask Billy the Door ...

So: In the next time, when there is a bug report, or a support request about some issues on a 64 bit host:

"Your decision to use 64 bit ..."

Peter

[pscEx]

Maybe, if there come some reasonable suggestions ...

Peter

[was_jaclaz]

Maybe, if there come some reasonable suggestions ...

Peter

Would it be reasonable having C:\WB\ as %BaseDir% ?

Would it solve the problem?



jaclaz

[pscEx]

Would it be reasonable having C:\WB\ as %BaseDir% ?

Would it solve the problem?



jaclaz

In this case it would help.

But with respect on and extending your blue 'Freedom band':

Every user can decide where he wants to have his %BaseDir% ...

Peter

BTW: I intentionally use 'problematic' paths in order to detect irregularities during develop

[was_jaclaz]

In this case it would help.

Then, it is also reasonable.

But with respect on and extending your blue 'Freedom band':

Every user can decide where he wants to have his %BaseDir% ..

Well, NO. The point is completely different.
One thing is related to our common friend Nuno, and another one is related to the good MS guys.
The first is a self-declared lover of freedom, the latter are doubtedly so.

I personally find not my pursuit of happyness being particularly prevented or delayed by this specific nth behaviour of the MS guys.

More than that, pragmatically, I find very, very improbable that people making so many absurd and unneededly overcomplex things for years without EVER listening to their users would now do something simple.

Heck, they were the guys that not only used two different loaders for NT based systems, SETUPLDR.BIN and NTLDR, each one with their own "ini" file, WINNT.SIF and BOOT.INI with different syntaxes/settings, they also hardcoded paths like \I386 and \minint in the loaders, and finally made the loaders (in 2K3) have a checksum mechanism to prevent changes.
When they finally unified the loaders, they changed from plain text to a Registry Hive and gave a crappy parttially undocumented editor for it.
Can you call that reasonable?

As always, we can make a deal.

If you can explain to me (as a programmer) what would have been the problem in making from the very start (NT 3.x) a plain .ini file containing all options and needed paths and a single bootloader, I will support your new campaign for "User" as opposed to "Benutzer", as well as you can tell me any reason why the data in a BCD cannot be saved and read from a plain .ini file.

BTW: I intentionally use 'problematic' paths in order to detect irregularities during develop

Sure, I know.
To put it plainly, you create a problem that can be avoided by simply using a "short path" in order to be able to ask what would be a reasonable solution (and taking an occasion to bash the MS guys)?

If the point was the second, crying aloud how still unfriendly are the things the MS guys do in their OS's, and how they find every possible way, instead of simplifying and correcting their past and reknown mistakes, to make things yet more unfriendly and insist on using unneeded overlays of compllexity, you have my full support.



jaclaz

[pscEx]

If you can explain to me (as a programmer) what would have been the problem in making from the very start (NT 3.x) a plain .ini file containing all options and needed paths and a single bootloader, I will support your new campaign for "User" as opposed to "Benutzer", as well as you can tell me any reason why the data in a BCD cannot be saved and read from a plain .ini file.

For that you should not ask me, but Billy the Door!

Heck, they were the guys that not only used two different loaders for NT based systems, SETUPLDR.BIN and NTLDR, each one with their own "ini" file, WINNT.SIF and BOOT.INI with different syntaxes/settings, they also hardcoded paths like \I386 and \minint in the loaders, and finally made the loaders (in 2K3) have a checksum mechanism to prevent changes.
When they finally unified the loaders, they changed from plain text to a Registry Hive and gave a crappy parttially undocumented editor for it.
Can you call that reasonable?

My similar feelings caused me to create this topic!

If the point was the second, crying aloud how still unfriendly are the things the MS guys do in their OS's, and how they find every possible way, instead of simplifying and correcting their past and reknown mistakes, to make things yet more unfriendly and insist on using unneeded overlays of compllexity, you have my full support.

You got it!

Thanks for your "Full support"

But what can we do? Compare our possibilities with that ones of Billy the Door!
As a result, I currently can only say (like in previous post)

So: In the next time, when there is a bug report, or a support request about some issues on a 64 bit host:

"Your decision to use 64 bit ..."

Peter

[yahoouk]

Strange
Running under 32bit Win7, when reaching File.script, Windows suddenly stopped and appeared BLUE SCREEN and restart.
WB 77beta2.
Machine source 32bit Win7 RC
WinPE7 Source 32bit.
When running under same machine with xp3pro, it's going well.
No problem at all.
I've got that issue for 5 days.
Now coping with XP3pro.

B Regards,

yahooUK

[pscEx]

Strange
Running under 32bit Win7, when reaching File.script, Windows suddenly stopped and appeared BLUE SCREEN and restart.
WB 77beta2.
Machine source 32bit Win7 RC
WinPE7 Source 32bit.
When running under same machine with xp3pro, it's going well.
No problem at all.
I've got that issue for 5 days.
Now coping with XP3pro.

B Regards,

yahooUK

Please inactivate the restart, that you can read the BSOD information.

I assume that it is not primarily a WinBuilder issue.

Remember, that Win7 is still in the beta phase, and RC1 is not yet the final(?) version.

Peter

[yahoouk]

Please inactivate the restart, that you can read the BSOD information.

I assume that it is not primarily a WinBuilder issue.

Remember, that Win7 is still in the beta phase, and RC1 is not yet the final(?) version.

Peter

Thanks guru, I'll send BSOD Info next time.



yahooUK