Printable Version of Topic

Click here to view this topic in its original format

Boot Land _ LODR Universal & Portable Apps _ Separation of system-core and user-stuff: LODR-packs

Posted by: sanbarrow Jan 3 2009, 03:32 AM

Little suggestion for winbuilder if you don't mind ...

Please http://sanbarrow.com/moa24/videos/lodr-packed-apps.html - it shows my prefered way of adding apps to a PE.
Every thing needs its name and so I called this way of adding apps LODR-packs.
LODR-pack means a procedure of packing an app in such a way that it can be Loaded On Demand.
In MOA I do everything like that ... dotnet2 ... java ... vmware workstation ... everything.
I also load about 2/3 of a typical LiveXP programs collection that way ... same with UBCD4win stuff.
This procedures makes it very easy to keep tons of apps ready at hand without need to rebuild the core over and over again.

A LODR-pack is a directory + a batch or a compiled script ready for use.
It can be automated by adding a single line to either prenetwork-batch.cmd or late-batch.cmd.
It does not need any registry stuff or files added at build-time.
It can be loaded from any path.

The batch creates a junction to the correct path and then speed-installs the app if necessary - like for example with VirtualBox.

If we could agree on some conventions you could use some of my stuff and I could maybe use some of yours ...

regards Ulli

By the way - do you know Damn Small Linux and its way of having a repository of LODR-packs ? - they call that .dsl packages.
We could have the same ...

Posted by: amalux Jan 3 2009, 04:11 AM

Forgive my ignorance but what are the advantages? Assuming it could be done, say an Acronis TrueImage LODR-pack for LiveXP; would it still be portable, bootable from any machine? Would it reduce image size/loading time? Could you still choose any read/write media to boot from? Could it still be RAM loadable for fast performance in PE?

Posted by: sanbarrow Jan 3 2009, 04:22 AM

QUOTE
Would it still be portable, bootable from any machine?
- sure - your core system does the booting - not the app
QUOTE
Would it reduce image size/loading time?
- of course - LODR-packs can be where ever - you do not even need to add them to the build
QUOTE
Could you still choose any read/write media to boot from?
- same as #1 - you can boot from where ever your core-system boots from.
QUOTE
Could it still be RAM loadable for fast performance in PE?
- yeah - sure - in MOA I always ramload for performance

This is not about changing your LiveXP-core - its just about packing the apps slightly different.
You now use app-scripts - that means you must run a downloaded app-script through winbuilder once - if you pack as LODR-packs you can directly use it.
And it will not influence your core-system in any way - download a LODR-pack from a running LiveXP - test it - if its nice keep it and store it where ever - if its crap delete it again.

In MOA the complete instructions for adding VirtualBox are:
download from SUN
install once
keep the files
next time you need it - start it with the lodr-pack batch from here ....

Adding apps can't be any easier

Posted by: amalux Jan 3 2009, 04:36 AM

QUOTE (sanbarrow @ Jan 2 2009, 08:22 PM) *
And it will not influence your core-system in any way - download a LODR-pack from a running LiveXP - test it - if its nice keep it and store it where ever - if its crap delete it again.

This sounds great but just to be sure I'm understanding correctly, you're saying this could work in a real hardware booted LiveXP or only in VM-environment like MOA?

Posted by: sanbarrow Jan 3 2009, 04:39 AM

QUOTE (amalux @ Jan 3 2009, 04:36 AM) *
This sounds great but just to be sure I'm understanding correctly, you're saying this could work in a real hardware booted LiveXP or only in VM-environment like MOA?


Nothing of this requires any VM-environment - in fact Workstation is just another LODR-pack in MOA - I only load it on demand and it is not required

Posted by: amalux Jan 3 2009, 04:44 AM

QUOTE (sanbarrow @ Jan 2 2009, 08:39 PM) *
Nothing of this requires any VM-environment - in fact Workstation is just another LODR-pack in MOA - I only load it on demand and it is not required

I'll be taking a close look at MOA (again) to if I can figure out how these LODR-packs are setup and how they can be ported to LiveXP. I'm sure to have questions along the way, thanks for your forward thinking here and any help you can provide this MOA noob smile.gif

Posted by: sanbarrow Jan 3 2009, 04:48 AM

Look at the batch I made for VirtualBOX - here http://www.boot-land.net/forums/index.php?showtopic=6588

As all speed-install instructions are plain batch you can easily adopt it to your environment.

The dotnet2 or workstation packages I have are much more advanced but basically they work the same.
Both of those will not translate to winbuilder easily as we use such different layouts - but we could talk about reasonable standards ...

Posted by: Lancelot Jan 3 2009, 11:04 AM

sanbarrow

can you put a movie player for your movies so we can pause, forward backward when watching smile.gif

and yes, LODR-pack method you introduced (repeatedly smile.gif ) may be used with livexp, I just have a great idea for "Midway" smile.gif , but need some days smile.gif.

Posted by: Galapo Jan 3 2009, 11:09 AM

Good, I'm interested too.

One standard I'd like to suggest: no hard-coding of drive letters. Only use existing variables, or we could agree on a standard variable which a given project may define as a hard-coded path.

Regards,
Galapo.

Posted by: Lancelot Jan 3 2009, 11:13 AM

Galapo

thumbup.gif i have a great idea, give me 2 days smile.gif

Posted by: Nuno Brito Jan 3 2009, 11:24 AM

Hi Sanbarrow.

I agree with Lancelot, would you please upload to youtube and post the link here?

Makes it easier for everyone to see the video.

Thanks.

smile.gif

Posted by: sanbarrow Jan 3 2009, 12:44 PM

QUOTE
One standard I'd like to suggest: no hard-coding of drive letters


Whats the problem with hard-coded driveletters ?

Look for example at dotnet.
The way I prepare this into a LODR-pack I do a regshot while installing it on the fly running PE and I directly use that reg-patch without any manual editing required for the lodr-pack.
If you introduce variables you need to manually edit the patch first - then you apply it later on and have to do something like reg-expand again.
I don't need to do all that.

Have a look at Linux - they put apps in /usr/bin or /usr/local/bin - which are hardcoded paths too.
What the Linux folks do with redirecting usr/bin to /dev/sda3 or whatever in fstab - I do with a single junction command at run-time.
That is so much easier than translating twice while using un-necessary variables.

Posted by: psc Jan 3 2009, 02:08 PM

Congrats, Ulli thumbup.gif

The Load-On-Demand is a great idea!

Currently:
On every boot you have 'thousands' of RunOnces doing a lot of never used reg entries etc.
On every boot you start 'thousands' of services you never need.
On every boot you start 'thousands' of drivers you never need.
On every boot ...

With Load-On-Demand:
If you need in a certain recovery a certain app / feature / driver / service etc., just install it and you have it!

Great!

Please try to make it 'WB - Usable' by providing a script to generate a LODR package
(BTW: I would accept a cmd batch only if it is controlled by a WB script diablo.gif )
@All: In addition to the well known 'App Scripts' I can imagine a class 'LODR Scripts'

Peter

EDIT:

I thought about it and will try to publish a nativeEx_LODR project next weeks.

Based on nativeEx_barebone_075 it will contain an app which inside the PE will offer a download list to download, install and execute the LODR app / driver / service.

I'm rather sure that such a project with minimum build time, minimum ISO size, minimum boot time and maximum features (depending on the collection of LODR packages) will have a great future.

@sanbarrow, can you PM me for tests one package, maybe the VMWare or VirtualBox?

Posted by: sanbarrow Jan 3 2009, 03:20 PM

Peter - thanks a lot for your open minded attitude cheers.gif

QUOTE
Based on nativeEx_barebone_075 it will contain an app which inside the PE will offer a download list to download, install and execute the LODR app / driver / service.


You got it - thats exactly what this is about.
Separate the core-system as cleanly as possible from the stuff that can be loaded on demand.
We sure would have to introduce a classification for the different core-systems we use.
We can't expect that a dotnet2-LODR-pack created for MOA or LiveXP runs on a 31 MB naked core-system - but that should be no problem.
Maybe we need core-classes like
"naked" - "native-XP" - "LiveXP" - "MOA-like" - "VistaPE" - "2k8-PE" - ... what ever the future may bring ...
So what - that doesn't change the beauty of this approach.

Sure - we may find out that some apps can't be LODR-packed ... maybe some Acronis stuff doesn't work that way.
But that doesn't matter - things that can't be packed this way can be added the usual way with app-scripts or plugins
- or if they are important enough - they may also be added to the core-system itself.

The big advantage of this approach is that we "advanced PE-hackers" can then create solid core-systems that can be easily reproduced by unexperienced users.
We can then leave adding the additional bells and whistles to the users.

Ulli

Posted by: MedEvil Jan 3 2009, 04:55 PM

Looks like deviding the projects into Vista based and XP based is outdated.
Maybe better groups would be:
- PE for old fashioned people and/or computers
- If you have enough RAM to run a full install from RAM, you mighty also have enough for this PE! wink.gif

Guys seriously, if i work only on machines that have so much RAM, that i can first install all applications to ramdisk and then even run them, then i need no stinking PE with tons of features missing. I simply go for an automated install.
We even already have a project like this!


cheers.gif

Posted by: Nuno Brito Jan 3 2009, 05:02 PM

QUOTE
Whats the problem with hard-coded driveletters ?


It's not just the driveletters, system folders are also hardcoded and this would mean a pack for each specific project which is what we worked so far to avoid in the first place.. laugh.gif

You're still thinking on terms of a I386 from XP PE but on Windows PE 2.x it is used the \Windows or anything else so this would mean for a start to double the work to make the same pack available for two projects.

If in the future comes a 7PE that places all system files in \kernel then we'd have to redo all again.. dry.gif

Also, how would the Documents and Settings folder be handled? On XPE from sherpya you'd see it in english but what if you're copying the registry entries for the german OS, wouldn't the paths differ?

There are plenty of reasons to keep things as flexible as possible.

--------

Otherwise it would mean a return to static paths everywhere and would impose developers to create several packs for each project.

Look on bartPE with the INF format, it would never work under Windows PE 2.x if there weren't app scripts available to translate .inf into a generic script language that is shared between projects.

The same thing for nLite as all the addons were coded with XP in mind but now that Vista changed things a little, this automatically meant that all previously made addons would not be recycled.

It doesn't mean that bartPE plugins or nLite addons don't work with newer OS's, it's just that they are not flexible and now will mean repacking them again.

We've learnt this lesson some years ago while each wb project used it's own way to write scripts for adding programs.

The current method helps to build and maintain a large library of available apps that can be used in future projects for any sort of objective.

-------

Please note that I'm not against the idea of LODR but I'm an ecologist and would really be sad to witness such waste of bytes that wouldn't be recyclable by other projects.

We need to think about preserving the environment and any LODR-pack should be made as project-agnostic-friendly as much as possible to ensure it has a chance to survive in this crazy world of ever changing projects.. cheers.gif

Posted by: psc Jan 3 2009, 05:03 PM

QUOTE (MedEvil @ Jan 3 2009, 05:55 PM) *
Looks like deviding the projects into Vista based and XP based is outdated.
Maybe better groups would be:
- PE for old fashioned people and/or computers
- If you have enough RAM to run a full install from RAM, you mighty also have enough for this PE! wink.gif

Guys seriously, if i work only on machines that have so much RAM, that i can first install all applications to ramdisk and then even run them, then i need no stinking PE with tons of features missing. I simply go for an automated install.
We even already have a project like this!


cheers.gif

Nobody demands that you use it.

I remember ICE age when I came up with the nativeEx idea.

There was also nobody who needed it. But I just did ...

Therefore, if we do not hurt or hinder somebody, please allow sanbarrow and me to waste our time ...

Peter

Posted by: Nuno Brito Jan 3 2009, 05:11 PM

QUOTE
I remember ICE age when I came up with the nativeEx idea.
........
So, please allow sanbarrow and and me our personal fun.


Will do, sanbarrow is in good hands with no doubts.

I was just worried about seeing our work moving back to the dark ages.

Hope both of you have fun exploring further this method!

cheers.gif


Posted by: psc Jan 3 2009, 05:13 PM

QUOTE (Nuno Brito @ Jan 3 2009, 06:11 PM) *
I was just worried about seeing our work moving back to the dark ages.

I have the vision that just the opposite will happen!

Peter

Posted by: Nuno Brito Jan 3 2009, 05:19 PM

You're wicked.. punk.gif

Posted by: MedEvil Jan 3 2009, 05:19 PM

QUOTE (psc @ Jan 3 2009, 06:03 PM) *
please allow sanbarrow and me to waste our time ...

By all means, please waste away! wink.gif
It's not like i could stop you anyhow. laugh.gif

cheers.gif

Posted by: psc Jan 3 2009, 05:27 PM

QUOTE (Nuno Brito @ Jan 3 2009, 06:19 PM) *
You're wicked.. punk.gif

It's my lack of English. I do not understand whether 'wicked' is a compliment or an agression.

But nevertheless: My vision is not new.

When some years ago Billy the Door invented dot net, he told us, that a small (seen from now: huge) core is sufficient. Everything else can be downloaded on demand.

And I hope, that our realization will become a bit better than the 'dot net' realization and can survive with a really small core.

(What is helpful: here we do not have to satisfy billions of users, we only have to satisfy some thousands of users tongue.gif )

Peter

Posted by: Lancelot Jan 3 2009, 05:34 PM

Well

probably sanborrow and peter will work hard on this, and what i will do will be rubbish, so better to summerize my idea for "Midway":

Idea:
i thought of a different name, "wim-Lpack" (wim Load pack) and "LOD" (Load on Demand) as a suboption:

wim-Lpack
|
|---->LOD

when a user enable checkbox for wim-Lpack
during build
the build will check if FastStoneCapture_Files_v1.wim exists at %GlobalTemplates%\wimlpack_Files\ ,
--> if exists will copy to %Target_Prog%
--->if not exits, the folder will be wimmed (like FastStoneCapture_v1.wim ) and will be copied to %GlobalTemplates%\wimlpack_Files\ and %Target_Prog%

Than if LOD checkbox is selected, than it will copy a .cmd file and related shortcuts
--> if LOD checkbox not selected than it will add to mount .wim at startup

on livexp the wim file will be mounted (either at startup when LOD disabled or as descibed in sanbarrow's way) to
%RAMDriveLetter%\%ProgramsFolder%\%ProgramFolder%\


Well this idea have lots of advantages,
1) first of all it is easy to update the script so the relevant wim will be updated too, (+it is also easier to update .wim)
2) Also besides FastStoneCapture_v1_Files.wim , there can be FastStoneCapture_v1_Reg.reg, FastStoneCapture_v1_Shortcut_Desktop.7z with same idea
which will result the build be faster
3) the iso created with "create iso" will be smaller compared with disableing wim-Lpack unselected
4) there can be a verify to check if bootsdi and fbwf is selected for some scripts that needs to write %systemdrive%


Well these are my ideas, i hope you like (or understand), i will wait to see what peter and sanborrow do, good luck.

Posted by: psc Jan 3 2009, 05:42 PM

Thanks, Lancelot!

I'm glad to see that there is #3 of the 'on demand' idea.

Currently I do not understand your post completelly (due to 'Midway'), but I'm going to try.

Peter cheers.gif

EDIT: My be now I understood: What you are describing, logically describes my vision nearly completelly!

Posted by: sanbarrow Jan 3 2009, 05:52 PM

@ medEvil

QUOTE
Guys seriously, if i work only on machines that have so much RAM, that i can first install all applications to ramdisk and then even run them, then i need no stinking PE with tons of features missing.


You miss the point - only the LODR-pack developer has to do this once. Then he creates a batch/script so that other users can use it with minimal requirements.
For example the combined dotnet2 and VMware-apps package I maintain called "esx-tools" needs about 250 Mb of free space in X: during creation.
Thats not practical for daily use of course but you only need to do that once.
Once that is LODR-packed you can then use it on a system with 15 Mb of free space in X:

I think the VirtualBox packages may work with 1 Mb of free space in X:
And by the way - I rarely use a ramdisk this days as in MOA I don't need one most of the times.

QUOTE
I was just worried about seeing our work moving back to the dark ages.


hyper.gif - hey this post gets really funny tongue.gif

Hey - the LODR-pack I use for Workstation installs any recent version you throw at it at run-time in a matter of seconds with minimal RAM requirements.
If you call that ice-age style then - yeah I love the ice-age tongue.gif

Posted by: Lancelot Jan 3 2009, 05:57 PM

It is nice to read nice things from you Peter,

Some more things about 'Midway' to clarify,

With 'Midway' i mean: this is not absolutely sanborrow's method, this is a method that will suit Nuno and Galapo's (and mine) concerns tu use LOD (+wimL)

And i highly believe, many things i wrote can be done automatically by api without changing a script a lot like FastStoneCapture.
With my idea only adding 2 (or 3) options to the begining of [process], and rest can be done by api
ex:
For wimL: 1 interface button and 1 line to the beginin process section for wimL -->will be enough for most scripts like FastStoneCapture--->rest can be done by api
For wimL+LOD: 1 interface button and [LODextra] section for creating .cmd file and related shortcuts for loading on demand

Maybe somebody who understands what i mean can post with better english, if nobody understands, than lets drink beer cheers.gif .


Anyway, smile.gif, i will be glad to be the first tester smile.gifsmile.gif for the result of work you will do with sanbarrow. Good luck thumbup.gif

Posted by: sanbarrow Jan 3 2009, 06:00 PM

@ Lancelot - sorry I missed your post ...

I also often use wims to safe space - it doesn't really matter if you use the directory directly or if you wrap it in a wim.
Wrapping in wims of course makes a lot of sense on CD-only builds.

If you carry your optional apps on a USB-disk or stick you can as well use straight directories because size does not matter anymore with recent 2.5 inch USB-disks or large sticks

Posted by: Lancelot Jan 3 2009, 06:08 PM

Sanborrow,

with your idea of LOD, i just try to combine things together for midway. Saving space is 3rd benefit i wrote on "post #23" (totally i wrote 4 additional benefits for my idea, but with reasons you explanined it should be 5 and maybe more)

anyway, good luck cheers.gif

Posted by: psc Jan 3 2009, 06:12 PM

QUOTE (Lancelot @ Jan 3 2009, 06:57 PM) *
It is nice to read nice things from you Peter,

Is it so rarelly?
I always try to tell the truth.

Maybe that sometimes it hurts the interest or opinions of some members. But I do not want to hurt the members themselves with my post. My intention is to point to things which help to become the WB world better.

Peter

Posted by: Lancelot Jan 3 2009, 06:16 PM

QUOTE (psc @ Jan 3 2009, 08:12 PM) *
Is it so rarelly?
I always try to tell the truth.

Maybe that sometimes it hurts the interest or opinions of some members. But I do not want to hurt the members themselves with my post. My intention is to point to things which help to become the WB world better.

Peter
This needs another topic, maybe next month biggrin.gif cool.gif

Posted by: MedEvil Jan 3 2009, 06:38 PM

QUOTE (sanbarrow @ Jan 3 2009, 06:52 PM) *
so that other users can use it with minimal requirements.
For example the combined dotnet2 and VMware-apps package I maintain called "esx-tools" needs about 250 Mb of free space in X: during creation.
Thats not practical for daily use of course but you only need to do that once.
Once that is LODR-packed you can then use it on a system with 15 Mb of free space in X:

I think the VirtualBox packages may work with 1 Mb of free space in X:

So by your own admittance you need 250MB of RAM to install + ??MB of RAM to run Application+Dot.Net + 15MB of RAM to have 15MB free on X:
Now please add the RAM required by the OS and i would guess your solution won't run with much less than 1GB of RAM.

Or am i missing something?

QUOTE (sanbarrow @ Jan 3 2009, 06:52 PM) *
And by the way - I rarely use a ramdisk this days as in MOA I don't need one most of the times.

confused1.gif You use no Ramdisk and yet have writable space on X:? If your idea is for portable HDD or USB-Stick, it makes even less sense. Sorry.

cheers.gif

Posted by: psc Jan 3 2009, 06:56 PM

QUOTE (MedEvil @ Jan 3 2009, 07:38 PM) *
So by your own admittance you need 250MB of RAM to install + ??MB of RAM to run Application+Dot.Net + 15MB of RAM to have 15MB free on X:
Now please add the RAM required by the OS and i would guess your solution won't run with much less than 1GB of RAM.

Or am i missing something?


confused1.gif You use no Ramdisk and yet have writable space on X:? If your idea is for portable HDD or USB-Stick, it makes even less sense. Sorry.

cheers.gif

Medevil, I do not know your age. But when NASA sent Armstrong to the moon, did you also discuss with them before?

I waited for the result.

Peter

Posted by: sanbarrow Jan 3 2009, 07:00 PM

QUOTE (MedEvil @ Jan 3 2009, 06:38 PM) *
So by your own admittance you need 250MB of RAM to install + ??MB of RAM to run Application+Dot.Net + 15MB of RAM to have 15MB free on X:
Now please add the RAM required by the OS and i would guess your solution won't run with much less than 1GB of RAM.

Or am i missing something?


The dotnet package requires a ramloading build which needs at least 10 maybe 15 Mb of free space in X: - in MOA I usually use a 250 or 280 Mb NTFS-image to do that.


QUOTE
confused1.gif You use no Ramdisk and yet have writable space on X:? If your idea is for portable HDD or USB-Stick, it makes even less sense. Sorry.


In MOA environment I use a cheatcode prompt at boot-time where I can redirect the usual ramdisk to where ever - if possible I redirect it to an USB-disk ... but it really doesn't matter.
The redirection is completely transparent - there is no change in behaviour if you a use ramdrive or a truecrypt-container or whatever for R:\

On the USB-disk I use now I have about 4 Gb of apps - all of them can be loaded on demand


QUOTE
But when NASA sent Armstrong to the moon, did you also discuss with them before?

roll1.gif

Posted by: psc Jan 3 2009, 07:56 PM

QUOTE (Lancelot @ Jan 3 2009, 07:16 PM) *
This needs another topic, maybe next month biggrin.gif cool.gif

Then it is better to forget the issue!

(With respect to my age) Next month (> 28 days!!!) I have forgotten this discussion

Peter cheers.gif

Posted by: MedEvil Jan 3 2009, 07:58 PM

QUOTE (psc @ Jan 3 2009, 07:56 PM) *
when NASA sent Armstrong to the moon, did you also discuss with them before?

Maybe they better should have. wink.gif
No need to kill a few people by a big fire cracker, just to avoid some discussion and planing!

cheers.gif

Posted by: psc Jan 3 2009, 08:12 PM

QUOTE (MedEvil @ Jan 3 2009, 08:58 PM) *
Maybe they better should have. wink.gif
No need to kill a few people by a big fire cracker, just to avoid some discussion and planing!

cheers.gif

Armstrong killed by 'a big fire cracker' ????
When ????
Where ????
How ????

Maybe I'm currently really a good friend of Mr. Altzheimer frusty.gif

Peter

Posted by: sanbarrow Jan 3 2009, 08:25 PM

@ Nuno

you are so worried about additonal work this may require. Really - don't worry.

It just took me two minutes to translate my virtualbox-lodr-pack with hardcoded paths to something that may more fit your needs.
Adopting a 15 lines batch to new environment really is no work at all.
See yourself

