520 replies to this topic

[cdob]

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.

[amalux]

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...opic.php?t=1364
those must exist in the directory - everything else is optional.

By the way - can we discuss this specific questions in the MOA 2.4 post ?
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

[amalux]

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 )

[sanbarrow]

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.

[cdob]

@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.

[sanbarrow]

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

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

[Lancelot]

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

[sanbarrow]

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



Ulli

[Galapo]

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.

[sanbarrow]

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

[Galapo]

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.

[sanbarrow]

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.

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

[Galapo]

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.

[sanbarrow]

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 ...

[sanbarrow]

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

drastically reduced development time ...
Just had a nice example at 911-forum - see
http://www.911cd.net...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.

[sanbarrow]

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...on68mb-host.png

[joakim]

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

[sanbarrow]

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

[Galapo]

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.

[joakim]

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

[Galapo]

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.

[sanbarrow]

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

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

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.

[Galapo]

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.

[sanbarrow]

Oops - we crossposted ...

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

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

[Galapo]

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.