30 replies to this topic

[sanbarrow]

I guess you can add an option on the script interface and use a %temp% that suits your needs - the newer projects do tend to be more dynamic and ease these changes a lot..

Good to hear - when I try to use %temp% = %ramdrive%\temp in Reatogo or XPE it doesn't work well - if at all.
Anyway - it would be an unclean approach if an important setting like this is handled in an inconsistent way.

Do the several projects have a clear standard how to set these parameters ?
If not - maybe we should consider to set a common standard ?

Looks like you do not have clear preferences on this topic ?

What do you think about moving programs into a virtual disk ?

I really love this table-talk emoticon

Hey - I noticed that I am the only user in the group developer - in the US-VMware-forum I'm the only one in the in-official "mad scientist" group.
Slowly I see a pattern building up

[Brito]

Under the current nativeEx based projects things have grown a lot in terms of efficiency - so it will likely be the common standard rule for our next generation of boot disks on XP/2003 PE environments.

I've just been a bit busier doing some works on the next wb - after this I hope to have more time to help you out with your project, just trying to dedicate my time to one thing at a time to do the job right..

What do you think about moving programs into a virtual disk ?

Why not? You mean mounting the disk on the host OS, copying all programs, placing it inside the ISO and then load it like a sort of SDI image? HighwayStar has already created a way to use SDI technology without resorting to MS licensed files, and I like the idea since it is a similar method used by the recent vistaPE and WIM images, meaning that we'll have to deal with this sort of matters sooner or later - I always give for sooner to start testing this..

Hey - I noticed that I am the only user in the group developer - in the US-VMware-forum I'm the only one in the in-official "mad scientist" group.
Slowly I see a pattern building up

hmm.. a pattern you'd say?

[TheHive]

Nuno - I don't know if you have an idea of what my MOA-stuff looks like - if you have a possibilty to watch VMware-codec videos please check this video I made
http://sanbarrow.com...moa025video.zip

Thanks for the video. it allows to understand it better. So you have something like shell launcher.

And I would really like to settle down in a larger community - instead of fighting alone.

Yeah! It sucks when you have to argue with yourself because you already know whose going to convince who.

[sanbarrow]

Thanks for the video. it allows to understand it better. So you have something like shell launcher.

Yes - the launcher searches for available virtual disks.

Have you seen the 4 input boxes on the left side of the launcher ?
If there is a free slot I can drag a virtual disk into it, right click the driveletter icon and voila - it gets mounted and integrated into my programs-directory.

If enough memory is available it mounts them in writeable mode and executes an autoload.cmd.
This batch creates junctions from my programs-dir to the programs in the virtual disk.
After that it merges all reg.files in an autoload-directrory into the registry.
Finally it copies desktop-icons or startmenu-shortcuts i place.

The result is I do not need any registry-expansion as I can always use hardcoded paths for any registry-stuff or shortcuts.
As I use driveletter R: for my RAMdrive I can very easily build a developement virtual machine that has the very same
layout than the PE will have when booted from CD later.

This allows creating startmenu entries by drag and drop.
It allows adding of programs like dreamweaver without writing any code at all.
I just have to add a line to my autoload-batch that says
junction R:\programs\dreamweaver dreamweaver

Later when I use the PE it doesn't matter at all wether the virtual disk that contains dreamweaver is copied to the CD or wether I load it from a mapped network-drive ...

I often hear that one uses variables for paths like %programsdrive%\programs\my-program.
Somehow I see no point in that - I don't need to use a variable for something that is well defined.

Why should I build a plugin by replacing
path-to-app = R:\programs\app
with
path-to-app = %programsdrive%\programs\app
and then hope that after boot of the PE this gets correctly translated into
path-to-app = R:\programs\app ???

The only variables I can't work around is %systemroot% as this maybe X:\i386, X:\minint or X:\sbin or whatever.

Anyway - I am happy with this layout I use as it is very easy to add stuff because I have a developement-regular windows-installation that is an almost exact mirror of the later PE.

If the ramdrive is a variable it is much more work to add a program in a lazy way.
If the ramdrive is set to B: my lazy way is impossible.

I really like to be lazy

By the way - Linux guys are lazy too - they alway use programs in /usr/bin - so that they can address them in a "always the same way" - it doesn't really matter wether /usr/bin is on the first,second or 23th hard-drive.

If you ask me - driveletters are a serious design-error in Windows

Ulli

[was_jaclaz]

If you ask me - driveletters are a serious design-error in Windows

Actually, if I may correct you , driveletters are a serious design-error in DOS.

NO design was made regarding drives in Windows, not in Win9x/Me, nor in the NT/2K/XP/2003, Microsoft just KEPT the old design, most probably for compatibility purposes (that could well have been fixed by the use of inter-drive and inter-filesystem junction points or hard-links ).

jaclaz

[sanbarrow]

Actually, if I may correct you , driveletters are a serious design-error in DOS.

NO design was made regarding drives in Windows, not in Win9x/Me, nor in the NT/2K/XP/2003, Microsoft just KEPT the old design, most probably for compatibility purposes (that could well have been fixed by the use of inter-drive and inter-filesystem junction points or hard-links ).

jaclaz

Jaclaz - sure you are right - driveletters were introduced in DOS.
In those days when a typical box was built with one or two floppies and one harddisk no problems occured.
If you have only one disk it doesn't really matter if you address this a C: or as "/"

The difference appear when you add more and more devices ...
Linux has a much cleaner way to do this - they allways boot from / and add devices in a configurable way - look at the fstab.
NTFS-based Windows can do something like this as well - but it is much more complicated as the config-file is no plain text as it is hidden in registry - see HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ...

Ulli