This pack now only assumes you have regsvr32.exe , drv_ctl.exe and snetcfg.exe somewhere in your path.
I guess this is really not asking for too much ...

CODE
@echo off

if not exist %programsdir%\virtualbox\Virtualbox.exe md %programsdir%\virtualbox
if not exist %programsdir%\virtualbox\Virtualbox.exe junction virtualbox %programsdir%\virtualbox
if not exist %programsdir%\virtualbox\Virtualbox.exe imagex /mount %sfxdir%\virtualbox21.wim 1 %programsdir%\virtualbox
if not exist %programsdir%\virtualbox\Virtualbox.exe exit

regsvr32 /s %programsdir%\virtualbox\VBoxC.dll
copy %programsdir%\virtualbox\drivers\network\netflt\protocol\VBoxNetFltNotify.dll %systemroot%\system32\VBoxNetFltNotify.dll
copy %programsdir%\virtualbox\drivers\network\netflt\miniport\VBoxNetFlt_m.inf %inf-dir%\VBoxNetFlt_m.inf
copy %programsdir%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.inf %systemroot%\inf\VBoxNetFlt.inf
copy %programsdir%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.sys %systemroot%\system32\drivers\VBoxNetFlt.sys
snetcfg -v -l %systemroot%\inf\VBoxNetFlt.inf -c s -i sun_VBoxNetFlt
snetcfg -v -l %systemroot%\inf\VBoxNetFlt_m.inf -c s -i sun_VBoxNetFltmp
regsvr32 /s VBoxNetFltNotify.dll
drv_ctl --inst-nostart VBoxDrv %programsdir%\virtualbox\drivers\VBoxDrv\VBoxDrv.sys
drv_ctl --inst-nostart VBoxUSB %programsdir%\virtualbox\drivers\USB\device\VBoxUSB.sys
drv_ctl --inst-nostart VBoxUSBMon %programsdir%\virtualbox\drivers\USB\filter\VBoxUSBMon.sys
net start VBoxNetFlt
net start VBoxDrv
net start VBoxUSBMon
start %programsdir%\virtualbox\VBoxSVC.exe
start %programsdir%\virtualbox\Virtualbox.exe
rem pause
exit


cheers.gif

Posted by: Galapo Jan 3 2009, 09:48 PM

QUOTE (sanbarrow @ Jan 3 2009, 10:44 PM) *
Whats the problem with hard-coded driveletters ?

Because then the LODR-pack would be tied to the project under which it was developed.

I would like to see LODR-pack being able to be used outside of PE environment, where, say, %SystemDrive% is generally c: rather than x: etc.

Also, maybe these LODR-packs should also provide for uninstalling themselves when no longer needed in addition to providing installation instructions.

Regards,
Galapo.

Posted by: sanbarrow Jan 3 2009, 09:54 PM

QUOTE
I would like to see LODR-pack being able to be used outside of PE environment, where, say, %SystemDrive% is generally c: rather than x: etc.


Galapo - thats usually called "portable app" then - thats much much more work.
In PE you usually don't need any cleanup routines - don't you ?

Posted by: MedEvil Jan 3 2009, 11:39 PM

QUOTE (psc @ Jan 3 2009, 09:12 PM) *
Armstrong killed by 'a big fire cracker' ????
When ????
Where ????
How ????

Who said anything about Armstrong? frusty.gif

We're talking here, while you're at the first steps of your idea.

And during the first steps of the project, to send a man to the moon, namely Mr. Armstrong.
A number of people died and this includes some astronauts, that were killed in their big fire cracker.


cheers.gif

Posted by: amalux Jan 3 2009, 11:50 PM

QUOTE (MedEvil @ Jan 3 2009, 10:38 AM) *
Or am i missing something?

Yes! A fully working LiveXP with all the tools you need, fully loaded into RAM (only way to go) takes up about 150MB or memory; even a multi-media pe with all the works uses maybe 2-300MB, hardly advanced technology! I build and test all my livexp's (RAM loaded) on a 512MB RAM 'older machine' just to make sure issues like you describe are avoided, so you need not panic over this any further (but I'm sure you will) wink.gif

Posted by: MedEvil Jan 4 2009, 12:34 AM

Amalux, would like to see your fully working LiveXP+Tools in a 150MB image. Sounds more like nativeEX_barebone+Tools to me. laugh.gif

But generally you plan on at least 200MB RAM for use as RAM, which is cutting it a bit close for the video players, but else should be sufficient.

Now imagine Dot.net get's installed into your setup and we're already more or less part the 750MB line.

No big deal today, where every new computer comes with 4GB and more of RAM.
But if one already plans to run ones PE only on machines like that, then why oh why all the hussle with PE building?

On a machine like that one can autoinstall a XP in less then 10minutes and everything works. Every hardware, every software that one chooses. No dependencies to watch out for, no scripts to write.

PE has one advantage and one advantage only. It can run straight of a CD, without the need to copy or install anything to any place and thus use the least amount of RAM possible.
Once this advantage is of no consequences, PE only has disadvantages! And thus i simply can not understand, why anyone, who plans to build a live system for a computer with more than enough RAM, would actually choose a PE of some kind! confused1.gif

cheers.gif

Posted by: amalux Jan 4 2009, 01:01 AM

QUOTE (MedEvil @ Jan 3 2009, 04:34 PM) *
Now imagine Dot.net get's installed into your setup and we're already more or less part the 750MB line.

If the LODR-pack scenario requires more than 512MB of RAM installed on the machine than, actually, I agree with you on this one. That wasn't part of my understanding and would change the dynamic completely. I simply don't know and will have to rely on others who know more until I can do some trials myself - I guess time will tell wink.gif

Posted by: sanbarrow Jan 4 2009, 01:16 AM

QUOTE
If the LODR-pack scenario requires more than 512MB of RAM installed on the machine


??? - it does not - what makes you think so ???

Posted by: amalux Jan 4 2009, 01:19 AM

QUOTE (sanbarrow @ Jan 3 2009, 05:16 PM) *
??? - it does not - what makes you think so ???

Like I said I don't know until I test but this is good news! thumbup.gif

Posted by: amalux Jan 4 2009, 07:48 AM

Having a bit of trouble with moa tut http://sanbarrow.com/phpBB2/viewtopic.php?t=1132; the following links are bad:
4. add drivers
http://downloads.littlbuger.info/index.php?dlid=827
- found this one
7. download latest moa-23*-plugin.zip
http://sanbarrow.com/moa23/files/moa-23005-plugin.zip


[attachment=6988:3props.JPG]

 

Posted by: sanbarrow Jan 4 2009, 11:53 AM

What do you want with that hundred years old plugins ???
Where do you find those very out-dated links ?
This is latest version ...

http://sanbarrow.com/moa24/files/moa24-setup-024.exe

Posted by: Lancelot Jan 4 2009, 11:58 AM

Galapo, Peter

I cant use wimpack.exe on builds for now, but it is better to put half of my idea (the other half will be load on demand) (all idea is at post 23 and post 26) in a simple script
can you check this:

http://lancelot.winbuilder.net/5F/1_Test_wim_Api%20FreeFSCapture53.rar

this is NOT a ready script, look two // MISSING - STAGE in script file

i hope it is more understandable now? what do you think ?


ps: message was first posted to wrong topic, sorry, now fixed smile.gif

Posted by: MedEvil Jan 4 2009, 02:02 PM

QUOTE (sanbarrow @ Jan 4 2009, 02:16 AM) *
??? - it does not - what makes you think so ???

Sanbarrow appearantly you're a wizard, you keep needing system resources while explaining, that you don't need while actually running. wink.gif
Can't wait to see the final result.

cheers.gif

Posted by: JonF Jan 4 2009, 02:04 PM

QUOTE (amalux @ Jan 3 2009, 06:50 PM) *
Yes! A fully working LiveXP with all the tools you need, fully loaded into RAM (only way to go) takes up about 150MB or memory;

Pah! I've booted BartPE on 128 MB machines once in a while, and need the facility to do so. Once I even booted BartPE on a 64 MB machine and did some useful work.

Posted by: MedEvil Jan 4 2009, 02:15 PM

Have now a NaughtyPE build which runs on 64MB with audio support and can play even video! showoff.gif

cheers.gif

Posted by: sanbarrow Jan 4 2009, 04:32 PM

QUOTE
Sanbarrow appearantly you're a wizard, you keep needing system resources while explaining, that you don't need while actually running.


Depending on the type of build and the cheatcode used at boot-time MOA-builds RAM-requirements vary between 96 Mb and 768 Mb.
There is no wizardry involved.

You might be shocked to see the 768 Mb figure - but that mode is only required for development.
As far as I know winbuilder-projects don't have a comparable mode as you must do all the development on a second building host.

Also the ram-requirements for the apps I use vary.
VirtualBox, Converter, Workstation, Dreamweaver and apps like that work on 256 Mb hosts.
For running dotnet2 apps like ViClient or FastSCP your box should have 512 Mb.

Only for stuff like developing dotnet apps or a new Workstation release you need more powerful systems.
I doubt that you can install 500 Mb apps on the fly with winbuilder-projects at all - so don't hold that high ram-requirements against me cool.gif

Posted by: amalux Jan 4 2009, 04:33 PM

QUOTE (sanbarrow @ Jan 4 2009, 03:53 AM) *
What do you want with that hundred years old plugins ???
Where do you find those very out-dated links ?
This is latest version ...

http://sanbarrow.com/moa24/files/moa24-setup-024.exe

QUOTE (amalux @ Jan 3 2009, 11:48 PM) *
Having a bit of trouble with moa tut http://sanbarrow.com/phpBB2/viewtopic.php?t=1132

If the tut is old, maybe it should be updated happy22.gif - Thanks for new link, is there new instructions or just run .exe and self contained - I'm heading to ntfs machine to try now...

Posted by: amalux Jan 4 2009, 04:36 PM

QUOTE (MedEvil @ Jan 4 2009, 06:15 AM) *
Have now a NaughtyPE build which runs on 64MB with audio support and can play even video! showoff.gif

cheers.gif

Congrats MedEvil, you've completely missed the point again laugh.gif

Posted by: sanbarrow Jan 4 2009, 04:39 PM

All MOA 2.3 stiff is out-dated.
Go to a 32bit machine with NTFS - run http://sanbarrow.com/moa24/files/moa24-setup-024.exe
Then copy the contents of ...pebuilder\bartpe\moahome\*.* to the root of a USB-disk or stick -
add a tag-file named "moa-is-at-home.tag" to the root of the disk/stick
and boot the CD with that stick/disk plugged in.

Then start adding apps of your choice ...

Start with a nice example - GIMP ...
Install it - drag an icon to the desktop - use it
Then reboot
click GIMP-icon on desktop - use it
Thats a nice example for a very simple LODR-pack - it doesn't even need a batch

If you want dotnet2 and all dotnet-VMware-apps build a MOA-max iso - boot it somewhere with cheatcode "remount"
(you will know what that means if you did the first steps)
download http://sanbarrow.com/moa24/esx-bandit/esx-tools-014.exe

get this additonal files and put them into R:\src - (you will know what that means if you did the first steps)
VMware-viclient.exe - build 3.5u2
WindowsServer2003-KB926139-v2-x86-ENU.exe
VMware-Vim4PS-1.0.0-113525.exe
VMware-vix-disklib-e.x.p-99191.i386.exe
VMware-VIRemoteCLI-3.5.0-104314.exe
VMware-converter-3.0.3-89816.exe
then run the esx-tools.exe

That may take 20 minutes and when its finished you can then use the complete dotnet stuff on next boot.
Once created the dotnet-package can be used with MOA-lite builds or higher.

edit: added sdome links

Posted by: psc Jan 4 2009, 04:41 PM

QUOTE (amalux @ Jan 4 2009, 05:36 PM) *
Congrats MedEvil, you've completely missed the point again laugh.gif

yahoo.gif
Peter innocent.gif ( cheers.gif )

Posted by: amalux Jan 4 2009, 08:07 PM

QUOTE (sanbarrow @ Jan 4 2009, 08:39 AM) *
All MOA 2.3 stiff is out-dated.
Go to a 32bit machine with NTFS - run the exe.
Then copy the contents of ...pebuilder\bartpe\moahome\*.* to the root of a USB-disk or stick -
add a tag-file named "moa-is-at-home.tag" to the root of the disk/stick
and boot the CD with that stick/disk plugged in.

Then start adding apps of your choice ...

Well, here are my thoughts so far fwiw...
Don't like being forced to run setup in VM, then told can't find VM directory confused1.gif

- directing to vm dir on my c didn't help - don't know what it wants here. I gave it a good dir to my vm install when asked during setup; if it was supposed to copy something to r:\vm it didn't happen.

MOA seemed hindered without vm 'host' - so moa only works mounted in vm?


- or is this what moa is? What is it supposed to look like? I feel really stupid but what the hell is it supposed to do? I don't understand any of the options, can't find anything about adding/installing LODR-packs or similar. There is, of course, a start menu with tools but not a toolset I'm particularly familiar with and I just feel I'm missing something. The booted setup is not running from ram at all! Did I miss something, this looks more like a typical 'run from CD' setup, not a bootsdi or whatever pebuilder's equiv is; I don't like pebuilder which is why I use WinBuilder so I don't know where the options in pebuilder are for running from RAM. This is pretty much where I left off the last time I tried MOA, sorry, I just don't get it. If I've missed the whole point, my apologies, I'm willing to learn but need better instructions than I've found so far rolleyes.gif

Posted by: MedEvil Jan 4 2009, 08:21 PM

The way i understood the MOA idea, and please someone correct me if i'm wrong, is this:
- A BartPE boots up from CD/DVD
- From that BartPE a VM is started (vmware to be exact)
- In the virtual machine there is an image mounted which holds the OS that is actually used.
- Guest OS boots up.
- Desktop presents itself, ready to use.


cheers.gif

Posted by: sanbarrow Jan 4 2009, 08:52 PM

Oh dear - seems like a I need to do a lot of explaining

MOA is a basic PE without any additional programs - it can be started with an explorer shell (default).
It has a pretty smart cheatcode prompt where you can redirect the user-space to various paths - like USB-disks, local disks , vmdks, truecryptcontainer, ramdisks and so on ...
It is build following the enough is beautiful approach.
Enough here is defined as :
be able to run all VMware apps - including dotnet stuff
be able to install everything else on the fly

Full stop. Thats it

MOA doesn't need to run VMs nor does it need to run in a VM.

Adding apps is a task for the enduser - as it is so easy in most of the cases MOA does not need any plugin-stuff to do this.


@ Amalux - the prompts for Workstation files is because the default in moa.ini is start_vmware=yes.
When start_vmware = yes MOA tries to find any Workstation available on the current host. If you show it a version it will be launched then.
If you don't want to fiddle with Workstation simple set
start_vmware=no

QUOTE
The booted setup is not running from ram at all!

check the setup-tool it has various ram-loading options.
For regular use take SHARK or LITE
For developement use take MAX or FAT.

You do NOT need to fiddle with pebuilder itself

.. and MOA-core is created by pebuilder because at the time it started there was only pebuilder - so far I haven't seen
a reason to change the building-tool as pebuilder is completely sufficient for the task

Posted by: amalux Jan 4 2009, 09:07 PM

QUOTE (sanbarrow @ Jan 4 2009, 12:52 PM) *
Oh dear - seems like a I need to do a lot of explaining

MOA is a basic PE without any additional programs - it can be started with an explorer shell (default).
It has a pretty smart cheatcode prompt where you can redirect the user-space to various paths - like USB-disks, local disks , vmdks, truecryptcontainer, ramdisks and so on ...
It is build following the enough is beautiful approach.
Enough here is defined as :
be able to run all VMware apps - including dotnet stuff
be able to install everything else on the fly

Full stop. Thats it

MOA doesn't need to run VMs nor does it need to run in a VM.

Adding apps is a task for the enduser - as it is so easy in most of the cases MOA does not need any plugin-stuff to do this.


@ Amalux - the prompts for Workstation files is because the default in moa.ini is start_vmware=yes.
When start_vmware = yes MOA tries to find any Workstation available on the current host. If you show it a version it will be launched then.
If you don't want to fiddle with Workstation simple set
start_vmware=no

You do take a lot for granted my friend, simple for you maybe. So, I did show it my ws host files and I still got prompt for vm after boot - are you saying start_vmware=no means moa won't try to load vm after boot? if so, fine but then I'll end up with what I already have, right? Basically, a run from CD (not RAM) project with a pre-determined tool set (not the tools I need), built from pebuilder which I don't like and adding additional tools/programs left up to user to figure out because it's so simple roll1.gif

Posted by: sanbarrow Jan 4 2009, 09:20 PM

Please read http://sanbarrow.com/how-to-add-ws-to-moa.html about how to prepare a Workstation directory.

About the apps - do what I already mentioned. Possibly with a ramloading build.

QUOTE
Then copy the contents of ...pebuilder\bartpe\moahome\*.* to the root of a USB-disk or stick -
add a tag-file named "moa-is-at-home.tag" to the root of the disk/stick
and boot the CD with that stick/disk plugged in.


Inject your LiveXP cd - drag the contents of your programs-dir to R:\programs.
Add startmenu entries by drag'n'drop
Add desktop-icons per drag'n'drop.
Use the apps.

Reboot

Find out which of YOUR apps don't work - good part of it already does.
Make a list of apps that don't work - only for those you need to create a batch.

Once you created a batch like the one for VirtualBox we already discussed you can automate loading it by putting a line like
start R:\programs\myapp\launch.cmd
into R:\bin\lastbatch.cmd.

If you want to load an app before network is up - put a line
into R:\bin\prenetwork-batch.cmd


Posted by: amalux Jan 4 2009, 09:30 PM

QUOTE (sanbarrow @ Jan 4 2009, 01:20 PM) *
Please read http://sanbarrow.com/how-to-add-ws-to-moa.html about how to prepare a Workstation directory.

About the apps - do what I already mentioned. Possibly with a ramloading build.



Inject your LiveXP cd - drag the contents of your programs-dir to R:\programs.
Add startmenu entries by drag'n'drop
Add desktop-icons per drag'n'drop.
Use the apps.

Reboot

Find out which of YOUR apps don't work - good part of it already does.
Make a list of apps that don't work - only for those you need to create a batch.

Thankyou for info, I'll research some more and try again... One question, is there any LODR-pack already setup that I could dl and take a look at, would help me understand how it's supposed to work. I found a possible dl link but requires login/pw. Thanks Ulli smile.gif

Posted by: sanbarrow Jan 4 2009, 09:47 PM

Nope - there is no list of already existing LODR-packs available - never needed one so far.

Start with the virtualbox-batch we discussed - thats a beautiful example.

I just made up the term LODR-pack so that we have a term to discuss rolleyes.gif

Basically I hope for know-hox exchange - which is very easy when folks use simple batch-files.
Look at the virtualbox-example ... someone finds out how to use app XY on top of PE without needing any app-scripts or plugins or core-rebuilds.
He then puts that in a batch - so that every one else can easily anaylize a working startup routine for app XY on PE.

I don;t care what you do with that - I just hope that I could use some of your knowhow too. cool.gif

... and I am pretty sure you will like this easy way too ...


Posted by: Galapo Jan 4 2009, 10:25 PM

QUOTE (Lancelot @ Jan 4 2009, 09:58 PM) *
I cant use wimpack.exe on builds for now, but it is better to put half of my idea (the other half will be load on demand) (all idea is at post 23 and post 26) in a simple script
can you check this:

Here's basic syntax for wimpack.exe:

wimpack.exe targetdir folder_in_targetdir_to_pack cmd_file system_exclude_file_list

Eg: wimpack.exe c:\target program c:\target\cmd.cmd none

Note: in targetdir a folder 'i386' must exist, to which the outputted WIM will be generated. cmd_file is necessary in this case only to avoid program error.

Regards,
Galapo.


Posted by: MedEvil Jan 4 2009, 11:14 PM

QUOTE (sanbarrow @ Jan 4 2009, 09:52 PM) *
be able to run all VMware apps

What is a VMWare app, if it's not a app running in VMWare?

cheers.gif

Posted by: rawral Jan 4 2009, 11:38 PM

QUOTE (MedEvil @ Jan 4 2009, 11:14 PM) *
What is a VMWare app, if it's not a app running in VMWare?

cheers.gif



my guess is 'VMware disk mount utility' or similar things mellow.gif

its possible even probable im way out tho

LODR-packs jump.gif ( it sounds like a good thing )





Posted by: amalux Jan 5 2009, 12:12 AM

QUOTE (MedEvil @ Jan 3 2009, 04:34 PM) *
Amalux, would like to see your fully working LiveXP+Tools in a 150MB image. Sounds more like nativeEX_barebone+Tools to me. laugh.gif


even with a full compliment of network and mass storage drivers, plus some free space to play with; this build creates an image ~147MB fully loaded to RAM. There's nothing 'outside' of the RAM to access, you can remove the CD as soon as you boot to desktop - this leaves the CD drive open for other things like burning discs or accessing other data etc. Tested on machines with only 256MB RAM and all programs accessed simultaneously without issue. Programs work exactly as they would in a full Windows, i.e. every program opens 'instantly', no delay for accessing from CD which drives me crazy.

QUOTE (MedEvil @ Jan 3 2009, 04:34 PM) *
On a machine like that [4GB and more of RAM] one can autoinstall a XP in less then 10minutes and everything works. Every hardware, every software that one chooses. No dependencies to watch out for, no scripts to write.

PE has one advantage and one advantage only. It can run straight of a CD, without the need to copy or install anything to any place and thus use the least amount of RAM possible.
Once this advantage is of no consequences, PE only has disadvantages! And thus i simply can not understand, why anyone, who plans to build a live system for a computer with more than enough RAM, would actually choose a PE of some kind! confused1.gif

cheers.gif

First, 4GB RAM? How about 512MB, more realistic to this discussion; yeah, you could autoinstall a full XP in 10 min. - so what? How long will it take you install, register and configure all the programs in the list above, an hour or more? While the client is waiting for you to do some repair work? PE has many advantages in a bare metal/repair/restore setting and none of them relate to running from CD, in fact, running from CD is the one serious dis-advantage if you are unlucky enough to get stuck with a non-bootsdi PE! Very rarely do I have to resort to a PE run from CD in the case of damaged RAM etc. and it kills me, the constant delays everytime I access a program or file, I've said it before; if the only PE I could use were run from CD, I wouldn't bother with it.

Personally, I can't see using PE as a replacement for a full OS but in the cases I encounter daily where booting normally is hindered or impossible due to OS corruption, virus damage etc. PE run from RAM is a beautiful thing to behold. I think that you and I use PE for far different reasons which might help to explain some of your confusion here wink.gif

Posted by: sanbarrow Jan 5 2009, 12:25 AM

QUOTE
What is a VMWare app, if it's not a app running in VMWare?


Things like
ViClient (needs dotnet) ,
ViToolKit (needs Powershell) ,
RemoteCli (needs Active-Perl),
Tripwire-ConfigCheck (needs JAVA)
.. and other VMware related apps like VEEAM Fastscp or TRILEAD VM-explorer which mostly need dotnet2.

All the apps mentioned above are handled by a single script called esx-tools.exe.
That handles the one-time setup and the loading of this apps at any time after boot later in regular use.

