107 replies to this topic

[sanbarrow]

Peter
about the e1000:

VMware can be used wit three different nics - you specify that in the vmx-file - see
http://sanbarrow.com...mx-network.html

if you set
ethernet0.virtualDev = "vlance" you get the regular pcnet32 from AMD

ethernet0.virtualDev = "vmxnet" uses an enhanced version of the AMD - you need vmxnet drivers installed.

ethernet0.virtualDev = "e1000" sets up an Intel e1000 virtual nic - which normally should be detected by a PE with 2003 sources

I am a total winbuilder noob right now

[pscEx]

I am a total winbuilder noob right now cheers.gif

Thanks, so let's start simply:

As a preface, currently there is only one VMWare network driver, that one you call "vlance".
Therefore, please adjust your Test VM to that.

Besides the projects you already mentioned, there is a different project: nativeEx_barebone.
This contains the nativeEx core (also contained in LiveXP and NativePE) and a minimum of additional scripts, just enough, to bring a project to run and to connect to the internet.

Copy WinBuilder.exe (072 or 072a) into an empty folder.
Download nativeEx_barebone (complete) from nativeex.boot-land.net.
If nativeex.boot-land.net is not shown in the server list (with 072, 072a shows it), add it.

Do not download anything else from this server, no core, no tools, no LiveXP!
Do not download anything else from a different server!

Open the project and define your path to your W2003 source.

If you download nativeEx_barebone only, in the first run nativeEx_core and all needed tools are added.
Then it asks you to restart WinBuilder.
After restarting WinBuilder, it will build a project and finally run into qEmu.

If that works, we can continue.
If that does not work, you probably have a problem with your personal W2003 source, not with WinBuilder.

Peter

EDIT: I tried with German W2003 R2 (SP1) and W2003 SP2. Both run into qEmu with internet connection.

[sanbarrow]

that looks better - now network comes up fine.

OK - lets assume I take this project as a base.
What are the next steps ?

I need more drivers - best would be if I could add the driverpacks from driverpack.net for mass-storage and nics.

Next I need to replace the cmdline=explorer.exe with cmdline=moa.exe

Is it a good idea to edit the hives directly for testing first ?

Thanks a lot - I was about to give up for now

Ulli

[pscEx]

Next I need to replace the cmdline=explorer.exe with cmdline=moa.exe

You are a noob in WinBuilder, but you are very experienced

So no more info as just a hint by the 'Oracle of Delphi':

Try to clone CMD.Script and tell us about your success.

Good luck!

Peter

[pscEx]

Try to clone CMD.Script and tell us about your success.

An additional hint:
Usually WBVerify complains if you select Explorer and CMD.
In your case: If you select MOA and Explorer, no error message will come up (because this constellation I did not include in the veryfy controls) and the result may crash.

Therefore: Deselect Explorer when selecting your clone.

Peter

[Galapo]

I need more drivers - best would be if I could add the driverpacks from driverpack.net for mass-storage and nics.

Gday Ulli,

You could try a script for mass storage drivers I have just finished:

http://galapo.boot-l...sStorage.script

I'd be interested to hear results.

I have another one for lan drivers if you want and can upload.

Regards,
Galapo.

[pscEx]

Gday Ulli,

You could try a script for mass storage drivers I have just finished:

http://galapo.boot-l...sStorage.script

I'd be interested to hear results.

I have another one for lan drivers if you want and can upload.

Regards,
Galapo.

@Galapo
That is a nice suggestion Ulli should hold in his mind.

But please, let's continue logically from small to universal.
And here the driver issue will come later!

Peter

[sanbarrow]

Dear Oracle of Delphi

I didn't understand a word of your advice ;-)

I guess I start editing hives directly and if that works I will ask again how to do that the recommended way.

Ulli

@ galapo - happy birthday

Thanks for your help - though at the moment I have no idea what to do with that script.
I'll have to postpone that for a while - first things first

[pscEx]

Dear Oracle of Delphi

I didn't understand a word of your advice ;-)

I guess I start editing hives directly and if that works I will ask again how to do that the recommended way.

