520 replies to this topic

[MedEvil]

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

[sanbarrow]

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

[amalux]

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...4-setup-024.exe

Having a bit of trouble with moa tut here

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

[amalux]

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

Congrats MedEvil, you've completely missed the point again

[sanbarrow]

All MOA 2.3 stiff is out-dated.
Go to a 32bit machine with NTFS - run 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...x-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

[pscEx]

Congrats MedEvil, you've completely missed the point again

Peter ( )

[amalux]

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

- 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

[MedEvil]

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.

[sanbarrow]

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

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

[amalux]

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

[sanbarrow]

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

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

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

[amalux]

Please read http://sanbarrow.com...-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

[sanbarrow]

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

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.

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

[Galapo]

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.

[MedEvil]

be able to run all VMware apps

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

[rawr]

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

my guess is 'VMware disk mount utility' or similar things

its possible even probable im way out tho

LODR-packs ( it sounds like a good thing )

[amalux]

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

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.

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!

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

[sanbarrow]

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

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.

[MedEvil]

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.

[sanbarrow]

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

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

[MedEvil]

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.

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.

[amalux]

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

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.

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

[MedEvil]

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

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

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.

[amalux]

MedEvil,

sanbarrow,

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

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

[sanbarrow]

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