Thats the most advanced LODR-pack I have at the moment - it runs on PEs with
at least 20 Mb free space in %systemroot% and writeable R:\home and R:\programs.
It does NOT require that you rebuild the out-of-the-box MOA-core in any way.
No problem in MOA - don;t know about LiveXP or other winbuilders CDs

QUOTE
Personally, I can't see using PE as a replacement for a full OS


On my notebook I have MOA in boot.ini along with a regular 2k3
- most of the times I use MOA as it runs Explorer and VMware Workstation faster than the regular install.

Posted by: MedEvil Jan 5 2009, 01:32 AM

So a VMWare app is an app which is/can be used for things related to VMWare?

Sanbarrow would you please tell me again the use of MOA, as i seem to remember wrong and can't really see the purpose of MOA in your explainations.

cheers.gif

Posted by: sanbarrow Jan 5 2009, 01:45 AM

MedEvil - I have a hunch that you are not part of the expected target-audience cool.gif

purpose of MOA: proof that traditional harddisk installed Operating systems are out-dated.

Posted by: MedEvil Jan 5 2009, 01:46 AM

QUOTE (amalux @ Jan 5 2009, 01:12 AM) *
even with a full compliment of network and mass storage drivers, plus some free space to play with; this build creates an image ~147MB fully loaded to RAM. There's nothing 'outside' of the RAM to access, you can remove the CD as soon as you boot to desktop - this leaves the CD drive open for other things like burning discs or accessing other data etc. Tested on machines with only 256MB RAM and all programs accessed simultaneously without issue.

Like i said joking, not a LiveXP - but a nativeEx_barebone with some tools. wink.gif

Amalux, you may use LiveXP project as base for your build, but what you end up with in the end has more in common with nativeEx_barebone, than with LiveXP and as such, i of course believe all your claims.


cheers.gif

Posted by: amalux Jan 5 2009, 02:14 AM

QUOTE (MedEvil @ Jan 4 2009, 05:46 PM) *
Like i said joking, not a LiveXP - but a nativeEx_barebone with some tools. wink.gif

Amalux, you may use LiveXP project as base for your build, but what you end up with in the end has more in common with nativeEx_barebone, than with LiveXP and as such, i of course believe all your claims.


cheers.gif


...if that's what nativeEx_barebone looks like fully RAM loaded then yeah, I guess there's no diff between LiveXP and nativeEx wink.gif

Posted by: MedEvil Jan 5 2009, 10:18 AM

QUOTE (amalux @ Jan 5 2009, 03:14 AM) *
...if that's what nativeEx_barebone looks like fully RAM loaded then yeah, I guess there's no diff between LiveXP and nativeEx wink.gif

Actually it does. Though it's hard to tell with the apps in the way. laugh.gif

NativeEx_barebone is the basis for all our XP based PE.
LiveXP, just like NaughtyPE, builds up on it and when you scale those two projects down, you will arrive again at nativeEx_barebone.

cheers.gif

Posted by: amalux Jan 5 2009, 07:48 PM

MedEvil, cheers.gif

sanbarrow,

I'm still having problem getting my vm recognised in MOA; please clarify the following instuction:

QUOTE
Finally go to the directory C:\ws650 and copy
vmusb.inf to oem5.inf
vmnetbridge.inf to oem6.inf
vmnetadapter.inf to oem7.inf

...where are these files and where are they being copied to? Thanks wink.gif

Posted by: sanbarrow Jan 5 2009, 09:19 PM

Hi
look in the original installation-directory. There you will find those 3 inf-files.
Just rename them as mentioned.

As no file for Workstation is added to the system-core - the directory for each version must contain all the drivers and inf-files.

if you want to use WS 6.5.0 check your directory against this list:
http://sanbarrow.com/phpBB2/viewtopic.php?t=1364
those must exist in the directory - everything else is optional.

By the way - can we discuss this specific questions in the http://www.boot-land.net/forums/index.php?showtopic=5470&st=10&start=10 ?
Preparing Workstation has not much to do with this topic ...

Thanks

Posted by: cdob Jan 5 2009, 09:46 PM

Short general notice:
Don't use oem*.inf file names.
That's a broken approach, this may cause conflicts.
Adjust your environment, use the original file names instead.

Posted by: amalux Jan 5 2009, 09:52 PM

QUOTE (sanbarrow @ Jan 5 2009, 01:19 PM) *
Hi
look in the original installation-directory. There you will find those 3 inf-files.
Just rename them as mentioned.

As no file for Workstation is added to the system-core - the directory for each version must contain all the drivers and inf-files.

if you want to use WS 6.5.0 check your directory against this list:
http://sanbarrow.com/phpBB2/viewtopic.php?t=1364
those must exist in the directory - everything else is optional.

By the way - can we discuss this specific questions in the http://www.boot-land.net/forums/index.php?showtopic=5470&st=10&start=10 ?
Preparing Workstation has not much to do with this topic ...

Thanks

OK, will post next question on this (if there is one) there, thanks. I see part of the problem already on my end, I was using ws651 with moa24.024; I've just updated to .029 and will try again wink.gif

Posted by: amalux Jan 5 2009, 10:05 PM

QUOTE (cdob @ Jan 5 2009, 01:46 PM) *
Short general notice:
Don't use oem*.inf file names.
That's a broken approach, this may cause conflicts.
Adjust your environment, use the original file names instead.

Sorry, just saw this; so leave the .inf's alone, got it. What about the vmrun.exe, still need to be from an older version from 6.0? (hope not, don't have it anymore)

(I know I said I wouldn't post another question here but just responding to cdob's post rolleyes.gif)

Posted by: sanbarrow Jan 6 2009, 09:53 AM

QUOTE (cdob @ Jan 5 2009, 09:46 PM) *
Short general notice:
Don't use oem*.inf file names.
That's a broken approach, this may cause conflicts.
Adjust your environment, use the original file names instead.


Thats the way Windows does it itself - isn't it ?
It reads the original inf and copies it as oem*.inf to inf-dir.
Whats the problem with that ?
I would agree of course if we were talking about plugins or app-scripts - but in MOA I don't use that way.

Posted by: cdob Jan 6 2009, 11:16 AM

@sanbarrow
I wrote a general notice, not to MOA.

As long as there is one windows used, there are no conflicts.
Windows themself handle this correct.
As long as one person creates all solution, there are no conflicts.

However there is a new approach presented to a community:
Different user may create different packs.
Different packs may contain different oem1.inf.
As long as different packs use own directories, there are no conflicts.

If different packs copy inf files to inf directory, there are conflicts.

Maybe no pack does copy file to inf directory today.
But packs may copy files in future.

I suggest: avoid possible conflicts today.

Posted by: sanbarrow Jan 6 2009, 12:28 PM

Ok - I see your point.
You are right - I'lll follow your suggestion for future projects.

QUOTE
Maybe no pack does copy file to inf directory today.
But packs may copy files in future.


I already do that nowadays - I'll review it and see if it still works with the original names

Posted by: Lancelot Jan 6 2009, 03:38 PM

QUOTE (cdob @ Jan 5 2009, 11:46 PM) *
Short general notice:
Don't use oem*.inf file names.
That's a broken approach, this may cause conflicts.
Adjust your environment, use the original file names instead.


Thank you cdob , it is a nice advice which immediately i begin to use

Posted by: sanbarrow Jan 7 2009, 11:39 PM

Some additional notes ...

Using LODR-packed apps becomes really convenient if your Core-system also has this features:

latebatch.cmd = a plain batch outside of the Core which can be used to automate loading packages
prenetwork-batch.cmd = a plain batch outside of the Core which can be used to automate loading packages that must be started before network is established

in MOA I do that like this:
The Core includes a directory named "bin" - if MOA is booted in CD-only mode this directory will be junctioned to R:\bin.
In the more convenient CD+USB mode this directory will be used from USB- in case it exists.
This makes it very very easy to adjust the two mentioned cmds without needing to rebuild the Core.
In MOA the directory R:\bin is always included in the path.
In a way I use this directory like Linux does use the directory for the init-scripts.
AFAIK winbuilder projects use RunOnceEx keys to handle the bootup.
Maybe you can add routines like this

if exist R:\bin\prenetwork-batch.cmd start /wait R:\bin\prenetwork-batch.cmd
and
if exist R:\bin\lastbatch.cmd start /wait R:\bin\lastbatch.cmd

A default search-path for LODR-packs ...
In MOA I use a directory named _sfx_
At boot-time the system scans all disks and CDs and if a directory named _sfx_ is present it will be automatically junctioned to R:\_sfx_.
This way I can automate loading of packages even if I don;t know the path


Another important aspect ... I always use %programsdir% on writeable NTFS - you should do that too.

By the way - if you start to use this approach your app-collection will grow very fast.
Mine is about 10 Gb - about 5Gb of them for different VMware Workstation versions

cheers.gif

Ulli

Posted by: Galapo Jan 7 2009, 11:44 PM

QUOTE (sanbarrow @ Jan 8 2009, 10:39 AM) *
Another important aspect ... I always use %programsdir% on writeable NTFS - you should do that too.

Did you mean %programfiles%, or is %programsdir% a defined variable in your project?

Thanks,
Galapo.

Posted by: sanbarrow Jan 7 2009, 11:52 PM

I mean the regular Windows-systemvariable.

The reason is just to make sure that if you install an app on the fly it can install with defaults.
If I install java runtime on the fly it installs to R:\programs\java in MOA.
R:\programs is always NTFS - so if I want to install Java but don't have enough free space in R: - I simply junction R:\programs\java to where ever and then install Java silently following defaults.

In case you have %programfiles% = X:\programs and assume that X:\programs is on readonly CD you can't do that

Posted by: Galapo Jan 8 2009, 12:00 AM

Understood.

In order to do this in a nativeEx-based project, FBWF or BootSDI is needed. In both cases, files are necessary which cannot be provided with a WinBuilder download. This means that a default build does not have this possibility as the supply of these files is optional for the user and it cannot be predicated if the user will supply them.

How to you accomplish this in your project?

Regards,
Galapo.

Posted by: sanbarrow Jan 8 2009, 12:07 AM

QUOTE
How to you accomplish this in your project?



For a ramloading build based on 2k3 you don't need FBWF-files.

I rarely have need for FBWF in MOA.
If I boot on a 128 MB machine that can't boot USB - I use a CD to boot and redirect ramdisk to USB.
On such low RAM hosts most of the times you do not need any dotnet or Workstation stuff that needs free space in X:\i386.

On more powerful host I use ramloading builds and don't need FBWF at all.

QUOTE
In order to do this in a nativeEx-based project, FBWF or BootSDI is needed.


Really ? - you use NTFS ramdisk - don't you ?
Move %programfiles% to %ramdrv%\programs and junction back to X:\programs ...

Little bit around the corner but once done you have writeable programs

By the way - thats half the way to a clever cheatcode prompt tongue.gif

Posted by: Galapo Jan 8 2009, 12:13 AM

I personally prefer RAM-loading approach also.

But nativeEx-based projects are meant to be able to be built from XP source as well as 2k3 source.

Maybe we could take up this %programsdir% variable and define it in addition to %programfiles%. In this way, %programsdir% could point to, say, '%temp%\Programs' in a project where %programfiles% is not writable but in the case where it is %programsdir% could point to %programfiles%. Each installation routine would need to make use of %programsdir%.

Regards,
Galapo.

Posted by: sanbarrow Jan 10 2009, 01:26 AM

We need a
Compatibilty classification.

For a start I would suggest something like this - you will need to add classes for winbuilder

default 2000 pro
default 2000 server
default XP
default 2003
default Vista
default 2008
default windows 7
default winpe1
default winpe2
default winpe3
default pebuilder
default ubcd4win XP
default ubcd4win 2003
default MOA

... add winbuilder types as needed


Suggestions for LODR-pack creators ...

Your app can be as large as you want - just make sure that you avoid any file-copies - MINIMAL FILE-actions
It doesn't matter how much registry you have to patch - just make sure you do no harm.
It also doesn't matter how you install drivers or add services - just make sure you do it AS FAST AS POSSIBLE.
Compare yourself:
Standard Installation of Workstation 6.5 on PE (MOA) takes about 15 minutes and moves 1.5 Gb of files.
A LODR-packed speed-install of Workstation 6.5 on PE takes about 5 seconds and moves 500kb of files.
A LODR-packed speed-install of dotnet2 on PE takes about 4 seconds and moves 5 Mb of files.

Please post your LODR-pack as simple as possible - in ideal case it is a filelist plus a batch.
Provide clear instructions on how to automate it and about the time at which it should be loaded.

You have a LODR-pack that only was tested on 2000 pro in Kisuaheli ? - fine post it and claim that it needs 2000 on Kisuaheli




Contents of a LODR-pack:

filelist: a explained filelist and instructions on how to grab this files
loader: a batch or a compiled loader (installrite, autoit or whatever) that speed-installs the program
help-text: a detailed explanation on the requirements that this package has - like what additional runtimes are required and so on ...
index.html : a html info so that we can automate adding your pack to an inventory


Loader: the batch or exe should do minimal tests if it is in the expected environment - then it should launch the app with minimal action - a cleanup is NOT required.
The loader should allow silent execution.


LODR-pack versus PortableApp

Thats similar - but ... - portable apps are designed to do no harm on regular Windows - thats a lot of work.
Doing no harm on PE is much easier as we do not need to clean up after use.

LODR-pack versus Unattended Installation

Thats very similar - we just can skip most of the checks that normal install-routines usually do - also in LODR-packs you have much less file-actions.


---------------------------------------------------------------------------------------------------------

Well - I do it like that anyway - it comes naturally once you have a good core ...

Posted by: sanbarrow Jan 14 2009, 07:31 PM

... another advantage of LODR-packs ...

drastically reduced development time ...
Just had a nice example at 911-forum - see
http://www.911cd.net/forums//index.php?showtopic=22533

I needed one afternoon to LODR-pack an app I had never seen before.
ShadowProtectServer is a relatively complex app which installs several services and needs VSS.

Once the LODR-pack is created you just put it on to an USB-disk or stick and then you use it when it comes handy.

Posted by: sanbarrow Jan 20 2009, 09:01 PM

When a new user builds his first standard out-of-the-box MOA-core 2.4.024 and boots
it along with my USB-disk plugged in he will get this startmenu



None of the apps in Load On Demand require any preparation or advanced builds of the core-system.

We just need one smart guy who knows its way through app XY - he writes a clever batch and gives easy instructions on how to grab the files.

Then a new user can grab that batch from lodrpack.boot-land.net - install app XY once on the fly and keep the files ....thats it.

By the way - the same core build also boots into full explorer shell on 68 Mb host

http://sanbarrow.com/moa24/screenshots/moa24029-on68mb-host.png

Posted by: joakim Jan 21 2009, 03:35 PM

One suggestion to the disagreement about universal LODR packages among all the projects.

Obviously something must be hardcoded, and obviously something must be patched to handle different platforms with different structures.

May I suggest one possible way to replicate a universal package approach (a sort of a Midway..yes):

Place everything in package and keep it there. Do not copy any files from package dir. The only hardcoded path must be directory structure (but do not necessarily have to) to package files. Then prepatch every script and registry patch according to which drive letter they are on, before executed. Ie load an inputbox that asks for the driveletter where package resides. This way I believe we can resemble the most universal package to be used among platforms. By keeping all files in package dir, there is also no requirements in regards to where you have writable access (b:\, r:\, x:\, rramdisk, fbwf, ramload, etc), besides having your package on writable storage, that by defintion would be the only meaningful place to have it.

The method would require more work before its ready (than the initially proposed LODR package), ie the registry patches must be prepatched by hand (to correct for different directories after captured install (system32\drivers, i386\inf, c:\program files, c:\program files\common files\, r:\programs.. etc)) before the package is ready and can be prepatched by the loader when used. By doing this, the only patch required is to correct for different driveletter. Btw, the registry patches would require 2 different
patching methods, one to replace characters and one to replace hex values. That's not a problem, I have one for my kind of universal vmware workstation 6.5.1 package to-be-released. Scripts are even easier to patch.

This "one directory with all" could be assigned a variable in the topdirectory like already suggusted in earlier replies.

Advantage:
- When package is finished, the only adjustment needed is to adjust for different driveletters (as directory structure is now hardcoded). That means 3 keyboard buttons pressed by the user, ie m:\. It also limits the complexity of it and the work by the developer prior to finish the package.
- Are not totally dependant on wim, although recommended, as it also can be saved separately according to the directory structure already suggested (but will need much more space).
- Do not require much ram.
- Are not dependant on ntfs (which means junctions-free LODR packages (it's a give and take)).
- With this approach it will be easier to share, adapt and combine the differings among xp, 2k3 and vista, and in that way replicate a truly universal way of packaging LODR apps for preinstallation environments.
- Save lots of space in your core build.
- Reduced boot-time.
- By prepatching beforhand, the rest of the patching can easily be automated in scripts, and really is a speedload.
- The package is completely separated from the system-core.

Requirements:
- Access to the medium in which the package is stored.
- Have the loader check its environment and choose patch/script according to the OS running.

Helpful:
Share scripts that collects the files from the system it was installed on (real, virtual, whatever..). Include helpfiles.

Hurdles:
Language differences.

Last note. This hassle is only necessary when using somewhat complex applications that installs services and drivers that require registry entries. For simple apps simply just put the files into the package dir.

I agree with Ulli about regsvr32. The build would suffer from lack of adaptability if such a small part of the system, yet so powerful and essential, should be excluded just to save some kb. Otherwise, if a minimalistic approach is preferred, place regsvr32 in the packagedir too.

The concept of the LODR package is great! It's a shame that no agreement has been settled upon the structure and format of it (even its existence).

Someone mentioned fair for moving towards the stoneage. I can't see how it relates to that.

Joakim

Posted by: sanbarrow Jan 22 2009, 05:07 PM

QUOTE
It's a shame that no agreement has been settled upon the structure and format of it (even its existence).


I am not surprised at all.
Using LODR-packed apps comes natural as soon as you start to separate system core from userland cleanly.
Winbuilder projects don't do this yet.

Ulli

Posted by: Galapo Jan 22 2009, 08:27 PM

QUOTE (sanbarrow @ Jan 23 2009, 03:07 AM) *
Using LODR-packed apps comes natural as soon as you start to separate system core from userland cleanly.
Winbuilder projects don't do this yet.

This separation does not happen at the individual script level, but it does happen if one uses WimPack. There is a very clear separation there of "system" (ie, basically boot essential stuff) and "non-system". Even MOA has much stuff under \system32\ which though is technically "system" are not needed for boot and so can be relocated.

Regards,
Galapo.

Posted by: joakim Jan 22 2009, 10:20 PM

QUOTE
This separation does not happen at the individual script level, but it does happen if one uses WimPack. There is a very clear separation there of "system" (ie, basically boot essential stuff) and "non-system". Even MOA has much stuff under \system32\ which though is technically "system" are not needed for boot and so can be relocated.


It's true, but the focus need to be kept towards the concept of LODR packaging and how it can best be constructed architectually and thereafter applied to a running livecd, project-independantly.

The way I see it, there will be more work required to make such packages, but the gains are also equally higher since the requirements of the running system become less (filesystem, writeable area, memory, project used, bootmethod, wim-support, etc.)

Universal packages should be the way to go. As such packages optimally will require developers across projects to cooperate in some kind of way (just OS relevant), there will also in the future be growing needs for a "port collection" kind of system to keep the packages categorized in a "library". As that is the second step, we should rather look at step 1, and brainstorm around that.

Does anybody have any suggestions or constructive criticism on my midway proposition?

I am almost finished with the vmware workstation 6.5.1, hopefully this weekend. I thought a good candidate would be a complex candidate, to prove its flexibility.

Joakim

Posted by: Galapo Jan 22 2009, 10:28 PM

QUOTE (joakim @ Jan 23 2009, 08:20 AM) *
I am almost finished with the vmware workstation 6.5.1, hopefully this weekend. I thought a good candidate would be a complex candidate, to prove its flexibility.

Yes, excellent idea. When it's done, I'd like to look at it and see how we might be able to get this LODR concept working in LiveXP, without such hardcoded MOA things like r:\.

Thanks,
Galapo.

Posted by: sanbarrow Jan 22 2009, 10:39 PM

QUOTE
... without such hardcoded MOA things like r:\.


Whats the problem with that - or what is the equivalent in LiveXP ?

QUOTE
Even MOA has much stuff under \system32\ which though is technically "system" are not needed for boot and so can be relocated.


Yes - the idea behind that is to have a core-system that is able to give the user a working system even if the core is used standalone.

At cheatcode time the user then can decide wether he wants to use a prepared userspace and where this writeable space is located.
As far as I know LiveXP offers no choice - you must decide this at build-time.


Posted by: Galapo Jan 22 2009, 10:48 PM

QUOTE (sanbarrow @ Jan 23 2009, 08:39 AM) *
what is the equivalent in LiveXP ?

Currently nothing.

I guess because with WinBuilder we've worked so hard to not have hardcoded paths in anything, that I'm reluctant to move to a hardcoded r:\. As it is, with LiveXP r:\ could in theory well be a virtual CD drive the user has selected for use at boot.

Regards,
Galapo.

Posted by: sanbarrow Jan 22 2009, 11:01 PM

Oops - we crossposted ...

Galapo - you must have an equivalent. Every Windows has it.

Don't you usually use B:\home + X:\programs ?

Posted by: Galapo Jan 22 2009, 11:06 PM

There's the variables %temp% and %programfiles%. %temp% can be a whole number of things, and %programfiles% is dependent upon source and/or user override.

Regards,
Galapo.

Posted by: Galapo Jan 22 2009, 11:10 PM

QUOTE (sanbarrow @ Jan 23 2009, 08:39 AM) *
Yes - the idea behind that is to have a core-system that is able to give the user a working system even if the core is used standalone.
Yes, so the concept of "core-system" is different between these two projects.

QUOTE
As far as I know LiveXP offers no choice - you must decide this at build-time.
That's correct.

Regards,
Galapo

Posted by: sanbarrow Jan 22 2009, 11:10 PM

QUOTE
There's the variables %temp% and %programfiles%. %temp% can be a whole number of things, and %programfiles% is dependent upon source and/or user override.


I also have those variables - Windows needs them.
In MOA they are all defined to directories under R: - like R:\temp and R:\programs.

That makes it very very easy to relocate all this in a single operation.
I just have to decide after boot what I mount as R:\
Super simple

Posted by: Galapo Jan 22 2009, 11:12 PM

QUOTE (sanbarrow @ Jan 23 2009, 09:10 AM) *
I also have those variables - Windows needs them.

Yes, so what I'm saying is that these LODR-apps need to make use of variables such as %temp% or %programfiles% in order to function in project without r:\. Or am I missing something?

Thanks,
Galapo.

Posted by: sanbarrow Jan 22 2009, 11:14 PM

No - we should use the same variables that are used by regular Windows.

Posted by: Galapo Jan 22 2009, 11:19 PM

OK, I guess I need to see some actual LODR-app code to completely understand what happens and whether it is compatible in its current for for LiveXP. joakim pack when it comes will make for a good comparison too.

Regards,
Galapo.

Posted by: sanbarrow Jan 22 2009, 11:30 PM

Here is a simple example we already looked at - just removed the R:\ stuff

This speed-installs VirtualBox 2.1 - the script assumes you have the files already in place -
if not mount a wim first or create a junction to the path where you have the VirtualBox install directory.

You can grab the files easily by taking the install-directory from somewhere you have instealled it already.

CODE
@echo off

if not exist %programfiles%\virtualbox\Virtualbox.exe exit

regsvr32 /s %programfiles%\virtualbox\VBoxC.dll
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFltNotify.dll %systemroot%\system32\VBoxNetFltNotify.dll
copy %programfiles%\virtualbox\drivers\network\netflt\miniport\VBoxNetFlt_m.inf %systemroot%\inf\VBoxNetFlt_m.inf
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.inf %systemroot%\inf\VBoxNetFlt.inf
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.sys %systemroot%\system32\drivers\VBoxNetFlt.sys
snetcfg -v -l %systemroot%\inf\VBoxNetFlt.inf -c s -i sun_VBoxNetFlt
snetcfg -v -l %systemroot%\inf\VBoxNetFlt_m.inf -c s -i sun_VBoxNetFltmp
regsvr32 /s VBoxNetFltNotify.dll
drv_ctl --inst-nostart VBoxDrv %programfiles%\virtualbox\drivers\VBoxDrv\VBoxDrv.sys
drv_ctl --inst-nostart VBoxUSB %programfiles%\virtualbox\drivers\USB\device\VBoxUSB.sys
drv_ctl --inst-nostart VBoxUSBMon %programfiles%\virtualbox\drivers\USB\filter\VBoxUSBMon.sys
net start VBoxNetFlt
net start VBoxDrv
net start VBoxUSBMon
start %programfiles%\virtualbox\VBoxSVC.exe
start %programfiles%\virtualbox\Virtualbox.exe
exit

Posted by: Galapo Jan 22 2009, 11:35 PM

Why %programfiles% rather than say %CD%?

Thanks,
Galapo.

Posted by: sanbarrow Jan 22 2009, 11:37 PM

QUOTE (Galapo @ Jan 23 2009, 12:35 AM) *
Why %programfiles% rather than say %CD%?


%CD% ?

CD ? - why - what if I have no CD ?

I prefer to use apps from the path they would install to themselves

Posted by: Galapo Jan 22 2009, 11:41 PM

I meant why can't the batch call from its location -- %CD% being Current Directory?

Posted by: Galapo Jan 22 2009, 11:49 PM

Why couldn't this

CODE
if not exist %programsdir%\virtualbox\Virtualbox.exe md %programsdir%\virtualbox
if not exist %programsdir%\virtualbox\Virtualbox.exe junction virtualbox %programsdir%\virtualbox
if not exist %programsdir%\virtualbox\Virtualbox.exe imagex /mount %sfxdir%\virtualbox21.wim 1 %programsdir%\virtualbox
if not exist %programsdir%\virtualbox\Virtualbox.exe exit

be this
CODE
if not exist %CD%\virtualbox\Virtualbox.exe md %CD%\virtualbox
if not exist %CD%\virtualbox\Virtualbox.exe junction virtualbox %CD%\virtualbox
if not exist %CD%\virtualbox\Virtualbox.exe imagex /mount %CD%\virtualbox21.wim 1 %CD%\virtualbox
if not exist %CD%\virtualbox\Virtualbox.exe exit

Posted by: sanbarrow Jan 22 2009, 11:54 PM

Ah - I see.

Maybe thats a matter of taste ...
I just found it to be easier if you first junction the app to its default path - or mount a wim to the default path - or assume it is already there.
That is a one-liner in a batch.
For a batch noob like me that makes things much easier smile.gif

The full batch for VirtualBox I use also has this lines - they are unused if the program is already in place.

CODE
if not exist %programfiles%\virtualbox\Virtualbox.exe md %programfiles%\virtualbox
if not exist %programfiles%\virtualbox\Virtualbox.exe junction virtualbox %programfiles%\virtualbox
if not exist %programfiles%\virtualbox\Virtualbox.exe imagex /mount r:\_sfx_\virtualbox21.wim 1 %programfiles%\virtualbox




Posted by: sanbarrow Jan 22 2009, 11:58 PM

Oh dear - we crossposted again laugh.gif

Galapo - where is the advantage of using %CD% ?

If you use a fixed path you can create startmenu entries by drag 'n' drop - and they will work next time as well.

Posted by: Lancelot Jan 23 2009, 12:02 AM

I am busy with other things and away for a while from this topic, here is an idea i want to share:

CODE
if not exist %programfiles%\virtualbox\Virtualbox.exe goto notexista
exit
:notexista
if exist %programfiles%\virtualbox\virtualbox21.wim goto wimexist
exit
:wimexist
md %ramdrv%\%programfilesname%\virtualbox
imagex /mount %programfiles%\virtualbox\virtualbox21.wim 1 %ramdrv%\%programfilesname%\virtualbox
exit



edit: exit added to code

Posted by: Galapo Jan 23 2009, 12:03 AM

OK, I understand. I'd be happy with the following.

CODE
if not exist %programfiles%\virtualbox\Virtualbox.exe md %programfiles%\virtualbox
if not exist %programfiles%\virtualbox\Virtualbox.exe junction %CD%\virtualbox %programfiles%\virtualbox
if not exist %programfiles%\virtualbox\Virtualbox.exe imagex /mount %CD%\virtualbox21.wim 1 %programfiles%\virtualbox
if not exist %programfiles%\virtualbox\Virtualbox.exe exit
...

Posted by: sanbarrow Jan 23 2009, 12:19 AM

Thats fine with me - I didn;t knew that %CD% can be used in a batch.

Lancelot - you add two variables %ramdrv% and %programfilename% without any benefit I can see.
Care to explain ?

I do not know what the variable %ramdrv% is good for - I prefer not to use a ramdrive at all

Posted by: Galapo Jan 23 2009, 12:24 AM

OK, good. This way necessary WIM image is located in same place at batch location, so no problem with different location for our various projects. Program loads to %programfiles%, so again no problem with whatever that variable expands as in our different projects.

Regards,
Galapo.

Posted by: sanbarrow Jan 23 2009, 12:27 AM

Galapo - I have a default search path for wims and vmdks. After boot I scan the environment and create a junction to R:\_sfx_.
Do you have something similar ? - its very useful

Posted by: Galapo Jan 23 2009, 12:37 AM

QUOTE (sanbarrow @ Jan 23 2009, 10:27 AM) *
Galapo - I have a default search path for wims and vmdks. After boot I scan the environment and create a junction to R:\_sfx_.
Do you have something similar ? - its very useful

No, but we could agree on one of the following (or something else, if you can think of something):

a) LODR WIMs/VMDK location will be set at %temp%\sfx
CODE
if not exist %programfiles%\virtualbox\Virtualbox.exe imagex /mount %temp%\sfx\virtualbox21.wim 1 %programfiles%\virtualbox


b) LODR WIMs/VMDK location will be set at %programfiles%\sfx
CODE
if not exist %programfiles%\virtualbox\Virtualbox.exe imagex /mount %programfiles%\sfx\virtualbox21.wim 1 %programfiles%\virtualbox