I'll have to postpone that for a while - first things first

Oracle has a 'realtime' interruption:

The PE shell is defined anywhere in the registry and written by ..., ..., cmd.script.

If you copy cmd.script to maybe moa.script, look into the script and change the necessary lines due to MOA, you will get the result that in the PE MOA is used as shell.

I do not know whether MOA will run or not, but it is started as shell.

Any additional registry tweaks are not necessary.

[German]
Das war's für heute. Spät genug.
Bis morgen.
[/German]

Peter

[sanbarrow]

By editing hives directly I was able to start the moa-launcher

Now I have to add the millions of missing dlls

Anyway - looks like a port can be done - I will need a lot of help with the .script stuff

[Galapo]

By the way - you mentioned autoit - are you interested in finishing this
http://www.boot-land...hman-t2878.html
we already talked about it at 911 some months ago

Gday Ulli,

I'm actually hoping that my OfflineSysPrep app might still accomplish some of this. Presently, I am trying to integrate the injecting of new massstorage drivers and applicable registry service entries to a partition (or writable mounted image) to boot on new hardware etc. If only I could find an app that could read a windows inf file and write a reg file or something based on this... Beyond this, I am still interested in moapatchman and might get some time to take a look.

By editing hives directly I was able to start the moa-launcher

Now I have to add the millions of missing dlls

Congratulations!

Hopefully by starting with a minimal base like nativeEx or LiveXP, we'll be able to see what's essential for moa and what's not. I'm sure there's a lot of stuff in that 200mb moa image which can be culled. This size has really kept me from taking up moa to any great extent, so I'm very pleased that a port to WB is underway.

If you get a chance, next time you boot nativeEx or whatever, take a look at what services are running and see if there's any that are particularly missing but mao requires.

Regards,
Galapo.

[sanbarrow]

...
Hopefully by starting with a minimal base like nativeEx or LiveXP, we'll be able to see what's essential for moa and what's not. I'm sure there's a lot of stuff in that 200mb moa image which can be culled. This size has really kept me from taking up moa to any great extent, so I'm very pleased that a port to WB is underway....

Hi

Yep - starting from the very basics again is a good thing - got to be careful not to add to much at a time ;-)
At the moment I just add a little bit of registry and a couple of files.
First I'll have to make sure the cheatcodes work ...

Don't know about the penetwork.
Do you know if I can use similar profiles as in penetcfg ?



Oh dear - I just thought about the dotnet 1.1 bloat I need for VI-client - gives me the shivers

[Galapo]

Don't know about the penetwork.
Do you know if I can use similar profiles as in penetcfg ?

To tell you the truth, I haven't yet played around with setting my own profiles -- just enabled auto configuration. But this won't really suit mao with potentially multiple adapters and the need to define specific ip addresses etc.

The penetwork scripts allows you to create profiles very easily -- just click the 'start editor' button. I guess check the file generated and see how this compares to the bartpe plugin version.

Oh dear - I just thought about the dotnet 1.1 bloat I need for VI-client - gives me the shivers

From memory I think maybe someone has done a script for this. It would be good for you if they have. Not may will really have the need for VI-client, so it may not be too important at this stage, but there will be some who do require it.

Regards,
Galapo.

[sanbarrow]

Galapo - maybe a little bit off topic ...

Anyway - you use programs from a vmdk mounted in undoable mode as I do ...
Recently a guy appeared at sanbarrow forum who makes a " Portable Application Launcher" and seems to be interested in the procedure I use.
See posts from itsmep3
http://sanbarrow.com...?...sc&start=15
the tool he makes is here
http://www.systemsaf.../apploader.aspx

Hey - can we set a standard for this - and make an easy launcher for this ?
We could exchange full program collections easily if we could pack them this way.
I tried to convince the UBCD4win guys some time ago - but they didn't eat it
See the screenshot of the ramdisk layout I posted some posts earlier - I run all this apps without any plugins - all is prepared at the time I actually mount the vmdk.

[sanbarrow]

Back to topic - cheatcodes.

