211 replies to this topic

[paraglider]

Also the option in win7rescue pe to run wiminfo to identify the configurations in the source wim files is a useful option. May be you could consider adding that to your project.

[paraglider]

Also 0-preconfig.script no longer attempts to use imageex from windows aik. That stops the build mounting images on win7 x64.

[was_JFX]

Why don't you ask Nuno Brito to create you a winbuilder website so your project can be downloadable via winbuilder?

When project ready...

Also 0-preconfig.script no longer attempts to use imageex from windows aik. That stops the build mounting images on win7 x64.

Dependency of waik was drop with release from Mar 25, it makes use of imagex and wimfilter of vista sp1 versions.

[Lancelot]

to fix registry issue of latest package, here are workaround scripts

http://lancelot.winb.....2-Device X.7z
http://lancelot.winb.....2-Device Y.7z

extract to addons as usual .

ps: for default builds, enable "2-Device Y"

ps: @CD-RW , use "2-Device X"



Have fun.

[paraglider]

----------Service Note----------
Posts here moved from Multi7PE continue topic since topic owner JFX annoyed from topic goes out of MultiPE discussion.

What the hell going on here Is this now a topic win7 vs. vista

Lancelot
----------Service Note----------
----------Service Note #2 ----------
Moved just this post back, because:
#1: An answer to Paraglider's question made by JFX (next post), would be ununderstandable.
#2: Paraglider's worries about illegality would be removed from the topic where it is posted to.
PSC
----------Service Note #2 ----------

So you are saying you have removed windows 7 as the build platform?

Also as I am sure you are aware MS prohibits redistribution of AIK and windows components.

Believe you should investigate using the PSC wimcaptex approach if you want to remove dependency on AIK components.

[was_JFX]

What the hell going on here Is this now a topic win7 vs. vista

If anyone has a problem with special files, don't use it.

If anyone can't live with the way special files are handled, we can stop working on and remove project.

I'm already very annoyed, that the most important things in project seems some shortcuts or the stupid way Pe2/3 projects handle program locations.

So you are saying you have removed windows 7 as the build platform?

No! Project 'auto detect' missing wimfilter v1 and install it, look in preconfig.script. Doesn't this work for you?

[paraglider]

No. The vista version of imageex does not work in windows 7 x64.

[paraglider]

Although when I run it from the command line it does appear to work. I did manually also run instwimfltr

[Lancelot]

All the trouble JFX and Lancelot have had with shortcuts and drive letters,, I would wait

Hi PaPeuser, it is not a trouble*. There is an old design issue and since I did not want JFX spend his valuable time on fixing these things (like capi integration) I found workaround script(s). With last edition I see JFX misunderstand the issue narrowing down to a "shortcut issue" (where same mistake also made somewhere else ....) and made another workaround to fix only shortcuts which does not solve issue. (I explained JFX in detail early today).

Well I also missed the fact that cd drive can be X: (not Y:) on some builds ... so this time i put 2 workaround scripts


Let me give you a summary:
Issue is mainly %cddrive% variable not defined on win7 projects.
In the past issue discussed here , Jonf fixed issue on VistaPE-Capi, Max_Real QNX informed and as far as i know Max_Real QNX also made required fix on Leopard b3, yahoouk informed but I guess did not made a solution. Since JFX continues yahoouk's project, naturally this heritage continued....

Recently this missing on win7 projects discussed also here

ps: As far as i know all popular wb based win7 projects uses yahoouk's legacy with other words, we can say yahoouk is the Father of these projects.



what is %cddrive% ?

when you add an app script to your build (without runfromram enabled) the path defined lines added with %cddrive% (shortcuts + registry + .. whatsoever)

When PE boots, these applications are on CD with an unknown drive letter at the very begining, a mechanism required at bootup that should find drive letter and add %cddrive% to environmantel variable. (currently there not exists)

How not having this effect:
In the past it was causing missing shortcut and registry (and maybe other thingies if script requires), JFX made a workaround for only shortcut... but others left.

What does workaround scripts do:
"CdDrive Y:" makes cd drive letter to Y: at very begining of boot and ALL (shortcut, registry, etc) values during build written with Y: instead of %cddrive% hence everything works on PE
"CdDrive X:" makes cd drive letter to X: for build process (should be used with "Build model Normal" OR if build made with "ALL from ram")

Goal of workaround scripts:
I personally do not want JFX spend time on such a fix which has nothing to do with building Multi PE.
Besides I do not want end user reports saying some apps scripts not working for this reason, ex: http://www.boot-land...showtopic=10752

So end users can use apps scripts easly without causing "not working script" posts around, they are happy.
JFX can focus on core building elements without not spending time on such posts, JFX happy.

and this thingy can be later perfectly fixed the day JFX ends thingies with core elements. (or maybe in time a user (ex: PaPEuser) can come with a ready to apply solution )

And they live happly after

ps: more or less , shutdown related posts moved here and off topic posts moved here

[paraglider]

If I select the full copy option then after booting PE if I attempt to open control panel from the start menu then I get a reboot. This does not happen with standard copy.

This is building on win7x64 from win7.x86 source.

Previous version ( Win7PE_SE_25_03_10.7z ) did not have this problem as I always use full copy - you get slightly better driver installation with full. At least in vmware I get the vmware video driver to install when using full copy. Never have managed to get nvidia drivers to install with either full or standard copy.

[PaPeuser]

With other more important issues. Why waste time with ShutdownPE right now?
ShutdownPE is an add-on and I think it should remain so
Even if you find a fix today . I think it was yesterday . by calling “CdDrive Y” that may change tomorrow .. So why waste time with addons at this point.