c) LODR WIMs/VMDK location will be set to %sfx% environment variable
CODE
if not exist %programfiles%\virtualbox\Virtualbox.exe imagex /mount %sfx%\virtualbox21.wim 1 %programfiles%\virtualbox


Thoughts?

Regards,
Galapo.

Posted by: Lancelot Jan 23 2009, 12:42 AM

my vote is for B )
but with more unique folder name (sfx too regular) as an example like this:
%programfiles%\_sfx_\virtualbox21.wim
or maybe this
%programfiles%\wims_sfx\virtualbox21.wim
or ......

Posted by: Galapo Jan 23 2009, 12:45 AM

My vote is for c). Nothing is hardcoded into the batch script at all then apart from the assumed %sfx% variable.

Posted by: Lancelot Jan 23 2009, 12:47 AM

i agree with c) too as long as %sfx% variable have a unique folder name smile.gif

Posted by: Galapo Jan 23 2009, 12:50 AM

Well, it can be whatever the project decides and whatever does the setting of the variable.

Posted by: sanbarrow Jan 23 2009, 12:54 AM

I vote for C

In MOA I already have %sfxdir% defined.

Option A to have it under %temp% is unwise - %sfxdir% does not need to be writeable
Option B does not make sense to me - if that is possible you can as well put the files into the right place directly

Posted by: Galapo Jan 23 2009, 01:02 AM

Could we alter %sfxdir% to %sfx%? Or is there a particular reason for %sfxdir%?

Posted by: sanbarrow Jan 23 2009, 01:04 AM

No problem to change to %sfx%

I just picked the other name 2 years ago ... profilesdir, windir, sfxdir and so on

Posted by: Galapo Jan 23 2009, 01:13 AM

%sfx% is just a bit simpler is all.

OK, all this isn't too hard to implement in LiveXP now. Just have to write a script which adds necessary components...

Regards,
Galapo.

Posted by: sanbarrow Jan 23 2009, 01:15 AM

Can we agree that basic tools like drv_ctl.exe, regsvr32.exe, devcon.exe , snetcfg.exe are in the path ?

Posted by: Galapo Jan 23 2009, 01:19 AM

Yes. The LODR setup script for LiveXP should set those dependencies. Name any more essentials.

Of course, with LiveXP they may not be available in \system32\ or available at very early boot unless specified otherwise.

Regards,
Galapo.

Posted by: sanbarrow Jan 23 2009, 01:33 AM

What about sc.exe and regedit.exe ?
I also like to use msiexec.exe - but that may not be available on all builds

Posted by: Galapo Jan 23 2009, 01:38 AM

OK, I'll add them to the list. These also may not necessarily exist under \system32\ but will be in the path after early gui boot.

Regards,
Galapo.

Posted by: sanbarrow Jan 23 2009, 01:42 AM

What about safety-checks ?
Some LODR-batchs may seriously harm a regular Windows.
In my dotnet2-script I scan for X:\i386\system32\shell\moa.exe and abort if that file is not there.
Can we find something we have in common to check if we are running a PE ?

Posted by: Galapo Jan 23 2009, 01:48 AM

Sure, batch should check presence of 'HKLM\SYSTEM\CurrentControlSet\Control\MiniNT'. Key only exists under PE.

Regards,
Galapo.

Posted by: Galapo Jan 23 2009, 01:57 AM

So what does MOA do after junctioning to %sfx%. Generate any startmenu shortcuts for LODR? If so, which one(s)?

Thanks,
Galapo.

Posted by: sanbarrow Jan 23 2009, 02:00 AM

I don't think we need any further checks for evetually required additional runtimes like Java, Dotnet, Visual C and stuff like that.
The LODR-pack description should mention the requirements.

if an app needs Java and Java is not loaded on a build it just will not work

Posted by: Galapo Jan 23 2009, 02:07 AM

QUOTE (sanbarrow @ Jan 23 2009, 12:00 PM) *
The LODR-pack description should mention the requirements.

Yes, I agree.

Posted by: sanbarrow Jan 23 2009, 02:09 AM

QUOTE
So what does MOA do after junctioning to %sfx%. Generate any startmenu shortcuts for LODR? If so, which one(s)?


No - I do not generate startmenu shortcuts.
I use the %sfx% to automate loading of wims and vmdks.

For example if moa.exe finds a tdrive.vmdk in %sfx% it will be automatically mounted to driveletter T:\

Posted by: Galapo Jan 23 2009, 02:13 AM

So how to you start an LODR-app in MOA? Do you browse to %sfx% folder and double-click the CMD file?

Posted by: sanbarrow Jan 23 2009, 02:21 AM

QUOTE (Galapo @ Jan 23 2009, 03:13 AM) *
So how to you start an LODR-app in MOA? Do you browse to %sfx% folder and double-click the CMD file?


Either that - or as in the screenshot some posts above I right drag the batch into the startmenu or onto the desktop.

As I use MOA along with a USB-disk most of the times I only rarely need to mount wims or create junctions first.
So to load Dreamweaver for example I simply browse to R:\programs\dreamweaver and doubleclick the loader-batch.

In a case where I load from CD only the dreamweaver LODR-pack may be on an external stick - maybe under F:\dreamweaver.
Then I browse to F:\dreamweaver and doubleclick the batch.
Now it will first create a junction to R:\programs\dreamweaver and then run the app from there.

Posted by: Galapo Jan 23 2009, 02:42 AM

OK, for LiveXP I wish for a more "dynamic" solution. No "browsing" or "dragging".

Suggestion: LODR-app batch contain its title. This would be used for startmenu name. Say something like:

CODE
TITLE=Virtualization\VirtualBox
if not exist %programfiles%\virtualbox\Virtualbox.exe md %programfiles%\virtualbox
...

If batch is VirtualBox.cmd, there would also be a matching VirtualBox.ico so we get a nice menu.

Project would be the one to use these basics to create menu or not (as case may be).

Regards,
Galapo.

Posted by: sanbarrow Jan 23 2009, 02:53 AM

Hmm - I can't follow.

I you have a USB-disks with a lot of LODR-packs you will very likely also use the startmenu from the USB-disk - so dragging shortcuts as needed is the easiest thing.
You do that once and on every future boot the shortcuts are directly where you want them.

Posted by: Galapo Jan 23 2009, 03:12 AM

I want a method which allows for automatic shortcut generation. By specifying a title, this could be used for the startmenu shortcut name.

Posted by: sanbarrow Jan 23 2009, 03:18 AM

Do you want to add a routine to the core-system that scans %programsdir% for existing apps and then populates startmenu ?

That of course makes sense

Posted by: Galapo Jan 23 2009, 03:22 AM

Yes, I want a method that if something where able to be scanned for the presence of LODR-apps, then once this was detected, there was a way for this "scanner" to then generate shortcuts.

Posted by: Galapo Jan 23 2009, 04:06 AM

Ulli, do you have a link for your VirtualBox pack. We may as well use this one as our test example. I'd like to play around a little bit with it etc.

Thanks,
Galapo.

Posted by: sanbarrow Jan 23 2009, 03:19 PM

I'll upload one now - do you prefer wim or plain files in a zip ?

http://ports.sanbarrow.com/apps/virtualbox/virtualbox21.wim

use with the batch we discussed some posts ago - USB- in guests doesn't work yet.

Be carefdul if you run this along with VMware Workstation !
As soon as you start a VirtualBOX-VM with enabled VT-support - this will instantly crash all running VMware machines.

Posted by: Galapo Jan 23 2009, 08:06 PM

OK, thanks for that.

In MOA, is LODR location mapped to %sfx% directory?

Thanks,
Galapo.

Posted by: sanbarrow Jan 23 2009, 09:09 PM

Galapo - to me this LODR-packages are no strict concept - more a style of working.

So I also don't have a strict rule for directories and paths.
The idea is to run an app from where you find it - with a minimum of file-operations and registry-patching.
Keeping that in mind it really doesn't matter - and it should not matter where the packages are.
Just link them in place - so that they are in the expected place when you load them.

Lets see if we can find out best practice together and along the road.


Posted by: Galapo Jan 23 2009, 09:24 PM

QUOTE (sanbarrow @ Jan 24 2009, 07:09 AM) *
The idea is to run an app from where you find it - with a minimum of file-operations and registry-patching.

In that case %sfx% should be current directory -- how else does the command file know where %sfx% is if app can be found anywhere by definition?

Posted by: sanbarrow Jan 23 2009, 09:32 PM

I handle that like this ...
if I create a build that runs from CD only - I put the apps I want to have ready for load on demand into the %sfx% dir.
As this will be found after boot I can automate loading of the apps I have there by adding a line to lastbatch.cmd.

Apps that I use rarely I store on a USB-disk or stick ...

No need to have strict rules - put apps you expect to use often into the %sfx% dir so that you can automate them - the stuff you rarely use can be where ever

Posted by: Galapo Jan 23 2009, 10:02 PM

Yep, I was thinking along same lines for LiveXP. However, if we use such variable, then these LODR-apps won't work outside of our projects since %sfx% won't be defined.

So how about something like this at start of the batch -- then LODR-packs will be portable.

CODE
IF NOT DEFINED sfx SET sfx=%CD%


resulting in:

CODE
@echo off
IF NOT DEFINED sfx SET sfx=%CD%
if not exist  %programfiles%\virtualbox\Virtualbox.exe md %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe junction virtualbox  %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe imagex /mount %sfx%\virtualbox21.wim 1  %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe exit
...


Regards,
Galapo.

Posted by: sanbarrow Jan 23 2009, 10:07 PM

Makes perfect sense - by the way - does VirtualBox run on a typical build of yours ?

Posted by: risolutore Jan 23 2009, 10:39 PM

..seems to me that this development will get us close to Vmare ThinApp, wink.gif that is a very good product, BUT commercial (30 days trial).
ATM I have installed VMWare thinApp 4.x and used to take snapshot of different apps. After I rebboted and started a clean session of VistaPE and tested the apps "thinstalled" and they are all runnning well. I know that is not the same concept of LODR-packs BUT could be an interesting solution for runing an apps on different hardware and workstations.

Posted by: sanbarrow Jan 23 2009, 10:48 PM

In a way that is both the same concept: pack your app in such a way that you can
later use it with a minimum amount of changes to the running system.

Thinapp needs to do a much cleaner job on regular Windows.
On PE quick and dirty is good enough ;-)

Posted by: joakim Jan 23 2009, 11:11 PM

QUOTE
..seems to me that this development will get us close to Vmare ThinApp, wink.gif that is a very good product, BUT commercial (30 days trial)

Yes indeed, Thinapp can do much interesting stuff for you. The downside is that issues arise when trying to pack advanced system services. Performance is less than the "real app" would give you. Thianapped packages run from PE is painfully slow though. Anyways the concepts are related.

What would be the preferred way generating shortcuts for LODR-packages? I mean, 3.rd party apps (shortcut.exe, nircmd.exe...), autoits inbuilt functions, or..=? Something separated from the core.

What would the preferred start menu entry say? Should it be grouped under "LODR-Packages" as subitems?


Joakim

Posted by: joakim Jan 23 2009, 11:26 PM

We should also add SLODR-Packs. Secret Load On Demand Packages, encryped containers on hidden partitions.. For the paranoid with a reason crew.

Joakim

Posted by: Galapo Jan 24 2009, 12:45 AM

QUOTE (sanbarrow @ Jan 24 2009, 08:07 AM) *
does VirtualBox run on a typical build of yours ?
I confess, I haven't tried VirtualBox yet under LiveXP. But will know soon enough since we're using it as an example.

QUOTE (joakim @ Jan 24 2009, 09:11 AM) *
What would be the preferred way generating shortcuts for LODR-packages? I mean, 3.rd party apps (shortcut.exe, nircmd.exe...), autoits inbuilt functions, or..=? Something separated from the core.
I assume this will be left up to the project under which the LODR-app is run. Shortcuts, of course, is optional. With LiveXP I intend to offer a way for shortcuts to be generated, most likely by way of AutoIt app to be coded.

QUOTE (joakim @ Jan 24 2009, 09:11 AM) *
What would the preferred start menu entry say? Should it be grouped under "LODR-Packages" as subitems?

Again, dependent upon the project to decide, I assume (other than my "Title" suggestion above). Maybe just "LODR" is simple enough?

Regards,
Galapo.

Posted by: sanbarrow Jan 24 2009, 01:02 AM

IMHO we should ignore shortcut creation completely.

My first priority when starting this discussion was to allow easy know-how exchange between our different platforms.

For this to be useful for all of us we should try to keep the batchs as simple as possible.

Posted by: Galapo Jan 24 2009, 01:02 AM

OK, here's what I have for our VirtualBox example so far:

CODE
@echo off
IF NOT DEFINED sfx SET sfx=%CD%

if not exist  %programfiles%\virtualbox\Virtualbox.exe md %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe junction %sfx%\virtualbox  %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe imagex /mount %sfx%\virtualbox21.wim 1  %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe exit

regsvr32 /s %programfiles%\virtualbox\VBoxC.dll
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFltNotify.dll %systemroot%\system32\VBoxNetFltNotify.dll
copy %programfiles%\virtualbox\drivers\network\netflt\miniport\VBoxNetFlt_m.inf %systemroot%\inf\VBoxNetFlt_m.inf
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.inf %systemroot%\inf\VBoxNetFlt.inf
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.sys %systemroot%\system32\drivers\VBoxNetFlt.sys
snetcfg -v -l %systemroot%\inf\VBoxNetFlt.inf -c s -i sun_VBoxNetFlt
snetcfg -v -l %systemroot%\inf\VBoxNetFlt_m.inf -c s -i sun_VBoxNetFltmp
regsvr32 /s VBoxNetFltNotify.dll
drv_ctl --inst-nostart VBoxDrv %programfiles%\virtualbox\drivers\VBoxDrv\VBoxDrv.sys
drv_ctl --inst-nostart VBoxUSB %programfiles%\virtualbox\drivers\USB\device\VBoxUSB.sys
drv_ctl --inst-nostart VBoxUSBMon %programfiles%\virtualbox\drivers\USB\filter\VBoxUSBMon.sys
net start VBoxNetFlt
net start VBoxDrv
net start VBoxUSBMon
start %programfiles%\virtualbox\VBoxSVC.exe
start %programfiles%\virtualbox\Virtualbox.exe
exit

[LODR]
Shortcut=Virtualization\VirtualBox
Shortcut_Parameters=
Icon=VirtualBox.ico


Notice the [LODR] section. This will allow easy INI-style read to gain info for nice shortcut generation in a project if so desired. So shortcut could be made, say, as 'Start Menu\Programs\LODR\Virtualization\VirtualBox.lnk' or however a particular project wants using base of 'Virtualization\VirtualBox' as specified in [LODR].

Comments?

Regards,
Galapo.

Posted by: sanbarrow Jan 24 2009, 01:18 AM

Suits me perfectly thumbsup.gif

Please add the "are we in PE" check per looking up MiniNT key in registry you already suggested.

Lets work out a sample

Posted by: Galapo Jan 24 2009, 01:53 AM

QUOTE (sanbarrow @ Jan 24 2009, 11:18 AM) *
Suits me perfectly thumbsup.gif
Excellent. [LODR] section can be added to if need be. But this makes sure that we have in place the option for more advanced tasks like shortcuts if a projects wants that, which I do.

OK, so here's what we have now:

CODE
@echo off
reg.exe query HKLM\SYSTEM\CurrentControlSet\Control\minint >nul 2>&1
IF ERRORLEVEL 1 EXIT

IF NOT DEFINED sfx SET sfx=%CD%

if not exist  %programfiles%\virtualbox\Virtualbox.exe md %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe junction %sfx%\virtualbox  %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe imagex /mount %sfx%\virtualbox21.wim 1  %programfiles%\virtualbox
if not exist  %programfiles%\virtualbox\Virtualbox.exe exit