Found a first road block: programs in X:

Can we please discuss it ? - this is so restrictive.

Everything you arrange in X: is only virtually writeable.
What we have in the ramdisk - in the workspace - is really writeable - if you redirect it to a writeable location.

With moa's cheatcode "disk" you have a completely writeable AND persistant workspace - including home and apps and temp and ...
With Moa I add programs by downloading and installing them to R:\somewhere while running Moa -
I don't want to start writing code again for things I do by drag n drop now.

Please , please , please

[Galapo]

Hey - can we set a standard for this - and make an easy launcher for this ?
We could exchange full program collections easily if we could pack them this way.
I tried to convince the UBCD4win guys some time ago - but they didn't eat it
See the screenshot of the ramdisk layout I posted some posts earlier - I run all this apps without any plugins - all is prepared at the time I actually mount the vmdk.

Offtopic doesn't really worry me -- it's very much your topic so do what you please...!

Yes, we could set something of a standard I guess.

A complication is that many of my apps require registry entries. A possible way around this may be to have a _reg_mount folder (of whatever name) with .reg files to be merged when the drive is mounted and a _reg_dismount folder for registry entries to be removed prior to the dismounting of the drive.

I have my own launcher which takes care of my mounting of password-protected .isz image and then mounting of the vmdk image. In time, I've thought that I'd like to extend the options to using a truecrypt container (or not). Really, extending options. I haven't published a script for any of this yet, just my personal modifications, inter alia, to BootSDI script.

Regards,
Galapo.

[sanbarrow]

...

Yes, we could set something of a standard I guess.

A complication is that many of my apps require registry entries. A possible way around this may be to have a _reg_mount folder (of whatever name) with .reg files to be merged when the drive is mounted and a _reg_dismount folder for registry entries to be removed prior to the dismounting of the drive.

...

What about an automatic that applies firefox.reg if exist in firefox-dir, put firefox.lnk to desktop if exist in firefox-dir and run load.cmd if exist in firefox-dir ?

Simple enough with regshot and drag n drop if you mount the vmdk regularly in a VM.

[Galapo]

Back to topic - cheatcodes.

Found a first road block: programs in X:

Can we please discuss it ? - this is so restrictive.

Everything you arrange in X: is only virtually writeable.
What we have in the ramdisk - in the workspace - is really writeable - if you redirect it to a writeable location.

With moa's cheatcode "disk" you have a completely writeable AND persistant workspace - including home and apps and temp and ...
With Moa I add programs by downloading and installing them to R:\somewhere while running Moa -
I don't want to start writing code again for things I do by drag n drop now.

Please , please , please

How about junctioning r:\programs to %programfiles% (ie x:\Program Files).

Or how about:

Hive_Load,HKU

reg_add,0x1,"%reg%\Microsoft\Windows\CurrentVersion","ProgramFilesDir","R:\Programs"

reg_add,0x1,"%reg%\Microsoft\Windows\CurrentVersion","CommonFilesDir","R:\Programs\Common"

reg_add,0x2,"%reg%\Microsoft\Windows\CurrentVersion","ProgramFilesPath","%ProgramFiles%"

reg_add,0x2,"%reg%\ControlSet001\Control\Session Manager\Environment","ProgramFiles","R:\Programs"

Hive_Unload,HKU

Regards,
Galapo.

[sanbarrow]

How about junctioning r:\programs to %programfiles% (ie x:\Program Files).

Then I can not add anything to R:\programs after boot - no that is no option.

I prefer to move as much as possible out of X:
With ProgramFilesDir in R: set in registry we can forget this problems: programs are writeable - full stop.
Why make it more complicated than it has to be.

With my current setup - all builds no matter if they run from CD. ram - if they use a to USB redirected home ... all behave the same. I just set a cheatcode at start to switch options.

Isn't it much more complicated with X:\programs ?

Moa built only needs i386-dir on the boot-cd - everything else can be where ever.

[Galapo]

With ProgramFilesDir in R: set in registry we can forget this problems: programs are writeable - full stop.
Why make it more complicated than it has to be.

