Separation of system-core and user-stuff: LODR-packs
#501
Posted 23 March 2009 - 02:35 PM
lnk.7z 393bytes 704 downloads
I may have lost control of this experiment - I'm getting unexpected results (still not working), I'll start over and report shortly. The problem is too many variables, PE side and LODR side and the fact that what I'm really trying to do is just a bit different than what you intended - You can take a look in the tutorial here, towards the bottom under Adding Portable Apps and LODR-Packs to LiveXP (still under construction, the links will be back shortly) to get a better idea of what I'm after. Any help you can offer here for auto-starting the exe is appreciated; everything works well except for the auto launch but it's still convenient to have it launch-able (manually) from the Start menu.
#502
Posted 23 March 2009 - 11:24 PM
Here's the settings I used:
The root of the directory:
Start.cmd:
start "ASuite" "%~DP0\Start.exe" EXIT [LODR] Shortcut_number=1 Shortcut1="ASuite Launcher" Shortcut_Parameters1= Icon1=Start.exe Autostart1=True
Very confusing that it works for me and not you!
Regards,
Galapo.
#503
Posted 24 March 2009 - 04:50 AM
Yes, but interesting... Thank you very much for testing and report... and for LODR-Pack stuffVery confusing that it works for me and not you!
Regards,
Galapo.
#504
Posted 25 March 2009 - 03:33 AM
Sorry to keep this going but I've got more questions...Start.cmd:
start "ASuite" "%~DP0\Start.exe" EXIT [LODR] Shortcut_number=1 Shortcut1="ASuite Launcher" Shortcut_Parameters1= Icon1=Start.exe Autostart1=True
Very confusing that it works for me and not you!
Regards,
Galapo.
As known, with Autostart1=True in Start.cmd I get the .lnk errors but if I set Autostart1=False and add the following to PE's registry,
Hive_Load,Machine reg_add,0x1,"%reg%\Microsoft\Windows\CurrentVersion\Run","ASuite","C:\ASuite\Launcher\ASuite.exe" Hive_Unload,MachineI have success. My question is how to universalize this for any drive letter the UFD might occupy when unable to utilize your Autostart function or can your autostart be tweaked in any way?? I realize you can't test this error so I would be the tester for any ideas you may have.
#505
Posted 25 March 2009 - 03:59 AM
Actually, that's exactly what my LODR-loader is supposed to do. If we could just diagnose the problem, then you would have what you need.My question is how to universalize this for any drive letter the UFD might occupy when unable to utilize your Autostart function or can your autostart be tweaked in any way??
Regards,
Galapo.
#506
Posted 25 March 2009 - 04:21 AM
It must be conflicting with sth else in my build, I'll keep looking... Thanks againActually, that's exactly what my LODR-loader is supposed to do. If we could just diagnose the problem, then you would have what you need.
Regards,
Galapo.
#507
Posted 28 March 2009 - 10:39 AM
Everything working well now and new links are up - this is the best way to use LiveXP imoIt must be conflicting with sth else in my build, I'll keep looking... Thanks again
Thanks again for all your help
#508
Posted 28 March 2009 - 10:47 AM
Thanks,
Galapo.
#509
Posted 28 March 2009 - 04:37 PM
I couldn't figure out how to get yours working so I came up with my own which isn't fancy or elegant but works just fine:So what was the problem?
Thanks,
Galapo.
[Autorun] Hive_Load,Machine reg_add,0x1,"%reg%\Microsoft\Windows\CurrentVersion\Run","ASuiteC","C:\ASuite\Launcher\ASuite.exe" reg_add,0x1,"%reg%\Microsoft\Windows\CurrentVersion\Run","ASuiteD","D:\ASuite\Launcher\ASuite.exe" ... reg_add,0x1,"%reg%\Microsoft\Windows\CurrentVersion\Run","ASuiteM","M:\ASuite\Launcher\ASuite.exe" Hive_Unload,MachineI left it as an option in my script if anyone wants to try your way - hopefully they can give some feedback. I'd still like to get yours working and will continue to look at it when I can but I had to get a solution posted and this one works without issue on every computer I've tested, regardless of where the ASuite package resides; even on the same disk as LiveXP's image (I'm sure yours did to).
#510
Posted 22 May 2009 - 09:59 PM
Dotnet3 is required for the new VMware vSphere-client.
Ulli
#511
Posted 22 May 2009 - 10:24 PM
... latest news : dotnet3 can be LODR-packed
good news , thanks a lot for informing
#512
Posted 22 May 2009 - 10:37 PM
I guess in MOA I will use it as an addon-package to dotnet2. You must first load dotnet2 and then run an additional LODR-pack for dotnet3.
Best of all - you do not need any changes in the core-system.
#513
Posted 22 May 2009 - 10:58 PM
addon-package to dotnet2 good idea
20 Mb of files maybe ready in built if demanded .
all we need a "general" lodr pack to test . and if possible a method to gather files from install package (yep i understand the method you use for dotnet2....)
You know on LiveXP bootsdi we have B: ntfs and X: ntfs, further is up to you for a "general" package since you are a pro on dotnet and other things.
My pc is not fast enough and I am not qualified enough, time sanbarrow .
I hope joakim get success on ghost14 with livexp which would solve the missing "thing", than rest of the gates becoming open one by one for livexp ......
or maybe....
#514
Posted 22 May 2009 - 11:28 PM
Oh dear - no. It only works in MOA because that environment allows "brute-force" approachs.
I am afraid that with dotnet3 the neat setup I used with dotnet2 will no longer work.
This is the first time I am really running into the 512 MB size-limit of the ramloading PEs
So in this case I created an 140 Mb installrite-package for dotnet3 on a clean 2k3-sp2 VM.
Then I applied this after using my regular dotnet2 LODR-pack to a running MOA.
I only needed to do this once as I captured the changes again with Installrite.
The new package now is only 17 Mb.
In regular use next time I only need to run
esx-tools-016.exe run
dotnet3-installrite.exe
and for this I can again use my smaller 280 MB ramloading images
As you see this has no finesse at all - this is real brute force.
#515
Posted 22 May 2009 - 11:39 PM
like= you need 2k3sp2 as source, bootsdi with ntfs, ramdrive with B: and these scripts enabled.....
well thanks for writing the things you've done. You know all i want is seeing "general" lodr packs around for some low numbered but good applications. If galapo was around i would probably have more time for this, but....
and you are a pro, i am only a non teenage non mutant non ninja regular turtle
#516
Posted 23 May 2009 - 12:39 AM
I'm around and keeping track of discussion, just don't have time for much other than this unfortunately. I hope to update a few scripts leter today if possible. I'll let you know if I do that.If galapo was around i would probably have more time for this, but....
Regards,
Galapo.
#517
Posted 23 May 2009 - 12:40 AM
In many cases this works like a charm - like this time.
I see no reasons why it should not work for you - if you create an installrite-kit while capturing a dotnet installation in a clean VM of XP-sp2 or sp3 or whatever you use.
Then apply it to a running LiveXP and take a regshot along - maybe next time you only need a reg-patch and inject some files.
With MOA installrite has made life much easier.
Yesterday VMware released the new dotnet3 based client - today - thanks installrite - it already runs.
http://sanbarrow.com...vsphere-moa.jpg
#518
Posted 23 May 2009 - 01:09 AM
Nice to see you around Boss .
with your absance on action, my todo list gets longer with my turtle speed .
todo list speed=turtle speed X 5 (or maybe X 10)
You know I just try to concentrate the most urgent ones and you know fxscrpt does the critical master ones. But i am not you, just try to get wheel keep turning. You just left in my crucial learning period....
@Sanbarrow
yep i used installrite packages with LiveXP, it worked for dotnet2 and probably would work for dotnet3.
Many times written before:
you have "strick rules" for your project. LiveXP project ives more freedom with more options....... etc etc.. Do you need pictures showing what can be done with LiveXP Freedom . I wrote many times the difference. Hopefully joakim like the idea of LODR with freedom which i like the same way too .
I dont have a found problem with dotnet2 (not tested on dotnet3) on LiveXP , i made many tests including a ready old script, installrite package, installing directly on %systemdrive%, installing with junctions to reduce required space on %systemdrive% etc etc etc. Many dotnet2 aplications always worked nicely
But i couldnt make joakim's ghost14 lodr pack work !!!! which annoys me a lot since without a working ghost14 (or any other dotnet required sophisticated aplication. nope not tested another than ghost14) having dotnet2 (or3) is a bit meaninglesss. Without its meaning it is not encouraging to make a dotnet script to make a ready lodrpack with installrite or other ways.
and working on vc2005 script always posponed with new todo lists... .
Well having slow pc with many todo list around stops me doing other dotnet tests. Time
#519
Posted 24 May 2009 - 12:00 AM
1. Junctioning ramloading bootcd with ntfs formatted ramdisk image. Have the files collected and a registry patch. Make junction points from %SystemDrive% and to your externally connected disk where your dotnet2 files are. Does not work with vista and 2k8 sources because of wim format limitations. Requires less space in X:\.
2. Have an Installrite Kit (or similar) for dotnet2 to install. Works with ramloading, FBWF and EWF, and will require anything from 40-80 Mb of free space, depending on how stripped down your dotnet2 is.
3. Have a plugin or script that includes dotnet2 at buildtime.
4. Application virtualization like with ThinApp. Will fail to load my symantec packages because of the kernel drivers and system services that it depends on, but thinapped dotnet will work on less compålex apps. Requires little space in %temp%.
I have not looked at dotnet 3.5 yet, but guess it's similar in structure to the previous versions.
Instead of installrite kits, you might just as well use your junction kit and modify the batch so you have 2 batches - 1 for ntfs formatted X and 1 for non-ntfs. Here's a link to the such a dotnet2 kit http://www.boot-land...?showtopic=7825. This way you don't have to have all the dotnet files saved twice in different packages.
About LiveXP;
I think you should expand the core to include more than you do today. It's a pain in the back to build upon, when it is so restricted to size. As I'm a newbie in winbuilder scripts, I had to LODR pack a bunch of system services when doing my tests. I'll come back with some suggestions for what to include.
#520
Posted 24 May 2009 - 01:33 AM
LiveXP is very flexible project including requirements/suggestions from the users.I'll come back with some suggestions for what to include.
Name what you require , you get my full support (as far as i can help).
I will be away for some days. I now know what first todo when I come back .
#521
Posted 24 May 2009 - 07:41 PM
The last one is a modification of number 2 that involves splitting the package in two, where the directory Microsoft.NET is placed externally and only the assembly & winsxs directories are located under %SystemRoot%.
This only makes sense when NOT dealing with junction points on ntfs formatted X:\. It means that roughly 61 Mb (without much optimization) can be placed outside of X:\.
The effect of this is that dotnet2 now is reduced to only 40 Mb uncompressed on the systemdrive.
There will now be 2 different registry patches needed. My dotnet2 package is to be updated accordingly.
Joakim
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users