5 replies to this topic

[pscEx]

As known, I'm a registered 'Vista Enemy', and following that my only knowledge about Vista is it's existence.
That 'automatically' brings a very low knowledge level for Win7.
However, I like the project an try to help (due to WinBuilder items) as most as i can.

I (partly w/o understanding completelly) followed the 'ShortCut' issue in the Win7PE with Winbuilder 74 & 76 topic.

Here just an idea. If the experienced users judge that as nonsence, please tell me, and I'll be silent. (And that would not affect me any way)

I remember the stone age of OpenBuilder / WinBuilder version around 52 "Standard project".
There have been similar issues: The booting PE did not have the knowledge of the generating WinBuilder project.

Therefore 'simple' Shortcuts have been no problem, but 'more special' ShortCuts needed special treatement (e.g. language dependent folder names wich were NOT in the environment), which was added to the shortcut building app in the PE ... etc. ...

That was the reason I created the nativeEx idea:
Everything about Language dependent names, shortcut targets, etc. is known (or can brought to knowledge) to WinBuilder during build.
Shortcuts should be generated during build and be copied to the target.

It has been a hard way, but for nativeEx based projects it works very well.

Copyflow (for nativeEx):

• The app script makes a call to %BuildModelScript% to generate the shortcut
• %BuildModelScript% generates a 'Shortcut Template' ???.shc containing all necessary information
  (%BuildModelScript% knows 'everything' e.g. language dependent folder names)
• %BuildModelScript% calls %ActiveShell% (passing the template) to generate the shortcut and write into target.
  In this way different PE-main-shell scripts can create their individual shortcuts.
  The generated shortcut of Explorer.Script is very different from the shortcut of e.g. a43.script

Peter

Sample of ???.shc:

[Created]

   Program=shortcutParse

   Version=1.1.2

   Copyright=(C) 2007 Peter Schlang

   Date=2009-Jun-22 205640015

   [Shortcut]

   targetDir=V:\WB\wb debug\Workbench\nativeEx_barebone\UserData

   modelDir=V:\WB\wb debug\Workbench\nativeEx_barebone\UserData

   shortCutName=BGInfo

   shortCutType=DE

   shortCutLocation=

   shortCutExe=%SystemDrive%\Programme\BGInfo\Bginfo.exe

   shortCutToolTip=

   shortCutParameters=

   shortCutShow=

   shortCutDir=%SystemDrive%\Programme\BGInfo\

   shortCutHotKey=

   shortCutIconFile=

   shortCutIcon=0

[JonF]

The base problem in VistaPE and Win7PE is that the target drive is unknown until boot time.

Let's just look at VistaPE. After a build, the target folder contains VistaPE.wim, a folder named "Programs" which contains all the program folders which are not "Run from RAM", and some other stuff which doesn't matter.

When you burn this to a CD and boot from it, VistaPE.wim is loaded into RAM and the system really boots from that. As part of the boot process drive letters get assigned. The CD drive gets that first available drive letter after all internal drives get letters. So the CD drive is probably drive D, but could easily be something else (on this system, when I boot from CD the CD is drive N). lety's call it drive "?". for this discussion

So after booting VistaPE.wim is mounted as drive X. On drive X we see X:\Windows containing the system, and X:\ProgramFiles containing the programs that were "Run from RAM". On some other drive, maybe drive D but maybe not, we see ?:\VistaPE.wim, ?:\Programs\..., and the other stuff that doesn't matter.

The shortcuts are specified in the [shortcut] section of ?:\VistaPE.cfg, and references to "?:\Programs.." are listed inthat file as "%CDDRIVE%\Programs\...".

The loader that interprets these lines should interpret %CDDRIVE% as the drive that contains VistaPE.cfg, whether it's a CD drive or not. Apparently some loader or loaders don't always do that. If you are booting from USB and the loader interprets %CDDRIVE% as a CD drive, there's a problem.

I think this is not so much a Vista problem as a poor design choice made by Nightman. Maybe a junction point could be set up somehow? I'm no expert on how to fix it.

[pscEx]

The base problem in VistaPE and Win7PE is that the target drive is unknown until boot time.
...

Thanks, JonF!

Now I know a lot more as before!

When I understood correctly, the issue is that drive letters are assigned 'randomly' (depending on the actual HW)

Just a quick and dirty idea:
The 'Volume name' of a drive is known or can be defined at build time (?).
What about an app in early PE boot to link the volume name and the drive letter?

Peter

[Joshua]

The loader that interprets these lines should interpret %CDDRIVE% as the drive that contains VistaPE.cfg, whether it's a CD drive or not.

After i have a quick look to vpeldr code, i agree with you!
I will change my loader/shortcut programs to solve this problem.

Joshua

[pedrole15]

You perhaps adapte the shc.au3 (you find it in explorer.script for liveXP)
 SHC.AU3.txt   8.99KB   50 downloads

[Stephanowicz]

After i have a quick look to vpeldr code, i agree with you!
I will change my loader/shortcut programs to solve this problem.

Joshua

Hi,

just testing Your Win7Rescue setup...
Really great!
BUT what about the proposed path fix for usb drives???

BTW: I searched a lot in the forum, but did not find any satisfactory description where and how the path variables (like %SystemDrive% %cddrive%)in win7pe.cfg are set - is there a tutorial that covers this?
I'm asking because there's a registry entry in HKLM\System\CurrentControlSet\Control\PEBootRamdiskSourceDrive that holds the drive letter of the boot device. The key is set by "Wpeutil UpdateBootInfo". Therefore one could assing it to a pathvariable and use it in win7pe.cfg for the shortcuts to the program folder...
My question is how can I read the key and assign it to a variable I can use in win7pe.cfg?

Thanx in advance!

Steph