regsvr32 /s %programfiles%\virtualbox\VBoxC.dll
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFltNotify.dll %systemroot%\system32\VBoxNetFltNotify.dll
copy %programfiles%\virtualbox\drivers\network\netflt\miniport\VBoxNetFlt_m.inf %systemroot%\inf\VBoxNetFlt_m.inf
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.inf %systemroot%\inf\VBoxNetFlt.inf
copy %programfiles%\virtualbox\drivers\network\netflt\protocol\VBoxNetFlt.sys %systemroot%\system32\drivers\VBoxNetFlt.sys
snetcfg -v -l %systemroot%\inf\VBoxNetFlt.inf -c s -i sun_VBoxNetFlt
snetcfg -v -l %systemroot%\inf\VBoxNetFlt_m.inf -c s -i sun_VBoxNetFltmp
regsvr32 /s VBoxNetFltNotify.dll
drv_ctl --inst-nostart VBoxDrv %programfiles%\virtualbox\drivers\VBoxDrv\VBoxDrv.sys
drv_ctl --inst-nostart VBoxUSB %programfiles%\virtualbox\drivers\USB\device\VBoxUSB.sys
drv_ctl --inst-nostart VBoxUSBMon %programfiles%\virtualbox\drivers\USB\filter\VBoxUSBMon.sys
net start VBoxNetFlt
net start VBoxDrv
net start VBoxUSBMon
start %programfiles%\virtualbox\VBoxSVC.exe
start %programfiles%\virtualbox\Virtualbox.exe
exit

[LODR]
Shortcut=Virtualization\VirtualBox
Shortcut_Parameters=
Icon=VirtualBox.ico


Regards,
Galapo.

Posted by: sanbarrow Jan 24 2009, 03:14 AM

Here is another example I use occasionally.
Starwind - sometimes I want to serve a local disk as an iSCSI-target.
As I only use it rarely I never bothered about the few seconds it takes to load.
It only uses 8 Mb installed.

The file "starwind.exe" is the trial download - about 4 Mb

CODE
@echo off
reg.exe query HKLM\SYSTEM\CurrentControlSet\Control\minint >nul 2>&1
IF ERRORLEVEL 1 EXIT

IF NOT DEFINED sfx SET sfx=%CD%

if not exist  %sfx%\starwind.exe exit


start /wait %sfx%\starwind.exe /silent
start  %programfiles%"\Rocket Division Software\StarWind\StarWind.exe"
exit

[LODR]
Shortcut=Server\Starwind
Shortcut_Parameters=
Icon=Starwind.ico

Posted by: sanbarrow Jan 24 2009, 03:39 AM

Another example : esx-tools.
This one loads dotnet2, viclient , powershell , vitoolkit, remotecli ...
I made this one long before this so it probably only works in MOA


CODE
@echo off
reg.exe query HKLM\SYSTEM\CurrentControlSet\Control\minint >nul 2>&1
IF ERRORLEVEL 1 EXIT

IF NOT DEFINED sfx SET sfx=%CD%

if not exist  %sfx%\add2vm.wim exit
if not exist  %sfx%\add2win.wim exit
if not exist  %sfx%\esx-tools-014.exe exit


start %sfx%\esx-tools-014.exe run
exit

[LODR]
Shortcut=Virtualisation\ESX-tools
Shortcut_Parameters=
Icon=esx-tools.ico



Galapo - allowing hardcoded paths in registry patches makes things much easier.
How would you handle registry patches ?
In MOA I can reuse registry captures as they are - without any need to edit them.

Posted by: Galapo Jan 24 2009, 04:27 AM

QUOTE (sanbarrow @ Jan 24 2009, 01:39 PM) *
How would you handle registry patches ?

Yes, that's we still need to sort out.

With LiveXP, depending upon setup, %systemroot% can generally be x:\i386 or x:\minint.

Two options (maybe more, if you know of something):

a) no hard-coding in reg files

b) allow hard-coding, but specify what is hard-coded in [LODR]
CODE
[LODR]
...
RegFiles=reg1.reg|reg2.reg|reg3.reg
systemdrive=x:
systemroot=x:\i386
programfiles=x:\programs


Reg files can then be easily patched, with patching app patching the reg files and writing project's variables back to command so they may be repatched again in future, say:
CODE
[LODR]
...
RegFiles=reg1.reg|reg2.reg|reg3.reg
systemdrive=x:
systemroot=x:\minint
programfiles=x:\Program Files


Regards,
Galapo.

Posted by: sanbarrow Jan 24 2009, 04:44 AM

I never use
X:\minint
as I find that option behaves too dirty.
Its neither fish nor meat rolleyes.gif

Anyway - this would work for me.

CODE
[LODR]
...
RegFiles=reg1.reg|reg2.reg|reg3.reg
systemdrive=x:
systemroot=x:\i386
programfiles=r:\programs

Posted by: Galapo Jan 24 2009, 05:45 AM

That's fine with me. You get to supply reg files as you like them and necessary info is there for another project to adapt if required.

Note: make sure you check hex entries for hardcoding. For example,

CODE
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FLEXnet Licensing Service]
"Type"=dword:00000010
"Start"=dword:00000003
"ErrorControl"=dword:00000001
"ImagePath"=hex(2):22,00,43,00,3a,00,5c,00,50,00,72,00,6f,00,67,00,72,00,61,00,\
  6d,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,43,00,6f,00,6d,00,6d,00,6f,\
  00,6e,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,4d,00,61,00,63,00,72,00,\
  6f,00,76,00,69,00,73,00,69,00,6f,00,6e,00,20,00,53,00,68,00,61,00,72,00,65,\
  00,64,00,5c,00,46,00,4c,00,45,00,58,00,6e,00,65,00,74,00,20,00,50,00,75,00,\
  62,00,6c,00,69,00,73,00,68,00,65,00,72,00,5c,00,46,00,4e,00,50,00,4c,00,69,\
  00,63,00,65,00,6e,00,73,00,69,00,6e,00,67,00,53,00,65,00,72,00,76,00,69,00,\
  63,00,65,00,2e,00,65,00,78,00,65,00,22,00,00,00
"DisplayName"="FLEXnet Licensing Service"
"ObjectName"="LocalSystem"
"Description"="This service performs licensing functions on behalf of FLEXnet enabled products."

should not be used but rather
CODE
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FLEXnet Licensing Service]
"Type"=dword:00000010
"Start"=dword:00000003
"ErrorControl"=dword:00000001
"ImagePath"="C:\\Program Files\\Common Files\\Macrovision Shared\\FLEXnet Publisher\\FNPLicensingService.exe"
"DisplayName"="FLEXnet Licensing Service"
"ObjectName"="LocalSystem"
"Description"="This service performs licensing functions on behalf of FLEXnet enabled products."


Let's see if anyone else has on opinion regarding hard-coding.

Regards,
Galapo.

Posted by: Lancelot Jan 24 2009, 05:49 AM

Just an idea for batch file

It will be better if batch file checks the wim file (ex: virtualbox21.wim) is in a writeable media.

Posted by: Galapo Jan 24 2009, 06:00 AM

QUOTE (Lancelot @ Jan 24 2009, 03:49 PM) *
t will be better if batch file checks the wim file (ex: virtualbox21.wim) is in a writeable media.

What, and then only mount read-only?

Another idea: if reg file(s) contain no hard-coded entries, this could be indicated:

CODE
[LODR]
RegFiles=reg1.reg|reg2.reg|reg3.reg
Hardcoding=no

else indicate otherwise
CODE
[LODR]
...
RegFiles=reg1.reg|reg2.reg|reg3.reg
Hardcoding=yes
systemdrive=x:
systemroot=x:\i386
programfiles=x:\Program Files


Regards,
Galapo.

Posted by: Lancelot Jan 24 2009, 06:06 AM

Galapo

Sorry, wimmaster made me to make a mistake. no problem, no need to check writeable media.

Posted by: joakim Jan 24 2009, 10:04 AM

QUOTE
CODE
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FLEXnet Licensing Service]
"ImagePath"=hex(2):22,00,43,00,3a,00,5c,00,50,00,72,00,6f,00,67,00,72,00,61,00,\
  6d,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,43,00,6f,00,6d,00,6d,00,6f,\
  00,6e,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,4d,00,61,00,63,00,72,00,\
  6f,00,76,00,69,00,73,00,69,00,6f,00,6e,00,20,00,53,00,68,00,61,00,72,00,65,\
  00,64,00,5c,00,46,00,4c,00,45,00,58,00,6e,00,65,00,74,00,20,00,50,00,75,00,\
  62,00,6c,00,69,00,73,00,68,00,65,00,72,00,5c,00,46,00,4e,00,50,00,4c,00,69,\
  00,63,00,65,00,6e,00,73,00,69,00,6e,00,67,00,53,00,65,00,72,00,76,00,69,00,\
  63,00,65,00,2e,00,65,00,78,00,65,00,22,00,00,00


should not be used but rather
CODE
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FLEXnet Licensing Service]
"ImagePath"="C:\\Program Files\\Common Files\\Macrovision Shared\\FLEXnet Publisher\\FNPLicensingService.exe"


Let's see if anyone else has on opinion regarding hard-coding.


Is is true that ImagePath do not have to be supplied in hex when importing to registry? I always thought so.

If that is the case, it makes patching even easier. For simplicity, we need to agree on one hardcoded path (preferrably short), then patch the reg file according to your project (again preferrably one agreed upon standard path) requirement.

Joakim

Posted by: jaclaz Jan 24 2009, 12:30 PM

QUOTE (joakim @ Jan 24 2009, 12:04 PM) *
For simplicity, we need to agree on one hardcoded path (preferrably short), then patch the reg file according to your project (again preferrably one agreed upon standard path) requirement.


I vote for NO_SPACES_IN_NAMES and 8.3 (read 11 for directories) compliant.

jaclaz

Posted by: joakim Jan 24 2009, 03:04 PM

My vote is there too.

How about hardcoding "x:\LODR\Package_name\your_subtree_structure", where x can be anything.

This only important stuff now is to have an agreement on what "x:\LODR" should be (case sensitive makes it easier).

Then the patching routine necessary to reflect your location of app and writable..(which vary across projects) is trivial.

Joakim

Posted by: joakim Jan 24 2009, 10:26 PM

When setting up a framework for reg files, one thing came to my mind:

By changing ImagePath for services supplied in hex and into characters, I noticed the key change from REG_EXPAND_SZ to REG_SZ. Will this make any functional difference for LODR-packages or is it simply irrelevant?

Joakim

Posted by: sanbarrow Jan 24 2009, 11:10 PM

Can we discuss a practical example ?

http://www.vmware.com/download/sdk/virtualdisk.html

Thats the latest VMware-diskmount-tool.
Install it once - keep the files in default path.

Then load with

CODE
start /wait drv_ctl --inst-nostart vstor2-vixmount "R:\Programs\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys"
start /wait regedit /s "R:\Programs\VMware\VMware Virtual Disk Development Kit\vddk.reg"
net start vstor2-vixmount


The reg-patch looks like this

CODE
REGEDIT4



[HKEY_LOCAL_MACHINE]

[HKEY_LOCAL_MACHINE\SOFTWARE]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls]
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\iconv.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libxml2.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\glib-2.0.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\gobject-2.0.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\gthread-2.0.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libcurl.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\liblber.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libldap.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libldap_r.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\sysimgbase.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\vixDiskLibVim.dll"=dword:00000001
"R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\zlib1.dll"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PatchedComponents]
"{63E949F6-03BC-5C40-C01F-C8B3B9A1E18E}"=hex(7):58,3a,5c,69,33,38,36,5c,77,69,\
  6e,73,78,73,5c,50,6f,6c,69,63,69,65,73,5c,78,38,36,5f,70,6f,6c,69,63,79,2e,\
  38,2e,30,2e,4d,69,63,72,6f,73,6f,66,74,2e,56,43,38,30,2e,43,52,54,5f,31,66,\
  63,38,62,33,62,39,61,31,65,31,38,65,33,62,5f,78,2d,77,77,5f,37,37,63,32,34,\
  37,37,33,5c,00,7b,36,33,45,39,34,39,46,36,2d,30,33,42,43,2d,35,43,34,30,2d,\
  43,30,31,46,2d,43,38,42,33,42,39,41,31,45,31,38,45,7d,00,00
"{98CB24AD-52FB-DB5F-B01F-C8B3B9A1E18E}"=hex(7):58,3a,5c,69,33,38,36,5c,77,69,\
  6e,73,78,73,5c,78,38,36,5f,4d,69,63,72,6f,73,6f,66,74,2e,56,43,38,30,2e,43,\
  52,54,5f,31,66,63,38,62,33,62,39,61,31,65,31,38,65,33,62,5f,38,2e,30,2e,35,\
  30,37,32,37,2e,34,32,5f,78,2d,77,77,5f,30,64,65,30,36,61,63,64,5c,00,7b,39,\
  38,43,42,32,34,41,44,2d,35,32,46,42,2d,44,42,35,46,2d,42,30,31,46,2d,43,38,\
  42,33,42,39,41,31,45,31,38,45,7d,00,00
"{98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E}"=hex(7):58,3a,5c,69,33,38,36,5c,77,69,\
  6e,73,78,73,5c,4d,61,6e,69,66,65,73,74,73,5c,00,7b,39,38,43,42,32,34,41,44,\
  2d,35,32,46,42,2d,44,42,35,46,2d,43,30,31,46,2d,43,38,42,33,42,39,41,31,45,\
  31,38,45,7d,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.]

[HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Virtual Disk Development Kit]
"InstallPath"="R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\"

[HKEY_LOCAL_MACHINE\SYSTEM]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT]
"NextInstance"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000]
"Service"="vstor2-vixmount"
"Legacy"=dword:00000001
"ConfigFlags"=dword:00000000
"Class"="LegacyDriver"
"ClassGUID"="{8ECC055D-047F-11D1-A537-0000F8753ED1}"
"DeviceDesc"="Vstor2 vix Disk Tools Virtual Storage Driver"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000\Control]
"*NewlyCreated*"=dword:00000000
"ActiveService"="vstor2-vixmount"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount]
"Type"=dword:00000001
"Start"=dword:00000003
"ErrorControl"=dword:00000001
"DisplayName"="Vstor2 vix Disk Tools Virtual Storage Driver"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount\Enum]
"0"="Root\\LEGACY_VSTOR2-VIXMOUNT\\0000"
"Count"=dword:00000001
"NextInstance"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount\Security]



This works for me - how should I prepare this so that you can use it ?
Joakim - in this case there is no imagepath required.

Posted by: joakim Jan 24 2009, 11:50 PM

That looks easy enough to patch your needs with drive letters and tree-structure. We only have to agree whether R:\Programs should be topdirectory of the package. I'm fine with that, I just have to know beforehand what to search and replace in the reg file. If there is ever gonna be agreement on that directory structure for the proposed standard package, there will be more/less work in order to fit this, depending on which project it's comming from (standard prog-path for that project). As I am a lonely rider here, it doesn't matter for me.