Personally, I think we should leave x:\Program Files alone as this is more the "default" scenario preferred by most projects and people.

However, making the change in registry to point %programfiles% to a different location from the default would work for a non-default project such as moa. If it is stated and people are aware that programs are writable for moa then it hopefully won't be a problem or that people forget (that is, if this is the default for the moa project).

Regards,
Galapo.

[pscEx]

By editing hives directly I was able to start the moa-launcher

I think your hive edit was not different from the code inside CMD.Script:

[process]

echo,"Loading setup registry hive.."

RegHiveLoad,"Build","%target_sys%\setupreg.hiv"

echo,"Writing new value.."

RegWrite,HKLM,0x1,"Build\Setup","CmdLine","cmd.exe"

echo,"Unloading hive.."

RegHiveUnLoad,"Build"

echo,"All done"

Run,%ScriptLog%,Process-log

Peter

[sanbarrow]

I think your hive edit was not different from the code inside CMD.Script:

Sorry - where do I find that cmd.script ?

[pscEx]

Sorry - where do I find that cmd.script ?

http://nativeex.boot...ells/CMD.Script

BTW: I assume that you now use nativeEx_barebone as base for your development.
Then you can find CMD.Script in the tree under
Basic > Shells > Set cmd.exe as default shell

Peter

[MedEvil]

@sanbarrow
Just a quick question. What do you need the programs folder writable for?
All Windows compliant programs store their data in 'Documents and Settings'.

[sanbarrow]

@sanbarrow
Just a quick question. What do you need the programs folder writable for?
All Windows compliant programs store their data in 'Documents and Settings'.

@ MedEvil

You are kidding - aren't you ?

All programs I know write to to home-dir AND to the programfiles-dir.
Well - how do you run for example paintshop or dreamweaver or whatever from a regular winbuilder-CD ?
Do you want to copy all of these apps to ramdisk before you use them ?
Why do you think do all this plugins for pebuilder exist that extract an sfx-archive in to ramdisk ?

I no longer have to use this sfx-hack.
My programs all are writeable so there is no need to copy them somewhere or pack sfx-archives.

Programs like paintshop that do not need any plugins - or scripts - may still want to write ini-files inside the programs-dir
How do you manage that if you got them located on read-only media ???

Come on - give that idea a chance

With my MOA - layout I only need to write plugins for apps that need kernel drivers which can not be launched easily otherwise.
Hey - I can run things like Virtual PC or Virtual Box from MOA without writing a plugin - I just install them when I want to use them.

http://sanbarrow.com...nshots-mix.html

In case I use moas cheatcode "disk" I for example use a 80 Gb 2.5 inch USB-disk instead of a ramdisk.
In effect I have almost unlimited free space in "programfiles" and "home" and "temp" without having to do any redirecting junctions back to X:\programs or whatever.

Please , please , please

With MOA-layout I can add 20 apps to my built in the time you write a script for one - if you are fast.
I don't even have to rebuild the full CD - I just add a changed vmdk and make a new ISO.

You may say - why I want to run paintshop from a LiveCD ?

Well - I don't use it often - I just have paintshop in one of my optional vmdks and load it on demand.
I do not regard this Live Cds as a rescue platform - I regard them as homeusers system of tomorrow.
If you only have the i386 dir on readonly CD you get the best of LiveCD/ regular install in one built:
a system that is cleaned from virus on reboot AND the option to use maybe 80% of all apps that are available.
Unless you are a gamer or need some fancy hardware you can do all things that you do on a regular Windows from MOA.
If an app doesn't work from MOA - just run it inside a VM.

Some of the MOA-users already replaced their regular Windows and are very happy with the results.

Please , please consider to make this layout change - it will not hurt you.
You can easily junction back from R:\programs to X:\programs to keep backwards -compatible.

By the way - you really do not need large ramdisks to make this work - you can start with a 8Mb ramdisk on lowRAM hosts ...

I use this layout since about 2 years - and it is very solid and easily manageable - so I really would hate to go one step back
and use your layout for a port to winbuilder.

Ulli