Most scripts work, I have 15 or more scripts I added and test with every version..

I would rather see more people testing different sources and reporting
Win7 x64
Win7 x86
Vista x86
Vista x64 and whatever else
How about different versions of WAIK if this goes on line??

Full file copy I had a problem and reported long ago, but either I did not have the time or a new update package came out, and I never followed up on it. (My Fault)

And when someone does report they should say what source. Because this project has many possible configurations. There are too many for a few of us to test.

Think of all the questions YOU will have to answer when this becomes a download

Hey right now I am discussed.. later

[was_JFX]

Thanks Lancelot for clarifying issue and clear topic.

Previous version ( Win7PE_SE_25_03_10.7z ) did not have this problem as I always use full copy - you get slightly better driver installation with full.

Thanks, your right i moved some files from explorer script to copy files and forgot to add also to fullcopy section.



@PaPeuser
I tested driver integration also with vista sp1 x86 / x64 but had no problem.

[paraglider]

Thanks. That fixed it.

[PaPeuser]

I always use Win7 x64 to test and build, if all is ok I switch to x86

With build package Win7PE_SE_04_03_2010.7z
I could easily change source from x64 to x86 and build with no errors

With build package Win7PE_SE_04_04_2010.7z
By its self I can switch back and forth from x64 to x86 no problems

With build package win7PE_04_04_2010.7z
And with latest 1 file 7z script update
I build with x64 no problems – I switch to x84 and get a build stopped due to error
Error
DirCopy – failed to copy directory [%baseDir%\Temp\Win7PE_SE\bootWimSrc\*.*] to: [%BaseDir%\Target\Win7PE_SE]: + s

My source for x86 builds is Win7 RC, maybe the release is not supported any more, even with an x86 build?

Tested and checked with new packages new folders, no add-on scripts

[pscEx]

DirCopy – failed to copy directory [%baseDir%\Temp\Win7PE_SE\bootWimSrc\*.*] to: [%BaseDir%\Target\Win7PE_SE]: + s

This is an error which frequently occurs.
You can see it in several logs around here.
Unfortunatelly there is a bug in the current log generator which displays " + s" rather than the error description.
Next beta it is fixed.

Until then I do not see a chance to find the root of the illness. Please be patient for some days (Nuno today asked me to do an agreement for next beta publish date).

Peter

EDIT:

I build with x64 no problems – I switch to x84 and get a build stopped due to error

This is an interesting information I did not have previously.
I hope it helps a lot!

[pscEx]

I build with x64 no problems – I switch to x84 and get a build stopped due to error

Can you try in a fresh download first with x86 and second with x64?

Sorry that I use your patience!

peter

[was_JFX]

My source for x86 builds is Win7 RC, maybe the release is not supported any more, even with an x86 build?

RC versions are not officially supported, but should work in most cases without a problem.

I do plenty build daily and often switch between x64/x86 host OS and x64/x86 sources without getting an error

[pscEx]

RC versions are not officially supported, but should work in most cases without a problem.

I do plenty build daily and often switch between x64/x86 host OS and x64/x86 sources without getting an error

For the record:

On my XP-SP3-Pro-DE host Win7-RC1-DE builds well and runs into VirtualBox 3.1.6

Peter

[PaPeuser]

Package updates all come with WB 8 included

With the package Win7PE_04_04_2010.7z,, i add the new 1-files update

i only ran a x86 build in a new folder - still same error

without adding 1-files update -- and all builds before 1-files i could use the Win7RC with out a problem to build a x86

My source for x86 builds is Win7 RC, maybe this older version of Win7 is not supported any more?

This is not a WB problem. This worked for paraglider

I will just assume that Win7RC is no longer supported....

Thanks

[pscEx]

I will just assume that Win7RC is no longer supported....

Sorry, now I'm starting to understand
I now think it is more an issue of the project than an issue of W7-RC

RC versions are not officially supported, but should work in most cases without a problem.

It means "supported in this project".
That's ok for me. Every project is defined for some "source" and "target"

Sorry, I'v had the feeling that there is an WinBuilder issue!

Peter

[was_JFX]

There really only 4 files added to full copy section.

But may a log file could help to find the reason of

[PaPeuser]

Heres a Log file I hope,,,,,,,,,,

link deleted

Why I posted about my new problem with Win 7 RC being used as a source, was really for future reference. Now I know the RC version will not work and what error messages maybe seen in future posts.

No problem, I will just stay with a x64 build till I get a better x86 source.

Edited
Updated Win7 32 bit source to GRMCULFRER_EN_DVD now no problems or errors....
My Win7 64 is GRMCPRXFREO_EN_DVD
Both build and boot no problems

Thanks.. this is not a WB problem,,

[was_JFX]

Thanks PaPeuser,

it's good to hear that your problem is gone.

However this is truly a wb bug and i hope psc find a solution for this.

[was_JFX]

Win7PE_SE_04_10_2010.7z

- replaced clid.reg with complete classes subkey of full OS
- replaced win7peldr with peshell
- removed VMWareNIC, VirtNet Network Adapter
- removed shell selection from Main Configuration, all needed settings in Shell section

[techvslife]

This version gives me this error when building x64 (looks like it's one additional program script, not part of the download):

(UltraISO.script) FileCopy - Failed to copy [%BaseDir%\Projects\Tools\Win7PE_SE\x64\hiderunEx_x64.exe] to: [%BaseDir%\Target\Win7PE_SE\Windows\System32\hiderun.exe]: The system cannot find the file specified.

UPDATE: found the file in the nativeEx7 project and copied it over. This resolved this problem.
Comments on this build are here:
http://www.boot-land...?...ost&p=97592