In order to also make a generic loader for such packages (I'm kind of working on that too slowly), we need to have an ini file to read some variables from (autoit), and dynamically feed the script with.

For example:
- LODR\subtree
- Name of main executable
- How many reg/cmd
- Naming convention if several reg/cmd ie: 1.reg, 2.reg, 1.cmd, 2.cmd
- Name of custom loader if supplied
- What else??

Joakim

Posted by: sanbarrow Jan 25 2009, 12:01 AM

QUOTE
We only have to agree whether R:\Programs should be topdirectory of the package.


Do we have to ?

In that example I installed the app on the fly - it defaults to install to the directory used in the patch as in MOA %programfiles% = R:\programs.

If your project uses X:\programs that would be your top-directory then.

Posted by: joakim Jan 25 2009, 12:20 AM

As long as there are differences in default install location we need at least two options for loader/patcher (equivalent to how many different default install locations there exist):

In that case we need to come up with a loader/patcher that also reads the ini file variable "project_source" which represent a standard install path for that project (to know the search-replace... But also maybe a variable called OS_source.

If we can agree on one standard install path it will make loader-developers life easier. It will require each project to adapt/fit that before supplied. Depending on what package exists, we also need to account for files needed to be "copied" somewhere ie %SystemRoot%.

Joakim



Posted by: sanbarrow Jan 25 2009, 12:37 AM

QUOTE
If we can agree on one standard install path it will make loader-developers life easier.


Full ack - so lets take R:\programs rolleyes.gif

Anything under X:\ would be a no go for me - to me thats a step back into "stoneage" cool.gif

Posted by: joakim Jan 25 2009, 12:48 AM

He he. Yeah that was not surprising. But hey, that also fits me perfectly. But sadly not a few others I guess. We could very well end up with drawing cards about this..

Seriously, I have some basic stuff finished now. I just haven't got the right environment to test in. But will tomorrow night. I'm just trying to sort out some ini-read variables, along fighting with typo errors thats giving me headaches. Bear with me. I'll hopefully post some working stuff tomorrow with accompanying code.

Joakim

Posted by: sanbarrow Jan 25 2009, 01:09 AM

QUOTE
We could very well end up with drawing cards about this..


Hmmm ... can we agree on the assumption that we all prefer to use a ramloading image for performance - or a standard CD on low RAM machines ?

In both cases our free space available under X: is limited.

So do we want to have limited free space in %programfiles% ? - sure no.

So where do we put it ? - isn't the driveletter we use for the ramdrive the only logical place ?

In MOA I use to redirect ramdrive to a USB-disk. With %programfiles% = R:\programs I have unlimited free space in the programs-directory.
Having %programfiles% = X:\programs would cripple the whole system


Posted by: joakim Jan 25 2009, 01:32 AM

The only difference as I see it, is that not all projects by default produce a ramloading image. That means the assumption of a ramloading system is broken. Don't get me wrong.. I think ramloading is excellent, but what if your machine has less than say 512 mb ram. You would custom make a ramloading image that fits within your installed ram. Not all PE-projects have this option at buildtime. It therefore makes it even more complicated when trying to glue this stuff together, as more variables has to be added to the loader/patcher.

And what if ramloading is not agreed upon.. That would mean no ntfs in systemroot and junctions from there gone. So if junctions should still be an option for the LODR-package, there must be somewhere else formatted with ntfs. Did I hear you say R? OK so if you ANY writable space (ramdrv) after boot, why not make it ntfs..? That question deserves an answer....if junctions are ever gonna be applied.

Redirecting to your package on an usb-disk also is most appealing to me.

Another thought, to be acknowledged by the others, is to have at least one minimum of a ramdrv-writable, regardless of whether you have an usb-disk or not. Continued tomorrow.

Joakim

Posted by: sanbarrow Jan 25 2009, 01:41 AM

Joakim - the layout I use also works on hosts with 96 Mb.
In all cases I create or use an existing writeable NTFS-formatted area mounted as R:\
From then I can junction everything in place as needed.

Even on 96 Mb hosts I can use many of the LODR-packages

Posted by: Galapo Jan 25 2009, 02:48 AM

QUOTE (joakim @ Jan 24 2009, 09:04 PM) *
Is is true that ImagePath do not have to be supplied in hex when importing to registry? I always thought so.
Yes, that's correct.

QUOTE (joakim @ Jan 25 2009, 02:04 AM) *
How about hardcoding "x:\LODR\Package_name\your_subtree_structure", where x can be anything.
Please, no hardcoding in (main) command file! Main command should process with relative path: "%CD%\your_subtree_structure" or "%CD%\Package_name\your_subtree_structure".

QUOTE (sanbarrow @ Jan 25 2009, 10:10 AM) *
Then load with

CODE
start /wait drv_ctl --inst-nostart vstor2-vixmount "R:\Programs\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys"
start /wait regedit /s "R:\Programs\VMware\VMware Virtual Disk Development Kit\vddk.reg"
net start vstor2-vixmount
Again, please no hard-coding in main batch file. I thought we'd already agreed to this. Should rather be:
CODE
start /wait drv_ctl --inst-nostart vstor2-vixmount "%ProgramFiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys"
start /wait regedit /s "%ProgramFiles%\VMware\VMware Virtual Disk Development Kit\vddk.reg"
net start vstor2-vixmount



QUOTE (sanbarrow @ Jan 25 2009, 11:37 AM) *
Full ack - so lets take R:\programs rolleyes.gif
For dependent .reg file OK if hard-coding is indicated in [LODR]. In main batch this is out-of-place. Should rather be %ProgramFiles% as we've agreed.

Regards,
Galapo.

Posted by: Galapo Jan 25 2009, 02:53 AM

QUOTE (joakim @ Jan 25 2009, 12:32 PM) *
The only difference as I see it, is that not all projects by default produce a ramloading image.

Don't have to assume a ram-loading system per se. But I take it that LODR-packs may assume a) writable NTFS %Programfiles%; b) writable %SystemDrive%; and c) writable NTFS %temp%.

Regards,
Galapo.

Posted by: sanbarrow Jan 25 2009, 02:58 AM

- writable NTFS %Programfiles% - yes - thats a must have
- writable %SystemDrive% - nice to have but optional - some apps just will not work without this
- writable NTFS %temp% - not required

Posted by: Galapo Jan 25 2009, 03:00 AM

What I meant was that LODR-packs from my perspective may assume these things -- not that every app will make use of them.

Like you say, NTFS %temp% may not be required.

Regards,
Galapo.

Posted by: sanbarrow Jan 25 2009, 03:08 AM

Yes - if you start thinking about loading stuff on demand you need writeable %programfiles% - without that it doesn't make much sense.
And it is much more fun with NTFS - writeable %programfiles% - promised rolleyes.gif

Posted by: Galapo Jan 25 2009, 03:16 AM

And what about this issue of hard-coding? Can we agree to no hard-coding in main batch file? So we always use variables like %CD%, %sfx%, %ProgramFiles%, %SystemRoot%, %ALLUSERSPROFILE%, etc. And if dependent reg file contains hard-coding, this is indicated in [LODR] section as discussed.

Regards,
Galapo.

Posted by: sanbarrow Jan 25 2009, 03:30 AM

QUOTE
Can we agree to no hard-coding in main batch file? So we always use variables like %CD%, %sfx%, %ProgramFiles%, %SystemRoot%, %ALLUSERSPROFILE%, etc. And if dependent reg file contains hard-coding, this is indicated in [LODR] section as discussed.


tabletalk.gif

Yes - thats fine with me.

Posted by: Galapo Jan 25 2009, 03:35 AM

QUOTE (sanbarrow @ Jan 25 2009, 02:30 PM) *
Yes - thats fine with me.

Excellent! That means I can start coding a loader/patcher for use in LiveXP...

Regards,
Galapo.

Posted by: Galapo Jan 25 2009, 05:38 AM

QUOTE (sanbarrow @ Jan 25 2009, 10:10 AM) *
Can we discuss a practical example ?

http://www.vmware.com/download/sdk/virtualdisk.html

OK, here's an example of what it could be like:

CODE
@echo off
reg.exe query HKLM\SYSTEM\CurrentControlSet\Control\minint >nul 2>&1
if errorlevel 1 exit

IF NOT DEFINED sfx SET sfx=%CD%
    
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" md "%programfiles%\VMware\VMware Virtual Disk Development Kit"
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" junction "%sfx%\VMware\VMware Virtual Disk Development Kit  %programfiles%\VMware\VMware Virtual Disk Development Kit"
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" imagex /mount %sfx%\VMWareVDMK.wim 1  "%programfiles%\VMware\VMware Virtual Disk Development Kit"
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" exit

start /wait drv_ctl --inst-nostart vstor2-vixmount "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys"
start /wait regedit /s "%programfiles%\VMware\VMware Virtual Disk Development Kit\vddk.reg"
net start vstor2-vixmount

[LODR]
Shortcut=Virtualization\VMware Virtual Disk Development Kit
Shortcut_Parameters=
Icon=VMWareVDMK.ico
RegFiles=%programfiles%\VMware\VMware Virtual Disk Development Kit\vddk.reg
Hardcoding=Yes
programfiles=R:\Programs


Depending on location of vddk.reg, [LODR] 'RegFiles' line could be
CODE
RegFiles=%sfx%\vddk.reg
or if there was a sub-folder something like
CODE
RegFiles=%sfx%\VDDK\vddk.reg


'Icon' could also be something like
CODE
Icon=%sfx%\VDDK\VMWareVDMK.ico


Just so long as either relative path is indicated or variables are used.

Regards,
Galapo.

Posted by: joakim Jan 25 2009, 09:15 AM

QUOTE (Galapo @ Jan 25 2009, 03:16 AM) *
And what about this issue of hard-coding? Can we agree to no hard-coding in main batch file? So we always use variables like %CD%, %sfx%, %ProgramFiles%, %SystemRoot%, %ALLUSERSPROFILE%, etc. And if dependent reg file contains hard-coding, this is indicated in [LODR] section as discussed.

Thats fine. I just thought about the batch file to be patched in the same way as reg file, and substituting all top level paths with variables will achieve the same, so YES.

To avoid alot of errors I prefer to have hardcodings in reg files that can be patched before loaded after boottime. I have never tried to substitute so many paths in registry with variables, but have a feeling that some programs will complain about this (not confirmed). Galapo, do you know this?

Anyways, since patching reg files is easy and WILL work, can we agree on a common hardcoding in reg files?

Joakim

Posted by: Galapo Jan 25 2009, 09:27 AM

QUOTE (joakim @ Jan 25 2009, 08:15 PM) *
To avoid alot of errors I prefer to have hardcodings in reg files that can be patched before loaded after boottime. I have never tried to substitute so many paths in registry with variables, but have a feeling that some programs will complain about this (not confirmed). Galapo, do you know this?

Well it tends to work 99% of the time, and this is what WB scripts do all the time.

But I wasn't aware that replacing hex with text resulted in REG_SZ rather than REG_EXPAND_SZ. So if hex is to be used in such entries, it should be with a variable (I guess I'm being a bit lazy here and don't want to have to code the loader for also checking and maybe patching hex entries as well).

QUOTE
Anyways, since patching reg files is easy and WILL work, can we agree on a common hardcoding in reg files?

Well, so long as the method used is indicated in [LODR], it doesn't matter. The author of a particular pack I assume will code for their particular project. For example, users of LiveXP would as yet not be hard-coding 'r:\Programs' as that simply does not work in the project.

Regards,
Galapo.

Posted by: joakim Jan 25 2009, 01:04 PM

QUOTE (Galapo @ Jan 25 2009, 09:27 AM) *
But I wasn't aware that replacing hex with text resulted in REG_SZ rather than REG_EXPAND_SZ. So if hex is to be used in such entries, it should be with a variable (I guess I'm being a bit lazy here and don't want to have to code the loader for also checking and maybe patching hex entries as well).

It certainly will if we are talking about many different default install paths. I made a simple loader that patches both ways, though with ONE given standard path.

QUOTE
Well, so long as the method used is indicated in [LODR], it doesn't matter. The author of a particular pack I assume will code for their particular project.

How many different paths are we talking about (variables and hardcodes)?

Joakim

Posted by: Galapo Jan 25 2009, 07:45 PM

QUOTE (joakim @ Jan 26 2009, 12:04 AM) *
How many different paths are we talking about (variables and hardcodes)?

This are the ones I would think should be checked:
%ProgramFiles%
%SystemRoot%
%WinDir%
%SystemDrive%
%temp%
%AllUsersProfile%
%UserProfile%

%APPDATA% isn't defined in LiveXP, so if it needs to be, I'll add it in as well.

QUOTE (joakim @ Jan 26 2009, 12:04 AM) *
It certainly will if we are talking about many different default install paths. I made a simple loader that patches both ways, though with ONE given standard path.

Well, maybe you're right. Perhaps I should check the hex as well, just in case. What are you coding your loader in? Are you able to share the hex-patching section with me?

Regards,
Galapo.

Posted by: joakim Jan 25 2009, 10:53 PM

QUOTE (Galapo @ Jan 25 2009, 07:45 PM) *
Well, maybe you're right. Perhaps I should check the hex as well, just in case. What are you coding your loader in? Are you able to share the hex-patching section with me?

I'm doing it in Autoit. Have some bugs not sorted out yet.

My functions for the patching are:
CODE
Func _stringreplace_char()
$TextFileName = "ws651.reg"
$TextFileNameChecked = @TempDir & "\driveletter_checked.bak"
$FindText = "x:\"
$ReplaceText = FileRead($TextFileNameChecked)
$FileContents = FileRead($TextFileName)
$FileContents = StringReplace($FileContents,$FindText,$ReplaceText)
FileDelete($TextFileName)
FileWrite($TextFileName,$FileContents)
EndFunc

CODE
Func _stringreplace_hex()
$TextFileNameOrig = "ws651.reg"
$TextFileNameHex = @TempDir & "\driveletter_hex.bak"
$FindText = "78,00,3A,00,5C"
$ReplaceText = FileRead($TextFileNameHex)
$FileContents = FileRead($TextFileNameOrig)
$FileContents = StringReplace($FileContents,$FindText,$ReplaceText)
FileDelete($TextFileNameOrig)
FileWrite($TextFileNameOrig,$FileContents)
EndFunc

CODE
Func _stringreplace_scripts()
$TextFileNameScript = "ws651.cmd"
$TextFileNameChecked = @TempDir & "\driveletter_checked.bak"
$FindText = "x:\"
$ReplaceText = FileRead($TextFileNameChecked)
$FileContents = FileRead($TextFileNameScript)
$FileContents = StringReplace($FileContents,$FindText,$ReplaceText)
FileDelete($TextFileNameScript)
FileWrite($TextFileNameScript,$FileContents)
EndFunc

CODE
Func _modify_driveletter()
$LowerCase = StringLower(FileRead(@TempDir & "\driveletter.bak", 1))
$decimal = asc(FileRead(@TempDir & "\driveletter.bak"))
$hex = hex($decimal, 2)
FileOpen(@TempDir & "\driveletter.bak", 2)
FileOpen(@TempDir & "\driveletter_hex.bak", 2)
FileOpen(@TempDir & "\driveletter_checked.bak", 2)
FileWrite(@TempDir & "\driveletter.bak", $LowerCase)
FileWrite(@TempDir & "\driveletter_checked.bak", $LowerCase & ":\")
FileClose(@TempDir & "\driveletter.bak")
FileWrite(@TempDir & "\driveletter_hex.bak", $hex & ",00,3A,00,5C")
FileClose(@TempDir & "\driveletter_hex.bak")
FileClose(@TempDir & "\driveletter_checked.bak")
EndFunc

This is very basic, but you get the point. Btw the letter is read from inputbox. I believe my errors are coming from my LODR_Package.ini. Also need to replace some hardcoded stuff from the above with variables.

Joakim

Posted by: joakim Jan 26 2009, 12:06 AM

I am mostly finished with first version now. Confirmed working.

I need to do some cleanup in code before I dear post it. I also need to finish the script that collects the files (almost finished too), in addition to a proper helpfile.

I will also need to improve the variables read from ini.

Joakim

Posted by: Galapo Jan 26 2009, 12:26 AM

Hi Joakim,

Thanks, you've given me some ideas.

So how would you patch the entry I gave before, since the entry is split:

CODE
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FLEXnet Licensing Service]
"ImagePath"=hex(2):22,00,43,00,3a,00,5c,00,50,00,72,00,6f,00,67,00,72,00,61,00,\
  6d,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,43,00,6f,00,6d,00,6d,00,6f,\
  00,6e,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,4d,00,61,00,63,00,72,00,\
  6f,00,76,00,69,00,73,00,69,00,6f,00,6e,00,20,00,53,00,68,00,61,00,72,00,65,\
  00,64,00,5c,00,46,00,4c,00,45,00,58,00,6e,00,65,00,74,00,20,00,50,00,75,00,\
  62,00,6c,00,69,00,73,00,68,00,65,00,72,00,5c,00,46,00,4e,00,50,00,4c,00,69,\
  00,63,00,65,00,6e,00,73,00,69,00,6e,00,67,00,53,00,65,00,72,00,76,00,69,00,\
  63,00,65,00,2e,00,65,00,78,00,65,00,22,00,00,00


"433a5c50726f6772616d2046696c6573" requires patching, but what if it were "633a5c50726f6772616d2046696c6573" or "633a5c70726f6772616d2066696c6573"? How to code for different splits? Of course, it seems much easier to assume hex entries contain no hard-coding and only have the loader patch strings.

Regards,
Galapo.





Posted by: joakim Jan 26 2009, 11:39 AM

It should not be a problem. You must just extend the function, but you will have to know beforehand what to search for.

This is where my concept of "prepatched by hand before submitted" comes in (because it turns the loader-developers life into a nightmare if the search-rutine has to account for a large number of possible top-paths). If you can bear with me for a moment on my hardcoded idea, I will try to show how easy it will be to implement a project-independant loader. I will propose an example LODR_Package.ini.

I believe we cannot have everything quoted in variables as we do not know beforehand which drive %LODR% will reside on at buildtime, and therefore also eliminate the need for a "loader before the mainloader" that sets the %LODR%.

In my case, I would have moved entries in C:\\Program Files\\Common Files\\App_Specific\\* into the main LODR package dir and adjust the supplied regfile. Some apps writes to %ALLUSERSPROFILE%\Application Data\App_Specific\*, %COMMONPROGRAMFILES%\App_Specific\*, %USERPROFILE%\.., %PROGRAMFILES%\App_Specific\*, %systemroot%\*. This will result in x*y different path entries (x=from the above and y=c:\, b:\, r:\, x:\....). So by genuinly agree to some standard path (It REALLY doesn't matter what it is, as long as it is something consistent), the patching rutine can be simple and are less prone to errors. There will be a need for a tailored "get_files.cmd" similar to my get_files_ws651.cmd. This is necessary as we cannot redistribute most of the binaries involved. And seriously, there is no need for a file to be located exactly in C:\\Program Files\\Common Files\\. It can just as well be m:\\linux\\ if the accompanying regfile reflects that.

Joakim

Posted by: sanbarrow Jan 26 2009, 02:32 PM

Joakim - I don't see that paths like C:\whatever would appear in a LODR-patch.
I would highly recommend to create the patches on top of a running PE - that makes live much easier.
At least thats what I do - so far I never had to create a patch on a regular Windows.

I usually create my patches with regshot while running MOA. Then I only have to remove the un-necessary lines and take everything else as is.


QUOTE
I believe we cannot have everything quoted in variables as we do not know beforehand which drive %LODR% will reside on at buildtime,


? - at buildtime ??? - I completely ignore all LODR-packages at build-time - thats exactly what this is all about.

Posted by: joakim Jan 26 2009, 02:56 PM

QUOTE (sanbarrow @ Jan 26 2009, 03:32 PM) *
? - at buildtime ??? - I completely ignore all LODR-packages at build-time - thats exactly what this is all about.

That is my understanding too.

I never meant c:\... should appear. I meant in the case that someone for some reason could not supply a LODR-package without a c:\...reference.

Like I have insinuated before, I may produce a universal loader, If we can assume a limited number of supplied paths (in regfiles).

If we can have LODR_package.ini have for example
[LODR]
ProjectSource=moa/livexp/vistape
....
and have an agreement that moa=path=r:\programs and livexp=path=%programfiles%, then life can be easy.

Joakim

Posted by: sanbarrow Jan 26 2009, 04:58 PM

I would assume that a reg-patch using references like in a regular Windows has never been tested on top of PE.
So it is worthless.


QUOTE
If we can have LODR_package.ini have for example
[LODR]
ProjectSource=moa/livexp/vistape
....
and have an agreement that moa=path=r:\programs and livexp=path=%programfiles%, then life can be easy.


Yep - lets make life easy rolleyes.gif

Posted by: joakim Jan 26 2009, 05:15 PM

QUOTE (sanbarrow @ Jan 26 2009, 04:58 PM) *
I would assume that a reg-patch using references like in a regular Windows has never been tested on top of PE.
So it is worthless.

I would assume that too.

Searching for references to c:\ will never be incorporated in my solution.

Joakim

Posted by: sanbarrow Jan 26 2009, 07:14 PM

We should talk about packaging ...

In ideal case LODR-packed apps can be downloaded and used directly.

What about wims - can we redistribute files in wim-archives ?
This would work very nicely.
user downloads LODR-batch-XY.cmd and LODR-archive-XY.wim
Then he only needs to run the batch - which would then mount the wim.
And run eventually existing patches from inside the wim.

What would you use ?

Posted by: joakim Jan 26 2009, 08:58 PM

QUOTE (sanbarrow @ Jan 26 2009, 07:14 PM) *
In ideal case LODR-packed apps can be downloaded and used directly.

Yes would be nice
QUOTE
What about wims - can we redistribute files in wim-archives ?

I have some doubts.
QUOTE
Then he only needs to run the batch - which would then mount the wim.
And run eventually existing patches from inside the wim.

Yes, that makes a clean portable collection, that is very compressed.

Someone with more knowledge than me about redistributing binaries in such a way, may reply on this.

Joakim

Posted by: Lancelot Jan 26 2009, 11:45 PM

QUOTE (sanbarrow @ Jan 26 2009, 09:14 PM) *
user downloads LODR-batch-XY.cmd and LODR-archive-XY.wim

I would prefer winbuilder creating .wim file for couple of reasons
*future script updates will be easier
example: %GlobalTemplates%\VirtualBox_LODR\virtualboxs1v2.wim ( or maybe %GlobalTemplates%\LODR\VirtualBox_LODR\virtualboxv2s1.wim or whatever smile.gif ) so with 2nd build .wim creation wont be necessary but when/if an update needed, updating script would create a new .wim file smile.gif.
*investigating and finding bugies would be easier since through trials only some line changes on script will result with a new wim file
*uploading new fixed script is easier since .wim file occupy much much more space than .script smile.gif
*an option to use lodr pack or not use lodr pack can be used this way when building
**maybe some more reasons can be added smile.gif since building wim file through winbuilder seems to have more advantages

Posted by: Galapo Jan 26 2009, 11:51 PM

QUOTE (joakim @ Jan 26 2009, 10:39 PM) *
This is where my concept of "prepatched by hand before submitted" comes in (because it turns the loader-developers life into a nightmare if the search-rutine has to account for a large number of possible top-paths).

I wholeheartedly agree with this! Since the hex entries are so difficult to account for all variations and line breaks, can we agree that the loader may assume that no hex entries contain hard-coded paths? In other words, if there were hard-coded paths either a) they have been "prepatched by hand before submitted"; or b) converted to string entry and hard-coding is specified in [LODR]

QUOTE (joakim @ Jan 27 2009, 01:56 AM) *
If we can have LODR_package.ini have for example
[LODR]
ProjectSource=moa/livexp/vistape
....
and have an agreement that moa=path=r:\programs and livexp=path=%programfiles%, then life can be easy.

I don't think this is at all necessary if we simply are to specify if hard-coding exists and what has been hard-coded. In other words, an entry like this would be sufficient:
CODE
...
[LODR]
Shortcut=Virtualization\VMware Virtual Disk Development Kit
Shortcut_Parameters=
Icon=VMWareVDMK.ico
RegFiles=%programfiles%\VMware\VMware Virtual Disk Development Kit\vddk.reg
Hardcoding=Yes
programfiles=R:\Programs


QUOTE (sanbarrow @ Jan 27 2009, 06:14 AM) *
What about wims - can we redistribute files in wim-archives ?

Should be OK providing program may be redistributed.

QUOTE (sanbarrow @ Jan 27 2009, 06:14 AM) *
user downloads LODR-batch-XY.cmd and LODR-archive-XY.wim

No, I assume user will download .7z or .rar etc. containing: LODR-batch-XY.cmd, LODR-icon-XY.ico, LODR-archive-XY.wim.

Regards,
Galapo.

Posted by: Galapo Jan 26 2009, 11:58 PM

QUOTE (Galapo @ Jan 27 2009, 10:51 AM) *
I don't think this is at all necessary if we simply are to specify if hard-coding exists and what has been hard-coded. In other words, an entry like this would be sufficient:
CODE
...
[LODR]
Shortcut=Virtualization\VMware Virtual Disk Development Kit
Shortcut_Parameters=
Icon=VMWareVDMK.ico
RegFiles=%programfiles%\VMware\VMware Virtual Disk Development Kit\vddk.reg
Hardcoding=Yes
programfiles=R:\Programs


Actually, on second thoughts, this is rather tricky. vddk.reg is packaged in the WIM. So the loader would have to mount the WIM, patch the WIM, commit the changes, and then unmount the WIM. So depending on the amount of LODR-packs containing WIM images having hard-coded reg files, the loading stage could take a while.

So better to have REG files supplied alongside batch, icon, and WIM image. So in the example before it should now be altered to: I assume user will download .7z or .rar etc. containing: LODR-batch-XY.cmd, LODR-icon-XY.ico, LODR-archive-XY.wim, and LODR-reg-XY.reg.

Regards,
Galapo.

Posted by: sanbarrow Jan 27 2009, 12:10 AM

QUOTE
No, I assume user will download .7z or .rar etc. containing: LODR-batch-XY.cmd, LODR-icon-XY.ico, LODR-archive-XY.wim.

Uh no - that ain't clever ... see I use a 40 Mb java.wim for my Java-LODR-pack. If I pack wim and batch into another archive - I have to download 40 Mb and extract it - makes 80 Mb - using batch plus wim directly needs just those 40 Mb.

@ Lancelot
QUOTE
I would prefer winbuilder creating .wim file for couple of reasons

Please lets keep this completely independant from your build-process.
This is something we do AFTER boot - lets keep it as simple as that.

Posted by: Galapo Jan 27 2009, 12:17 AM

QUOTE (sanbarrow @ Jan 27 2009, 10:10 AM) *
Uh no - that ain't clever ... see I use a 40 Mb java.wim for my Java-LODR-pack. If I pack wim and batch into another archive - I have to download 40 Mb and extract it - makes 80 Mb - using batch plus wim directly needs just those 40 Mb.

In my opinion, it makes for LODR-pack supply easier to simply provide an archive containing all the necessary files. What's 80mb on modern systems anyway? After initial extraction, it's back to 40mb again.

But what ever suits the LODR-pack creator/supplier. If you want to supply a pack as four separate files to download -- LODR-batch-XY.cmd, LODR-icon-XY.ico, LODR-archive-XY.wim, LODR-reg-XY.reg -- then that's fine by me, and if someone else would prefer to supply one LODR-XY.7z containing the necessary files then that's fine by me as well. Each to his own.

Regards,
Galapo.

Posted by: sanbarrow Jan 27 2009, 12:27 AM

QUOTE
But what ever suits the LODR-pack creator/supplier...


Yep - you are right - we don't need to strict rules here

Ulli

Posted by: Galapo Jan 27 2009, 12:37 AM

Another option for this whole hex/reg issue.

What about converting REG files to AU3? This then makes editing those entries very easy. Just have to have AutoIt3.exe in path.

So something like this:

CODE
@echo off
reg.exe query HKLM\SYSTEM\CurrentControlSet\Control\minint >nul 2>&1
if errorlevel 1 exit

IF NOT DEFINED sfx SET sfx=%CD%
    
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" md "%programfiles%\VMware\VMware Virtual Disk Development Kit"
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" junction "%sfx%\VMware\VMware Virtual Disk Development Kit  %programfiles%\VMware\VMware Virtual Disk Development Kit"
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" imagex /mount %sfx%\LODR-archive-VMWareVDMK.wim 1  "%programfiles%\VMware\VMware Virtual Disk Development Kit"
if not exist "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys" exit

start /wait drv_ctl --inst-nostart vstor2-vixmount "%programfiles%\VMware\VMware Virtual Disk Development Kit\bin\vstor2-vixmount.sys"
start /wait AutoIt3.exe "%sfx%\LODR-reg-VMWareVDMK.au3"
net start vstor2-vixmount

[LODR]
Shortcut=Virtualization\VMware Virtual Disk Development Kit
Shortcut_Parameters=
Icon=LODR-icon-VMWareVDMK.ico
RegFiles=LODR-reg-VMWareVDMK.au3
Hardcoding=Yes
programfiles=R:\Programs
systemroot=X:\i386


LODR-reg-VMWareVDMK.au3
CODE
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\iconv.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libxml2.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\glib-2.0.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\gobject-2.0.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\gthread-2.0.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libcurl.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\liblber.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libldap.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\libldap_r.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\sysimgbase.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\vixDiskLibVim.dll", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls", "R:\\Programs\\VMware\\VMware Virtual Disk Development Kit\\bin\\zlib1.dll", "REG_DWORD", 0x00000001)

RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PatchedComponents", "{63E949F6-03BC-5C40-C01F-C8B3B9A1E18E}", "REG_MULTI_SZ", "X:\i386\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773\{63E949F6-03BC-5C40-C01F-C8B3B9A1E18E}")
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PatchedComponents", "{98CB24AD-52FB-DB5F-B01F-C8B3B9A1E18E}", "REG_MULTI_SZ", "X:\i386\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd\{98CB24AD-52FB-DB5F-B01F-C8B3B9A1E18E}")
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PatchedComponents", "{98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E}", "REG_MULTI_SZ", "X:\i386\winsxs\Manifests\{98CB24AD-52FB-DB5F-C01F-C8B3B9A1E18E}")

RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Virtual Disk Development Kit", "InstallPath", "REG_SZ", "R:\Programs\VMware\VMware Virtual Disk Development Kit\")

RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT", "NextInstance", "REG_DWORD", 0x00000001)

RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000", "Service", "REG_SZ", "vstor2-vixmount")
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000", "Legacy", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000", "ConfigFlags", "REG_DWORD", 0x00000000)
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000", "Class", "REG_SZ", "LegacyDriver")
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000", "ClassGUID", "REG_SZ", "{8ECC055D-047F-11D1-A537-0000F8753ED1}")
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000", "DeviceDesc", "REG_SZ", "Vstor2 vix Disk Tools Virtual Storage Driver")

RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000\Control", "*NewlyCreated*", "REG_DWORD", 0x00000000)
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_VSTOR2-VIXMOUNT\0000\Control", "ActiveService", "REG_SZ", "vstor2-vixmount")


RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount", "Type", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount", "Start", "REG_DWORD", 0x00000003)
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount", "ErrorControl", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount", "DisplayName", "REG_SZ", "Vstor2 vix Disk Tools Virtual Storage Driver")

RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount\Enum", "0", "REG_SZ", "Root\LEGACY_VSTOR2-VIXMOUNT\0000")
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount\Enum", "Count", "REG_DWORD", 0x00000001)
RegWrite("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vstor2-vixmount\Enum", "NextInstance", "REG_DWORD", 0x00000001)


Regards,
Galapo.

Posted by: sanbarrow Jan 27 2009, 12:46 AM

Good idea - Galapo - do you have a recent regtoau3-converter ? The one I occasionally use can't handle all types of registry.

Posted by: joakim Jan 27 2009, 12:50 AM

Finally, 1.st version out:

This is 427 Kb with loader ans batch to collect necessary files. Tiny Instruction inside.

Try to hotplug this after bootup and execute the loader. I would appreciate some feedback on this.

Remember this was buildt for the sole purpose of the loader and really not about getting Workstation running. Only requirement is writable %temp%, but that will be eliminated in future releases. This should be a truly portable app for PE. Beware that the security check was left out in this version (it's actually there just not activated), so do not execute on a real system.

Only minor modifications are necessary to fit other apps, if there are rules.

Joakim

Posted by: Galapo Jan 27 2009, 12:51 AM

QUOTE (sanbarrow @ Jan 27 2009, 11:46 AM) *
Good idea - Galapo - do you have a recent regtoau3-converter ? The one I occasionally use can't handle all types of registry.

Yes, see the one attached to my previous post.

Regards,
Galapo.

Posted by: Galapo Jan 27 2009, 01:00 AM

QUOTE (joakim @ Jan 27 2009, 11:50 AM) *
I would appreciate some feedback on this.

Nice work joakim.

I only have an initial comment on 'get_files_ws651.cmd' since I don't own Workstation so testing is a bit tricky.

These lines require some modification:
CODE
copy %systemroot%\inf\oem0.inf ws651\
copy %systemroot%\inf\oem1.inf ws651\
copy %systemroot%\inf\oem2.inf ws651\


On my system and on others' systems, oem*.inf will differ significantly.

Regards,
Galapo.

Posted by: Galapo Jan 27 2009, 01:17 AM

Note: I just grabbed this reg converter from the autoit forums to save some time. I modified the dword conversion as there was a bug there. Now I notice this line:

CODE
RunWait(@ComSpec & ' /c TYPE "' & $Reg & '" > "%TEMP%\' & GetFilename($Reg) & '"', @SystemDir, @SW_HIDE)


Converts unicode files to ascii, which is now unnecessary with newer versions of AutoIt since unicode files are now supported.

Use instead the modified one I've now attached.

Regards,
Galapo.

Posted by: sanbarrow Jan 27 2009, 02:49 AM

Joakim
I don't understand how to use this ?

I installed once on the fly - run get_files_ws651.cmd.
Then I created directory LODR as suggested.
Now I have
R:\LODR\ws651
which includes the collected files, vmrunws.cmd, LODR_package.ini and ws651_LODR.exe

When I run vmrunsws.cmd Workstations starts but without any services.
When I run ws651_LODR.exe it asks "select driveletter for LODR-package" but does not accept any input.

How should I launch this ?

Posted by: sanbarrow Jan 27 2009, 05:03 AM

By the way - just released http://sanbarrow.com/phpBB2/viewtopic.php?t=1445 - loads on demand:

VMware-viclient.exe version 3.5u3
WindowsServer2003-KB926139-v2-x86-ENU.exe
VMware-Vim4PS-1.0.0-113525.exe
VMware-vix-disklib-e.x.p-99191.i386.exe
VMware-VIRemoteCLI-3.5.0-104314.exe
VMware-converter-3.0.3-89816.exe


maybe next release LODR-compatible rolleyes.gif

Posted by: Galapo Jan 27 2009, 09:58 AM

Fixed a few more bugs. Hopefully OK now!

 RegToAU3.rar ( 1.73K ) : 77


Regards,
Galapo.

Posted by: joakim Jan 27 2009, 11:37 AM

Now it should work properly . A lot of minor errors are also fixed. Now with safety check as well.

Don't think you need to own one to test this.

About the oem*.inf issue, I can pack a wim with the necessary files, to make it easier.

Have not had the time to look over the reg2au3 thing yet. Will it be easier to patch regfiles with this?

BTW, in this current version the regfile is adjusted to only need character replacement.

Joakim

Posted by: sanbarrow Jan 27 2009, 12:08 PM

Did you upload new version ?

Posted by: joakim Jan 27 2009, 12:14 PM

I am having hard times submitting attachments here.... and replies as well. Flood control and authorization mismatch??

http://www.mediafire.com/file/xfjntyq0wtq/ws651_LODR1.rar

Joakim

Posted by: sanbarrow Jan 27 2009, 12:54 PM

Joakim - please explain how to use it - I always get "driveletter was not found" ???

Which driveletter ?

Do I need to launch %temp%\ws651\ws651.cmd and ws651.reg manually ?

Posted by: Nuno Brito Jan 27 2009, 01:14 PM

QUOTE (joakim @ Jan 27 2009, 11:14 AM) *
I am having hard times submitting attachments here.... and replies as well. Flood control and authorization mismatch??
..


"normal" members usually have more limited work conditions to save resources on the server.

Sorry about these workflow annoyances but the good news is that you're moving up the ladder quite quickly and should soon be promoted to a group where no such restrictions occur.

smile.gif

Posted by: sanbarrow Jan 27 2009, 01:41 PM

Got it - it works with this sequence:

doubleclick %temp%\ws651\ws651.reg
doubleclick %temp%\ws651\ws651.cmd

manually run "net start vmci"

next I can start Workstation manually.

Hmm - this surely wasn't intended this way - was it ?

Posted by: joakim Jan 27 2009, 02:11 PM

QUOTE (sanbarrow @ Jan 27 2009, 01:41 PM) *
Hmm - this surely wasn't intended this way - was it ?

Definately not the intention. Weird, as I ran it in moa myself as well as an xp/xpe.

For the record, ws651.cmd is not worth much. It needs to be rewritten to get all the services correct.

The driveletter should only be typed with one character and nothing else, ie "r".

Joakim

http://www.mediafire.com/file/dnmhjmwwmfz/ws651.wim

Posted by: sanbarrow Jan 27 2009, 03:15 PM

Looks like it works if I clean up %temp% before calling WS651_LODR.exe.
Then I only have to manually start vmci - then I can run VMs.

FYI - I run MOA with cheatcode "remount" so %temp% is a persistant location.

Posted by: joakim Jan 27 2009, 03:28 PM

QUOTE (sanbarrow @ Jan 27 2009, 03:15 PM) *
FYI - I run MOA with cheatcode "remount" so %temp% is a persistant location.

That explains a lot, as I was expecting %temp% to be clean after each reboot. In that case, just cleaning the dir and typing only 1 letter in the inputbox will load it correctly (except for the broken ws651.cmd that I will look into later on).

I'll try to make a workaround for persistent %temp% too.

Were the shortcuts generated ok on your build?

Joakim

Posted by: sanbarrow Jan 27 2009, 03:43 PM

QUOTE (joakim @ Jan 27 2009, 03:28 PM) *
Were the shortcuts generated ok on your build?


see yourself -

Startmenu and desktop-icon are created fine. I miss the one for vmplayer.exe though

Question: if I had the LODR-pack in lets say F:\LODR - would you then install the drivers to F:\LODR\ws651 ?

Do you see any advantage here ? - i thought you would junction F:\LODR\ws651 to the default path for Workstation and launch it from there ....
The way you work now you always have to clean up shortcuts - and writing vmrun-scripts to launch VMs will behave different each time the LODR-driveletter changes ...
Looks like you make it more tricky than it needs to be ???

Posted by: sanbarrow Jan 27 2009, 03:58 PM

Joakim - it works flawlessly on "stoneage-type" boots with a ramdrive. cool.gif

Yes - if LODR\ws651 is in C:\... you really install drivers to C:\...

This makes many things more tricky than necessary - are you sure this is wise ???

Just compare:
moa-loader creates one junction
no registry-patching at load
no cmd patching at load

your loader needs to patch the cmd
needs to patch the reg-files
needs to change /cleanup shortcuts
...
thats much more work for no advantage

Posted by: joakim Jan 27 2009, 05:09 PM

QUOTE (sanbarrow @ Jan 27 2009, 03:58 PM) *
Joakim - it works flawlessly on "stoneage-type" boots with a ramdrive. cool.gif

Yes - if LODR\ws651 is in C:\... you really install drivers to C:\...

This makes many things more tricky than necessary - are you sure this is wise ???

Just compare:
moa-loader creates one junction
no registry-patching at load
no cmd patching at load

your loader needs to patch the cmd
needs to patch the reg-files
needs to change /cleanup shortcuts
...
thats much more work for no advantage

It's a yes and no answer, depending on pe-system applied to. There's always pros and cons. The way you have developed moa and the powerfulness of ramloads with persistent %PROGRAMFILES% etc, I guess the gains from utilizing such a LODR solution will be less than on other type of pe-systems. The way you already handle your LODR packages seems very well functioning, and I am not saying that this LODR solution will work better for you. I believe you have a mature solid pe-system given and bound to the assumptions and requirements for the different builds it may produce.

But the flexibility that this kind of solution gives, also relaxes many of the assumptions that other pe-systems need to have fulfilled in order to let specific apps run (be it ramdrv, ramload, fbwf, ewf, ntfs, fat32, cdfs, vmdk....) It was meant to be a truly portable solution for PE/livecd's. And honestly, I'm not quite sure where I'm going with this. I find it interesting though and appreciate the time you've spent testing on this and the feedback given.

I'll add shortcuts for vmplayer as well.

Joakim

Posted by: sanbarrow Jan 27 2009, 05:20 PM

I see - well as soon as you allow that %programfiles% is stored on Fat, Fat32 or CDFS your way is the only one to go.

But do you really need to make that assumption ?
Who uses Fat on ramdrive ???

Don't know - I would think that a LiveCD that uses Fat or Fat32 on its ramdrive is long gone history ?

Posted by: sanbarrow Jan 27 2009, 06:55 PM

What about preparing both ways ?

First let the LODR-batch try to create a junction from %CD% to %programfiles%\ws651 - if that doesn't work procede as you do now ....

creating the junction is just one line of code

Posted by: psc Jan 27 2009, 07:14 PM

I didn't take part on the discussions here since a long time.

In the very beginning I was rather enthusiastic and thought that this topic can become a great project.

But in the mean time I have the opinion, that this topic is a great sandbox for theories and discussions and visions and ..., far away from the original intention.
During the time I have besides development work in WinBuilder.exe and nativeEX, I do not have much interest to check all the suggestions.
Maybe they are partly good, then 'I beg your pardon'. But currently it beats me with a lot of posts I do not understand on the first view.

To bring this great idea to a running result, rather than having it as 'successful' discussion theme:
I suggest to split this topic into two topics:

Peter happy22.gif

Posted by: sanbarrow Jan 27 2009, 07:42 PM

Peter - for your information ... I already have a pretty good working project published that uses all this technics discussed here.
So I really don't need a chance ...

I also think that this is a open discussion - don't you think so ?

QUOTE
To bring this great idea to a running result ...


This idea already produces running results since about 2 years now.

Ulli

Posted by: psc Jan 27 2009, 07:48 PM

QUOTE (sanbarrow @ Jan 27 2009, 08:42 PM) *
Peter - for your information ... I already have a pretty good working project published that uses all this technics discussed here.
So I really don't need a chance ...

I also think that this is a open discussion - don't you think so ?

Ulli

Sorry, then I misunderstood.
(Maybe it depends on the fact that I'm 'offline' a long time)

After we published WB 076, I'll try to come back

Peter cheers.gif

Posted by: sanbarrow Jan 27 2009, 07:56 PM

Ok , ok cheers.gif

I already started using terms like blockhead in my thoughts after your last reply

Nevermind - lets see what you can use from my experience happy22.gif
I am pretty sure that in a years time everybody will use apps packed like this

Ulli

Posted by: sanbarrow Jan 27 2009, 08:20 PM

Sorry Peter - I was getting somewhat over enthusiastic with this ..

Posted by: sanbarrow Jan 27 2009, 09:48 PM

Ok - back to work.

I made a very basic LODR-pack for the winpcap 4.0.2 driver and service.
You can later test function with Wireshark-portable or something like that.

Instructions:
download zip
extract it somewhere and I really mean somewhere
run LODR-wpcap.cmd

The reg-patch contains a few hardcoded paths which can be adjusted in a few seconds

 LODR_WinPcap.zip ( 325.5K ) : 66
 

Posted by: Galapo Jan 27 2009, 10:36 PM

QUOTE (joakim @ Jan 27 2009, 09:37 PM) *
About the oem*.inf issue, I can pack a wim with the necessary files, to make it easier.

I would say it's better to gather necessary files from install file, eg:

CODE
VMware-workstation-6.0.0-45731.exe /a /v" /qb TARGETDIR=""%temp%\WS_extract"""


Regards,
Galapo.

Posted by: Galapo Jan 27 2009, 10:50 PM

QUOTE (sanbarrow @ Jan 28 2009, 01:58 AM) *
Just compare:
moa-loader creates one junction
no registry-patching at load
no cmd patching at load

your loader needs to patch the cmd
needs to patch the reg-files
needs to change /cleanup shortcuts
...
thats much more work for no advantage

Yes, but that is because your loader was designed specifically for your PE. Since the loader is not generalised for use across different PE environments, reg entries won't be accurate and so the app would fail outside of the development environment.

This is why it is important to either a) provide reg files etc. which contain no hard-coding whatsoever; or b) provide the means where what has been hard-coded may be identified and so patched for execution outside of the development environment.

Regards,
Galapo.

Posted by: Galapo Jan 27 2009, 10:59 PM

QUOTE (sanbarrow @ Jan 28 2009, 07:48 AM) *
I made a very basic LODR-pack for the winpcap 4.0.2 driver and service.
You can later test function with Wireshark-portable or something like that.

Nice work Ulli!

All necessary data is given to get the app to run under a different PE. Once we reach agreement on the structuring of [LODR], then the rest is up to the loader to make use of this.

Regards,
Galapo.

Posted by: sanbarrow Jan 27 2009, 11:21 PM

QUOTE
This is why it is important to either a) provide reg files etc. which contain no hard-coding whatsoever; or cool.gif provide the means where what has been hard-coded may be identified and so patched for execution outside of the development environment.


... or c) junction everything in place and forget about registry-patching.

Personally I find last variant 100 times easier rolleyes.gif

Not fully serious cool.gif - its just that I am a very slow coder - so I simply have to find easy ways

Posted by: Galapo Jan 27 2009, 11:24 PM

QUOTE (sanbarrow @ Jan 28 2009, 01:43 AM) *
Startmenu and desktop-icon are created fine. I miss the one for vmplayer.exe though

OK, good idea. Provide a way for multiple shortcuts and associated files:

CODE
...
IF "%1"=="workstation" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe
IF "%1"=="player" /start %ProgramFiles%\VMWare\VMWare Workstation\vmplayer.exe
IF "%1"=="" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe

[LODR]
Shortcut_number=2
Shortcut1=Virtualization\VMware Workstation
Shortcut2=Virtualization\VMware Player
Shortcut_Parameters1=workstion
Shortcut_Parameters2=player
Icon1=LODR-icon-VMWareWS.ico
Icon2=LODR-icon-VMWarePlayer.ico
RegFiles_common=LODR-reg-VMWare.au3
Hardcoding_common=Yes
programfiles_common=R:\Programs
systemroot_common=X:\i386


Of course, this could also be like this:

CODE
...
IF "%1"=="workstation" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe
IF "%1"=="player" /start %ProgramFiles%\VMWare\VMWare Workstation\vmplayer.exe
IF "%1"=="" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe

[LODR]
Shortcut_number=2
Shortcut1=Virtualization\VMware Workstation
Shortcut2=Virtualization\VMware Player
Shortcut_Parameters1=workstion
Shortcut_Parameters2=player
Icon1=LODR-icon-VMWareWS.ico
Icon2=LODR-icon-VMWarePlayer.ico
RegFiles1=LODR-reg-VMWareWS.au3
RegFiles2=LODR-reg-VMWarePlayer.reg
Hardcoding_common=Yes
programfiles_common=R:\Programs
systemroot_common=X:\i386


Or (as an example only!)

CODE
...
IF "%1"=="workstation" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe
IF "%1"=="player" /start %ProgramFiles%\VMWare\VMWare Workstation\vmplayer.exe
IF "%1"=="" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe

[LODR]
Shortcut_number=2
Shortcut1=Virtualization\VMware Workstation
Shortcut2=Virtualization\VMware Player
Shortcut_Parameters1=workstion
Shortcut_Parameters2=player
Icon1=LODR-icon-VMWareWS.ico
Icon2=LODR-icon-VMWarePlayer.ico
RegFiles1=LODR-reg-VMWareWS.au3
RegFiles2=LODR-reg-VMWarePlayer.reg
Hardcoding_common=No
programfiles1=R:\Programs
systemroot1=X:\i386
systemdrive2=c:


Thoughts?

Regards,
Galapo.

Posted by: Galapo Jan 27 2009, 11:30 PM

QUOTE (sanbarrow @ Jan 28 2009, 09:21 AM) *
... or c) junction everything in place and forget about registry-patching.

Yes, but again that is only possible if everything is still consistent.

In LiveXP, R: can be taken by something else so junctioning may fail. %systemroot% may not always be x:\i386, so these entries would still require patching.

Better, I think, to either hard-code nothing or to provide the means for being able to patch hard-coding. If we can't agree on having no hard-coding, then we must agree to providing the means of being able to patch hard-coding otherwise we are wasting out time. I think we have agreed to providing such a means through the [LODR] section. We just need to now agree to a "standard".

Regards,
Galapo.

Posted by: sanbarrow Jan 27 2009, 11:36 PM

I am not sure what you have in mind with theses LODR-parameters
Hardcoding_common ....

Wouldn't it be more straighforward if a creator just lists all variables he has defined in his build like this

%systemroot% = X:\i386
%programfiles% = R:\programs
%profilesdir% = R:\home
and so on

Then a user with a different platform directly sees what may produces issues ....

Posted by: sanbarrow Jan 27 2009, 11:40 PM

QUOTE
In LiveXP, R: can be taken by something else so junctioning may fail.


Ok - thats more flexible.
But is it worth the price ?

What is so important that you must mount it as R: ?

Posted by: Galapo Jan 27 2009, 11:52 PM

QUOTE (sanbarrow @ Jan 28 2009, 09:40 AM) *
Ok - thats more flexible.
But is it worth the price ?

Well, flexability. Personally, I don't want to have an R: in my system and i don't want to be forced to have one. I like to have minimal drives and having R: adds another drive letter that is unnecessary. That's the whole reason for having system variables -- they can be defined differently across systems.

Regards,
Galapo.

Posted by: sanbarrow Jan 27 2009, 11:56 PM

What do you use ? - B:\ or do you have %temp% under X:\ ?

You speak about driveletters as if they were something evil huh.gif

I am pretty happy with X: for system and R: for userstuff

Posted by: Lancelot Jan 27 2009, 11:58 PM

I dont like to be forced to use R: too

QUOTE (Galapo @ Jan 28 2009, 01:52 AM) *
system variables -- they can be defined differently across systems.
cheers.gif thumbup.gif thumbsup.gif

sanbarrow
we have a %temp% in B:\Documents and Settings...... (i guess folder name changes due to the language of cd) (on livexp), also location of %temp% can be changed with some settings

try to see, 15mb smile.gif http://livexp.boot-land.net/Compressed/LiveXP-Minimum.zip

Posted by: Galapo Jan 28 2009, 12:01 AM

QUOTE (sanbarrow @ Jan 28 2009, 09:36 AM) *
I am not sure what you have in mind with theses LODR-parameters
Hardcoding_common ....

My only thought with this is if an LODR-pack combined two apps with two different reg files for the two apps and these had different hard-coded paths. I admit this is very unlikely. Well, let's scrap it for the more simple option: assume reg files contain same hard-coded paths.

So this gets us back to something like this for two apps in same pack (example only):

CODE
...
IF "%1"=="workstation" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe
IF "%1"=="player" /start %ProgramFiles%\VMWare\VMWare Workstation\vmplayer.exe
IF "%1"=="" /start %ProgramFiles%\VMWare\VMWare Workstation\vmware.exe

[LODR]
Shortcut_number=2
Shortcut1=Virtualization\VMware Workstation
Shortcut2=Virtualization\VMware Player
Shortcut_Parameters1=workstion
Shortcut_Parameters2=player
Icon1=LODR-icon-VMWareWS.ico
Icon2=LODR-icon-VMWarePlayer.ico
RegFiles=LODR-reg-VMWareWS.au3|LODR-reg-VMWarePlayer.reg
Hardcoding=Yes
%programfiles%=R:\Programs
%systemroot%=X:\i386


This for pack containing single app:

CODE
...
[LODR]
Shortcut_number=1
Shortcut1=Network\WinPCap
Shortcut_Parameters1=
Icon1=
RegFiles=LODR-reg-wpcap.reg
Hardcoding=Yes
%programfiles%=R:\Programs
%systemroot%=X:\i386


What do you think?

Regards,
Galapo.

Posted by: joakim Jan 28 2009, 12:11 AM

Improved version: http://www.mediafire.com/file/jnnzi2lv2qy/ws651_LODR.rar

Shortcuts for both vmware.exe and vmplayer.exe are good now. A lot of other small things too.

The most surprising is that it now also supports VistaPE. I had an old build from a year ago I tested. Some small modifications where necessary.





I see there are 4 pages of unread posts while I've been testing and coding. I'll come back to that.

Joakim

Posted by: Galapo Jan 28 2009, 12:11 AM

QUOTE (Lancelot @ Jan 28 2009, 09:58 AM) *
we have a %temp% in B:\Documents and Settings...... (i guess folder name changes due to the language of cd) (on livexp), also location of %temp% can be changed with some settings

Yes, what %temp% expands to varies in accordance with source language.

Location of profiles by default is on ramdrive B:. User has option to change this to R: if they like, or even set to X: if %SystemDrive% is writable.

If access to %temp% is by variable rather than hard-coding, then it doesn't matter what %temp% is set to, whether it be 'r:\temp' or 'b:\Documents and Settings\Default User\Local Settings\Temp'. If acess to %ProgramFiles% is by variable rather than hard-coding, then it doesn't matter what %ProgramFiles% is set to, whether it be 'r:\Programs' or 'x:\Program Files'.

But if hard-coding must be done, then providing the mechanism for patching is what has to be done to allow for portability across different projects.

Regards,
Galapo.

Posted by: joakim Jan 28 2009, 12:19 AM

WHAT AM I DOING WRONG HERE?

I get disabled functions, invalid blabla, 1 in 5 tries are successful. And I can only reply to an old post....?

Joakim

Posted by: sanbarrow Jan 28 2009, 12:24 AM

@ Lancelot - downloaded your zip - assigned XP-sp2 unmodified sources (english)
- everything looked fine but the iso neither boots in VMware nor in Qemu -
CTRL+SHIFT+ l didn't help. It reboots after txtsetup I think
Log is attached

Joakim - good work cheers.gif

Galapo - I think discussion about this driveletters and paths is moot - you prefer yours - I prefer mine.

Maybe you add cheatcodes one day - then it will appear logically that a strict separation
X: is for %systemroot% only
R: or B: or whatever is for eveything else
has most advantages


 log.zip ( 152.29K ) : 53
 

Posted by: Galapo Jan 28 2009, 12:33 AM

QUOTE (sanbarrow @ Jan 28 2009, 11:24 AM) *
Galapo - I think discussion about this driveletters and paths is moot - you prefer yours - I prefer mine.

Yep, exactly my point. Which is why if LODR-packs developed under a particular environment are to be used outside that environment they have to avoid hard-coding entirely or provide the means for patching. Of course, I'd like the first option, but I don't think we'll agree there so we just have to agree on "standards" for the [LODR] section. Was what I provided in post #251 acceptable?

Thanks,
Galapo.

Posted by: sanbarrow Jan 28 2009, 12:41 AM

QUOTE
Was what I provided in post #251 acceptable?


Yes - thats fine .
As long as those batchs don't get too complicated so that I still understand them its fine rolleyes.gif

Lets find some examples now - did you try the winpcap on a typical LiveXP ?

Posted by: Galapo Jan 28 2009, 12:43 AM

QUOTE (sanbarrow @ Jan 28 2009, 11:41 AM) *
Lets find some examples now - did you try the winpcap on a typical LiveXP ?

Not yet, as I've been waiting until we'd settled a bit more firmly on [LODR] to code the loader for LiveXP.

So I'll now finish the script I'd started and code the loader. Shoudn't take too long, hopefully...

Regards,
Galapo.

Posted by: sanbarrow Jan 28 2009, 12:52 AM

I just made one for nmap with zenmap - GUI.
That was a tricky one - it uses a installrite - package for patching the registry.
Aren't those packages supposed to autoadjust ?
Lets try that package tomorrow

Posted by: Galapo Jan 28 2009, 01:00 AM

QUOTE (sanbarrow @ Jan 28 2009, 10:52 AM) *
That was a tricky one - it uses a installrite - package for patching the registry.
Aren't those packages supposed to autoadjust ?

Actually, I've never used installrite so I can't answer that question. If you have a link, post it now so I can take a look at you nmap pack to keep it in mind while I'm working on the loader at the moment.

Thanks,
Galapo.

Posted by: sanbarrow Jan 28 2009, 01:08 AM

Hey - here is an http://sanbarrow.com/phpBB2/viewtopic.php?t=1170 - but I doubt it will work for you ? Try it

The nmap-package has to wait - good night

Posted by: Galapo Jan 28 2009, 01:08 AM

QUOTE (joakim @ Jan 28 2009, 10:19 AM) *
I get disabled functions, invalid blabla, 1 in 5 tries are successful. And I can only reply to an old post....?

Sorry to hear about that. I get no messages like that.

Posted by: Lancelot Jan 28 2009, 01:16 AM

QUOTE (sanbarrow @ Jan 28 2009, 02:24 AM) *
@ Lancelot - downloaded your zip - assigned XP-sp2 unmodified sources (english)
- everything looked fine but the iso neither boots in VMware nor in Qemu -
CTRL+SHIFT+ l didn't help. It reboots after txtsetup I think
Log is attached
There are missing files on your source
Failed to copy [F:\xp-sp2-vol\I386\ASMS\6000\MSFT\WINDOWS\COMMON\CONTROLS\CONTROLS.CAT]
please try with a fresh source smile.gif
i just download and build, it works nice.
here is my log
http://lancelot.winbuilder.net/5F/log_200901280314.rar

Posted by: sanbarrow Jan 28 2009, 01:54 AM

Shame on me - I thought that sources were clean mellow.gif
Anyway - tried again with 2k3-r2 and build was successful.
thumbsup.gif

Nice - small ... only thing I don't like is that icons I drag on the desktop don't remain there between boots.
That issue is fixed in MOA - makes life much easier by the way


Question: where can I change path to %programfiles% ?

Posted by: Lancelot Jan 28 2009, 02:26 AM

@sanbarrow

glad for success, and glad you like smile.gif

QUOTE (sanbarrow @ Jan 28 2009, 03:54 AM) *
icons I drag on the desktop don't remain there between boots.
this is outoftopic, lets not discuss for now smile.gif.
i updated http://livexp.boot-land.net/Compressed/LiveXP-Minimum.zip now, so you get a fresher (7 days fresher smile.gif ) version

for fbwf
at create iso script (at left on treeview of winbuilder, "XP Live CD ->Finish->2 Create Image->Create ISO")
put fbwf.sys and fbwflib.dll to proper folder and enable "Add File based filter use files from" checkbox
http://img162.imageshack.us/img162/6470/snap1se5.png
ps: if you use default folder %GlobalTemplates%\FBWF , it is (%BaseDir%\Workbench\Common\FBWF\) (%BaseDir% is where winbuilder.exe is) (according to your previous log: H:\home\moon\Desktop\LiveXP-Minimum\Workbench\Common\FBWF\ )
ps: i know you know all smile.gif, just write in case not to stop on this and continue lodr packs.

so with this mini build you may more easly try lodr packs with livexp smile.gifsmile.gif which i hope would result faster development biggrin.gif

Posted by: Galapo Jan 28 2009, 02:48 AM

QUOTE (sanbarrow @ Jan 28 2009, 11:54 AM) *
Question: where can I change path to %programfiles% ?

Place the attached script in 'Projects\LiveXP\Basic\Build' folder.

 AlterProgramsFolder.rar ( 517bytes ) : 66


Note: this just alters the folder name from default source name. The folder will still be located at x:. If you desire for %ProgramFiles% to be located at a different drive letter to %SystemDrive%, a script would have to developed for this. %target_prog% would have to be outputted to wherever it is you want it located and this location would have to be written to %programfiles%, probably at boot-time as i assume it is in MOA.

Regards,
Galapo.

Posted by: sanbarrow Jan 28 2009, 03:14 AM

QUOTE
If you desire for %ProgramFiles% to be located at a different drive letter to %SystemDrive%, a script would have to developed for this.


Strange - is this so unusual that no one ever asked for it ?
As the Lancelot build I have now uses B:\documents and settings
I also want B:\program files.

Galapo - I don't change environment variables at boot-time - not at all
- I always have R:\home and R:\programs
- I just change the physical device mounted to R: at boot-time.

You could do the same but it will not get you so much as your current layout has "documents and settings" and "program files" on different drives.
If you would redirect "documents and settings" to lets say a stick or a truecryptcontainer ... so what. That doesn 't help much.
If you redirect both main user-directories in a single stroke it starts to make sense.

Posted by: Galapo Jan 28 2009, 03:25 AM

QUOTE (sanbarrow @ Jan 28 2009, 01:14 PM) *
Strange - is this so unusual that no one ever asked for it ?

Yes, I guess so. No one requested until now.

QUOTE
I also want B:\program files.
Currently not possible in any nativeEx-based project I'm aware of.

QUOTE
Galapo - I don't change environment variables at boot-time - not at all
- I always have R:\home and R:\programs
- I just change the physical device mounted to R: at boot-time.

OK, got it. But how does PEBuilder know how to output plugin programs there during build? Normally, this is outputted to '...\BartPE\Programs'.

Unless you've totally ditched program plugins so nothing is outputted there during build and you mount a previously-created folder of some sort to r:\programs at boot? If that's the case, such a method is currently incompatible with existing nativeEx-based projects as %programfiles% is set to build-time outputted programs folder because that is where app scripts build to.

Regards,
Galapo.

Posted by: Galapo Jan 28 2009, 07:29 AM

QUOTE (sanbarrow @ Jan 24 2009, 01:19 AM) *
I'll upload one now - do you prefer wim or plain files in a zip ?

http://ports.sanbarrow.com/apps/virtualbox/virtualbox21.wim

Please reupload as the file must be corrupted as it will not mount successfully.

Thanks,
Galapo.

Posted by: sanbarrow Jan 28 2009, 07:26 PM

Galapo - try again - I uploaded the file again

QUOTE
But how does PEBuilder know how to output plugin programs there during build?

I don't add app-plugins at all. At build-time I only create the Core-system.
QUOTE
Normally, this is outputted to '...\BartPE\Programs

That directory does not exist in MOA

Posted by: Galapo Jan 28 2009, 08:45 PM

Hi Ulli,

I keep getting an "access is denied" error when attempt to access the folder that the WIM has been mounted to.

I'm using imagex.exe v.6.0.6001.18000. What version created this 'virtualbox21.wim' file?

Thanks,
Galapo.

Posted by: sanbarrow Jan 28 2009, 09:00 PM

I used .6.0.6001.16386 - would that be a problem ?

Posted by: Galapo Jan 28 2009, 09:02 PM

Quite possibly. I know back in Longhorn era that generally each successive ximage.exe (as it was then) was incompatible with the previous version. Maybe that's the same here.

Regards,
Galapo.

Posted by: sanbarrow Jan 28 2009, 09:17 PM

Where do I find the version you use ?

Posted by: Galapo Jan 28 2009, 09:35 PM

http://www.microsoft.com/downloads/details.aspx?FamilyID=94bb6e34-d890-4932-81a5-5b50c657de08&displaylang=en

Posted by: Galapo Jan 28 2009, 10:06 PM

I'm not sure what's wrong. I tried with the version you're using without success either.

Posted by: sanbarrow Jan 28 2009, 10:31 PM

Hmm - I uploaded it several times ...

Just install it on the fly once and keep the install-directory - that will do as well

Posted by: sanbarrow Jan 28 2009, 10:39 PM

@ Lancelot

Have a look here - thats your LiveXP - a little moafied by me so that you can now keep desktop-icons during reboots.
http://sanbarrow.com/moa24/videos/livexp-a-la-lancelot/livexp-a-la-lancelot.html

Small problems:
diskmanagement can't be launched at cheatcode-time

Posted by: Galapo Jan 28 2009, 11:51 PM

Ulli, I've created an LODR-pack for IZArc using WIM image here: http://galapo.boot-land.net/LODR/LODR-IZArc3.81.rar

Please test.

LODR-batch_main-IZArc3.81.cmd

CODE
@echo off
reg.exe query HKLM\SYSTEM\CurrentControlSet\Control\minint >nul 2>&1
if errorlevel 1 exit

IF NOT DEFINED sfx SET sfx=%CD%

if not exist "%programfiles%\IZArc\IZArc.exe" md "%programfiles%\IZArc"
compact /U /S /I /Q "%programfiles%\IZArc"
if not exist "%programfiles%\IZArc\IZArc.exe" junction "%sfx%\IZArc" "%programfiles%\IZArc"
if not exist "%programfiles%\IZArc\IZArc.exe" imagex /mount "%sfx%\LODR-archive-IZArc3.81.wim" 1 "%programfiles%\IZArc"
if not exist "%programfiles%\IZArc\IZArc.exe" exit

AutoIt3.exe "%sfx%\LODR-reg-IZArc3.81.au3"
start "IZArc" "%programfiles%\IZArc\IZArc.exe"
exit

[LODR]
Shortcut_number=1
Shortcut1=File Tasks\Compression\IZArc
Shortcut_Parameters1=
Icon1=LODR-icon-IZArc3.81.ico
RegFiles=LODR-reg-IZArc3.81.au3
Hardcoding=Yes
%ProgramFiles%=X:\Program Files


Note particuarly two things which I think should be standard in our batches. First, the 'compact' line. This is necessary to form junction in case %ProgramFiles% is ntfs-compressed. Second, note the use of quotes around paths which could contain spaces. Without the quotes, batch fails in LiveXP with English source since %ProgramFiles% expands to 'x:\Program Files'.

Regards,
Galapo.

Posted by: sanbarrow Jan 29 2009, 12:05 AM

Hi Galapo

IZArc runs nicely - but why does the LODR-batch tries to uncompress my complete 4 Gb programs-directory first ???

The batch run for about 10 minutes ????

Other than that - good start - if we find the line that runs amok and fix it - the rest works nicely. cheers.gif

Posted by: Galapo Jan 29 2009, 12:08 AM

QUOTE (sanbarrow @ Jan 29 2009, 11:05 AM) *
IZArc runs nicely - but why does the LODR-batch tries to uncompress my complete 4 Gb programs-directory first ???

Don't know. It should be doing that, only the 'IZArc' folder:
CODE
compact /U /S /I /Q "%programfiles%\IZArc"

For me, only that one 'IZArc' folder in %programfiles% is decompressed.

Regards,
Galapo.

Posted by: sanbarrow Jan 29 2009, 12:23 AM

I don't have anything compressed in programfiles before starting the batch - it just runs through the complete directory and displays files line by line ???

Posted by: Galapo Jan 29 2009, 12:27 AM

Again, don't know. It should only be running on the directory specified. try removing the '/I' parameter perhaps. What happens?

Posted by: sanbarrow Jan 29 2009, 12:28 AM

remove the /S then it does as you want

Posted by: joakim Jan 29 2009, 12:34 AM

Version 1.0.0.3; http://www.mediafire.com/file/zyzr4yknmed/ws651_LODR_v1003.rar

Fixed ws651.cmd to correctly install services and drivers.

Automatic OS detection to handle xp/2k3/vista.

To get it working you will need Microsoft Visual C Runtimes v.8.00.50727.42.

Takes about 35 seconds to load fully, including the patching and install.

Joakim


(Authorization mismatches still haunting me..takes me about forever to post this)

Posted by: Galapo Jan 29 2009, 12:39 AM

QUOTE (sanbarrow @ Jan 29 2009, 11:28 AM) *
remove the /S then it does as you want

OK, thanks.

Regards,
Galapo.

Posted by: joakim Jan 29 2009, 12:46 AM

About WinPcap, I was messing to get wireless usb devices recognized some time ago, but with no luck. Did you ever get that working?

Joakim

Posted by: Galapo Jan 29 2009, 12:58 AM

I just successfully got VMWare Converter packaged as LODR-pack.

LODR-batch_main-VMWareConverter.cmd

CODE
@echo off
reg.exe query HKLM\SYSTEM\CurrentControlSet\Control\minint >nul 2>&1
if errorlevel 1 exit

IF NOT DEFINED sfx SET sfx=%CD%

if not exist "%programfiles%\VMWare\VMWare Converter\converter.exe" md "%programfiles%\VMWare\VMWare Converter"
compact /U /I /Q "%programfiles%\VMWare\VMWare Converter"
if not exist "%programfiles%\VMWare\VMWare Converter\converter.exe" junction "%sfx%\VMWare Converter" "%programfiles%\VMWare\VMWare Converter"
if not exist "%programfiles%\VMWare\VMWare Converter\converter.exe" imagex /mount "%sfx%\LODR-archive-VMWareConverter5.0.1.1109.wim" 1 "%programfiles%\VMWare\VMWare Converter"
if not exist "%programfiles%\VMWare\VMWare Converter\converter.exe" exit
if not exist %systemroot%\system32\drivers\etc md %systemroot%\system32\drivers\etc
if not exist %systemroot%\system32\drivers\etc\PROTOCOL copy "%programfiles%\VMWare\VMWare Converter\PROTOCOL" %systemroot%\system32\drivers\etc

AutoIt3.exe "%sfx%\LODR-batch_sub-VMWareConverter.au3" "%programfiles%\VMWare\VMWare Converter" %1
exit

[LODR]
Shortcut_number=2
Shortcut1=Virtualization\VMWare Converter (Boot mode)
Shortcut_Parameters1=boot
Icon1=LODR-icon-VMWareConverter.ico
Shortcut2=Virtualization\VMWare Converter (Starter mode)
Shortcut_Parameters2=starter
Icon2=LODR-icon-VMWareConverter.ico


LODR-batch_sub-VMWareConverter.au3
CODE
#NoTrayIcon

$conveterdir = $cmdline[1]

If _ServiceRunning("NLA") Then
Else
    MsgBox(0+16+262144, "", "Network sevice is NOT started. For VMWare Converter to run successfully, networking needs to be started." & @CRLF & @CRLF & _
    "Please start networking before attempting to start VMWare Converter.")
    Exit
EndIf

If $CmdLine[0] > 1 Then
    If $CmdLine[2]  = "boot" Then
        _common()
        _boot_mode()
    Else
        _common()
        _starter_mode()
    EndIf
Else
    _common()
    _boot_mode()
EndIf

Func _common()
SplashTextOn("", "Starting VMWare Converter, please be patient...",400, 45, -1, -1, 1, "",12,500)
RegWrite('HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE\Features', 'Pnp', 'Reg_Dword', '0x00000001')
RegWrite('HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE\Features', 'Icf', 'Reg_Dword', '0x00000001')
RunWait("net start vss","",@SW_HIDE)
RunWait('drv_ctl --inst-nostart vstor2-p2v30 "' & $conveterdir & '\vstor2-p2v30.sys"',"",@SW_HIDE)
RunWait("net start vstor2-p2v30","",@SW_HIDE)
$PID = ProcessExists("vmware-ufad.exe")
If Not $PID Then Run($conveterdir & "\vmware-ufad.exe ufa.xml","",@SW_HIDE)
Sleep(7000)
EndFunc

Func _starter_mode()
SplashOff()
Run($conveterdir & "\converter.exe")
EndFunc

Func _boot_mode()
SplashOff()
Run($conveterdir & "\converter.exe -boot")
EndFunc

Func _ServiceRunning($sServiceName)
Local $SC_MANAGER_CONNECT = 0x0001
Local $SERVICE_INTERROGATE = 0x0080
Local $SERVICE_CONTROL_INTERROGATE = 0x00000004
Local $arRet
Local $hSC
Local $hService  
Local $bRunning = 0
$arRet = DllCall("advapi32.dll", "long", "OpenSCManager", "str", "", "str", "ServicesActive", "long", $SC_MANAGER_CONNECT)
If $arRet[0] <> 0 Then
   $hSC = $arRet[0]
   $arRet = DllCall("advapi32.dll", "long", "OpenService", "long", $hSC, "str", $sServiceName, "long", $SERVICE_INTERROGATE)
   If $arRet[0] <> 0 Then
      $hService = $arRet[0]
      $arRet = DllCall("advapi32.dll", "int", "ControlService", "long", $hService, "long", $SERVICE_CONTROL_INTERROGATE, "str", "")
      $bRunning = $arRet[0]
      DllCall("advapi32.dll", "int", "CloseServiceHandle", "long", $hService)
   EndIf
   DllCall("advapi32.dll", "int", "CloseServiceHandle", "long", $hSC)
EndIf
Return $bRunning
EndFunc


Two shortcut entries are able to be produced, one for "boot" mode and the other for "starter" mode.

Example demonstrates two things: a) multiple shortcuts; and b) use of supplying parameters.

Regarding parameters, if quotes around parameters with spaces is needed, it should be specified like this:
CODE
Shortcut_Parameters1=""first parameter" "second parameter""


Regards,
Galapo.

Posted by: sanbarrow Jan 29 2009, 01:09 AM

With current MOA I have the USB-WLAN Alfa 500mW running - thats a realtek rtl 8187.

Do you use right-click on moa.exe > network > wireless support ?

Posted by: sanbarrow Jan 29 2009, 01:23 AM

Galapo - hey - thats pretty much the same way I load it iwith the moa.exe I have in MOA.

I am playing with a different batch that starts it in Configure-mode - no results yet.
That would come handy - then we can use it in either mode- whichever it is that starts first is used

By the wey - I don't understand why you need this ?
RunWait("net start vss","",@SW_HIDE)


Posted by: Galapo Jan 29 2009, 01:31 AM

QUOTE (sanbarrow @ Jan 29 2009, 12:23 PM) *
RunWait("net start vss","",@SW_HIDE)

Could be a remnant when I was running tests in the beginning and converter wasn't working properly. I haven't checked now that things are stable whether it may be dropped.

Regards,
Galapo.

Posted by: Galapo Jan 29 2009, 04:40 AM

Finished the loader and script for LiveXP.

Script is http://galapo.boot-land.net/LODR/LODR-loader.rar.

Loader source is http://galapo.boot-land.net/LODR/LODR-loader.au3 (as well as encoded in the script).



Regards,
Galapo.

Posted by: amalux Jan 29 2009, 09:27 AM

Wow! Very impressive worship.gif , thank you for all your hard work on this Galapo; I can't wait to give it a try thumbup.gif

cheers.gif

Posted by: Lancelot Jan 29 2009, 10:01 AM

Galapo:

http://img292.imageshack.us/img292/4892/snap1rr1.png

i guess this happens when bios have floppy enabled but no device connected (not sure).

Posted by: Galapo Jan 29 2009, 10:03 AM

QUOTE (amalux @ Jan 29 2009, 07:27 PM) *
I can't wait to give it a try

Try with the IZArc pack I posted: http://galapo.boot-land.net/LODR/LODR-IZArc3.81.rar

Set up the script to point to your desired path, which will be searched for at the root of each drive. If the tag file is found there, then LODR-packs are recursively scanned for beneath this path. An LODR-pack is determined by the presence of an [LODR] section in a CMD file (see the example in the IZArc pack). If any are found, then startmenu shortcut paths will be generated ready for use.

Regards,
Galapo.

Posted by: Galapo Jan 29 2009, 10:07 AM

QUOTE (Lancelot @ Jan 29 2009, 08:01 PM) *
i guess this happens when bios have floppy enabled but no device connected (not sure).

Yep, could be. I'll look at the issue tomorrow and code something a bit more elaborate to avoid the error. DriveStatus() call will probably get around it I guess, maybe have to include DriveGetDrive() too. We'll see.

Thanks,
Galapo.

Posted by: joakim Jan 29 2009, 10:32 AM

Very impressive and interesting source Galapo. I see some similarity in there, but very different. A rather massive patching and pathformatting function you have. I see you incorporate something similar to the moa_is_at_home.tag. I thought about that too. Forgive my level of coding experience and knowledge, but I see "$drives[$i] & '\' & $LODR_tag", and "LODR-packs\LODR.tag" in the msgbox on top. Is there a directory path missing in the function or missing adjustment in msgbox-text, or more than one tag file?

Where is the safetycheck you suggested earlier? I also can't see where your .ini/$ini comes from..

I'll post my source when I'm home later on today.

Joakim

Posted by: Galapo Jan 29 2009, 11:23 AM

QUOTE (joakim @ Jan 29 2009, 08:32 PM) *
I see "$drives[$i] & '\' & $LODR_tag", and "LODR-packs\LODR.tag" in the msgbox on top. Is there a directory path missing in the function or missing adjustment in msgbox-text, or more than one tag file?

$LODR_tag is defined at the beginning of the code: $LODR_tag = $cmdline[1]. As per the default setting I've entered on the script interface, this expands as 'LODR-packs\LODR.tag'. It is the file path that is checked at each drive letter and if found it is assumed that this is the LODR-packs location.

QUOTE
Where is the safetycheck you suggested earlier?
Sorry, not sure what you mean.

QUOTE
I also can't see where your .ini/$ini comes from..

$ini variable is the first parameter passed to the _Patch() function.

Regards,
Galapo.

Posted by: Lancelot Jan 29 2009, 11:25 AM

@Galapo

is junk.exe ( http://www.ltr-data.se/files/junc.zip from Olaf http://www.ltr-data.se/opencode.html) can be usable instead of junction.exe of sysinternals?

for some reasons i have some doubts about the method, because of my awful english better to write a script, thank you for LODR-loader.script (i was using other scripts instead of LODR-loader, continuing with lodr by disableing runonce is easier now)

cheers.gif

Posted by: Galapo Jan 29 2009, 11:34 AM

Amalux, I've just reuploaded the script with a new executable. See if the problem is fixed.

Thanks,
Galapo.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)