21 replies to this topic

[allanf]

Swimming against the tide...



These scripts use only native WinBuilder Commands... no derived "API" Commands.

They contain one encoded file... the license, which is slightly hidden due to a spelling mistake. It can be viewed with the GUI "View License" Button.

Other files are downloaded on the first use (with a bit of luck), and stored in a newly-created folder called "appy_Archives".

The GUI allows the option to encode the downloaded files/archives, or the extracted files, or delete all encoded files (except the license).

A list of encoded files can be viewed with the "View Encoded FileList" Button. It may take a moment.

Extracted files are placed in a newly-created folder, which is named by the %ProgramFolder% Variable. To avoid possible conflicts with other scripts, it might be safest to place the script(s) in a new or unused folder inside "Apps". The extracted-file folder (or "Source Folder") can optionally be deleted.

Sysinternals Suite



Some things don't work in VistaPE. Help files don't work... yet! There is a link to a "Sysinternals Command Prompt".




EDIT: For xCHM (a chm file viewer) see the attached 'xxCHM.script' in a later post.


notepad++



Preconfigured with five different languages... can be changed by altering the "list" in the Variables Section... not enough room in the GUI.
Context Menu ("Edit with notepad++") doesn't start up automatically with Explorer Shell, but starts (twice!) with Litestep.




Foxit PE Launcher
Apparently Foxit PE Launcher is useful for Removeable Drives... I don't have one.




WinDirStat



This program is amazing!




ImgBurn



Tested in VirtualBox with a special "experimental" VBManage switch (dvdpassthrough ?), and it broke my disc. Otherwise very reliable. Thanks to LightningUK! for this and the outlawed sibling.




FSCapture53
I haven't seen the free FSCapture53 on any official web-sites.




Good Luck!

[Brito]

Hi Allanf!

Wish you'd really consider using API - do you have dificulties in using it?

I can explain whichever steps necessary - it's quite simple.

This means that your work is only available to VistaPE as it is right now - nobody knows if it will work over the next months in improved vistape versions and will surely never become available for XP based projects or any other project in the future since it uses static scripting..

Thank you for posting all these utilities but could we have an api version please?

[allanf]

... This means that your work is only available to VistaPE as it is right now -

Do you plan to change WinBuilder's Commands? If not, the scripts will always work.... I think?

Thank you for posting all these utilities but could we have an api version please?

.... hmmm. I'll try. Some of the programs are available as "Application Scripts" anyway.

.... just if anyone wanted to have the ability to view the encoded files or the license with a single button, or switch between the encoded files - archives or extracted. I can't see how that can be done with the API Commands (at the moment).

[pscEx]

Do you plan to change WinBuilder's Commands? If not, the scripts will always work.... I think?



.... hmmm. I'll try. Some of the programs are available as "Application Scripts" anyway.

.... just if anyone wanted to have the ability to view the encoded files or the license with a single button, or switch between the encoded files - archives or extracted. I can't see how that can be done with the API Commands (at the moment).

Let me give an additional hint.

The current script provides the option to run from RAM.

For some of the Sysinternals Apps this is necessary, because they want to install internal ressources as drivers (e.g. FileMon)

In an (current) API based script this would really crash in all XP ISOs w/o BootSDI or FBWF.
I think, to handle this by API is very difficult, if not even impossible.

There are apps suited to use the API, and there are apps which can only be scripted as API-free.

We should not think comparable with:

We must save money, neglecting how much it costs!

Peter

[Brito]

Thank you for considering an api version.

.... just if anyone wanted to have the ability to view the encoded files or the license with a single button, or switch between the encoded files - archives or extracted. I can't see how that can be done with the API Commands (at the moment).

You don't need any api command for these actions because they don't involve any interaction with the project.

Api commands are used when you need to copy/extract files to the respective program folder or simply create new icons.

They are used (based on the above examples) because the target program files folder name can change according to each language and the target OS can use other shells like xoblite, bblean, explorer, yzdock, etc.

We use API command mostly because it makes each project responsable for knowing best how to handle these decisions.

The developer only needs to ask for a shortcut to be created and unpack files on the programs folder.

---------
And I also agree with Peter's arguments.

[allanf]

Hi Peter,

There is no need to worry about Filemon in VistaPE...



... same with Regmon.

... and Process Explorer works beautifully.

Thanks for the hint anyway.

However, there is a problem with Autoruns, but not with AutorunsC (Command Prompt).




... and RootKitRevealer doesn't start at all.

Really, there is nothing that these scripts do that can't be done by the API Commands, except for the GUI functionality. The plan was to be able to simply type the name of the application and it's download address into the GUI, and away you go. But it is not so easy. Every program seems to have a quirk!

[pscEx]

Every program seems to have a quirk!

With the stress on 'Every'

Peter

[allanf]

With the stress on 'Every'

Peter

You can say that again!

I just did a quick compare of some matching scripts. Since no-one has been too critical of those scripts, I assume that they might fall into the category of "Application (or API) Scripts". Not sure.



1. WinDirStat.script from the Downloads => Application Scripts.... no option to Run from RAM - is this a feature that defines an Application Script? Also requires at least one System File (oledlg.dll). Failed to open. Desktop and StartMenu Shortcuts OK.

2. BGInfo.script from the VistaPE 010 Server.. option to Run from RAM selected, and program went to RAM ProgramFiles Folder, but StartMenu Shortcut never found it. Error. No Desktop Shortcut.

3. FreeFSCapture53.script (by PedroLe15, not the original by me), an API Test Script from VistaPE 010 BETA Server (now disappeared)... no option to Run from RAM. The Desktop Shortcut has no Icon. Opens FSCapture as just a Title Bar stuck in the corner of the Desktop... how to run it?

4. Process Explorer from VistaPE 010 Server. Option to Run from RAM selected, and that is where it went. No problems.

5. Process Monitor from VistaPE 010 Server. Option to Run from RAM was selected, but it ended up stuck on the CD! (Same thing happens with VistaPE 010's Dependency Walker which I use a lot.) No Desktop Shortcut but StartMenu Shortcut found it on the CD and it runs OK... until it ran out of resources!

(I also thought that there was an ImgBurn "Application Script" to compare but can't find it?)

Anyway... Like my school report cards - "Showing improvement, but can do better!"

[allanf]

1. WinDirStat.script... requires at least one System File (oledlg.dll)....

Come to think of it... I suppose that it is the same with my script. Oops.



Put a tick/check/mark in the box, and type in the dll.

[phox]

Come to think of it... I suppose that it is the same with my script. Oops.



Put a tick/check/mark in the box, and type in the dll.

@allanf.

Your script is excellent template for application scripts.
It is most universal solution I have seen up to now!

I suggest that you offer it to Pedro to adapt his MakeScript
generator accordingly.

Thank you for great solution!

[Galapo]

Your script is excellent template for application scripts.
It is most universal solution I have seen up to now!

I suggest that you offer it to Pedro to adapt his MakeScript
generator accordingly.

I am at a loss to see how this is an example of an "application script" as the script contains no api commands and is basically vistape-specific.

For example, much of the system file copying could be replaced by a require_file call, shortcut generation by a call to Add_Shortcut, etc etc.

Regards,
Galapo.

[allanf]

I am at a loss to see how this is an example of an "application script" as the script contains no api commands and is basically vistape-specific.

For example, much of the system file copying could be replaced by a require_file call, shortcut generation by a call to Add_Shortcut, etc etc.

Regards,
Galapo.

@phox,

Thank you so much. I am glad that someone appreciates the concept.

@Galapo,

The idea came when I first started using WinBuilder six or so months ago. Pedro Le 15's api.script was in it's infancy. And API Commands were undocumented and all-over-the-place. For a novice, it was mind-boggling. You are right. The scripts are far from "Application Scripts". All the Commands come from WinBuilder Editor's drop-down list. (The 'log.html's incorrectly state "call ...\api.script" for some things like "ExtractAllFiles".) The only purpose was to present a GUI rather than script to perform the same functions as the api. It wouldn't be too hard to make it an api script, but that is where I would be really "swimming against the tide".

The recent additions of "View License" and "View Encoded FileList" came from a suggestion by jaclaz in a stoush about licencing and redistribution of programs.

The ability to Download on first run came from the fact that I am on DialUp. Half the scripts around here start off with MBs of encoded files, which I can't download. And I've probably already got those encoded files floating around here somewhere, anyway. Once downloaded, the archive files (sometimes the executable file) are stored and can be encoded, unencoded, switched with extracted files, deleted , whatever suits. I should have mentioned that, if someone already has the archive, it can be placed in the '%ScriptDir%\appy_Archives\%ProgramFolder%\Folder' (I think), and the Download won't happen, and the script will extract the archive from there.

And it is just for VistaPE. Where do the XP-Projects put extracted files? What is the XP-Project's most basic (non-API) set of Commands for running a program in RAM?

Regards

[Galapo]

It wouldn't be too hard to make it an api script, but that is where I would be really "swimming against the tide".

Yes, you are right: it wouldn't take much. But it still would need to be done... Depends if you want to make it more compatible -- and it's OK if you don't. For me, I just hope that my scripts are compatible. But I will have to fire up VistaPE in time...

The ability to Download on first run came from the fact that I am on DialUp. Half the scripts around here start off with MBs of encoded files, which I can't download. And I've probably already got those encoded files floating around here somewhere, anyway. Once downloaded, the archive files (sometimes the executable file) are stored and can be encoded, unencoded, switched with extracted files, deleted , whatever suits. I should have mentioned that, if someone already has the archive, it can be placed in the '%ScriptDir%\appy_Archives\%ProgramFolder%\Folder' (I think), and the Download won't happen, and the script will extract the archive from there.

Yes, I like what you've done here. I'm only on the slowest version of broadband myself, so I prefer to offer options in addition to download.

And it is just for VistaPE. Where do the XP-Projects put extracted files? What is the XP-Project's most basic (non-API) set of Commands for running a program in RAM?

Extacted files are placed wherever this is specified, eg %Target_prog%. A program cannot be made to run "in ram" like VistaPE. BootSDI or fbwf gets around this to some extent.

Regards,
Galapo.

[allanf]

Yes, you are right: it wouldn't take much. But it still would need to be done... Depends if you want to make it more compatible -- and it's OK if you don't. For me, I just hope that my scripts are compatible. But I will have to fire up VistaPE in time...

I was hooked on VistPE for one reason - the ability to run the OS in RAM along with one program in particular - Ghost32. With a Laptop, no external drives and a single CD/DVD writer, I can run Ghost and burn the Images to CD/DVDs swapping them in and out. (OK. Ghost32 on HDD can do this alone by re-booting to it's Virtual Partition.) I'm afraid that I have never "progressed " to the XP-Projects.

It is theoretically possible to convert scripts to the GUI-style by just having the GUI "Interface Section" code (i. e. the %pFileBox[es]%, etc) and calling the rest of the script. But as I mentioned to Peter, every program has its quirks. The most important is how the Archive File extracts, and this is really evolving big-time with 7z.exe. Who knows where the Executable and ancilliary files are going to end up when extracted? So the copying of files to VistaPE will need, in many cases, some hard-coding.

Yes, I like what you've done here. I'm only on the slowest version of broadband myself, so I prefer to offer options in addition to download.

To avoid a download, the Archive File in the local appy_Archive folder needs to be precisely the same as the filename in the Download Link. It may also be possible to Update/Upgrade a program by simply changing the Download Link on the GUI. The scripts should run stand-alone without errors. So, it is possible to delete the encoded files by running the script alone. All that happens, is the Extractions/Unpacking and FileCopies to %TargetDir%.. good for testing the results.

BTW, that's "appy..." as in "'ow ya goin'? 'appy?". It had to be unique to avoid any possibility of a conflict with nearby folders called "Archives". It's the first word that came to mind.

Extacted files are placed wherever this is specified, eg %Target_prog%. A program cannot be made to run "in ram" like VistaPE. BootSDI or fbwf gets around this to some extent.

What I meant was like "Where, exactly?" Is it like XP on HDD '[Drive Letter]:\Program Files' => '%TargetDir%\Program Files'? ...same as VistaPE's RAM Folder? ....hmmm.

Regards

[phox]

I am at a loss to see how this is an example of an "application script" as the script contains no api commands and is basically vistape-specific.

For example, much of the system file copying could be replaced by a require_file call, shortcut generation by a call to Add_Shortcut, etc etc.

Regards,
Galapo.

I have given my opinion based on GUI.

It has everything to make new application script
just by filling the boxes with essential information.

I have already made few new scripts.

Of course, api is missing, but I am sure allanf will adapt it to be universal.

[allanf]

@Galapo,

I had a look at converting your xCHM script. I didn't know before downloading that this is program whose archive is beautiful - two files that unzip and go straight into the Program's Folder. So no messing around to rearrange folders and files. It's a very handy program as well!

In the end no part of your script could be saved except your name! Here it is totally hacked out.

Sorry! Deleted attached script. It was very bad.

It is a test script and has no GUI except for the buttons. I wanted to see how the variables passed to external scripts. It requires the following in the same folder.

Deleted!

Things should go faster if the interface variables (%pTextBox[es]%, etc) are passed as they are, and not needlessly set to other variables like %ProgramExe%, etc.

It has only been tested with VistaPE.



Something strange happened to the Shortcuts, and they didn't work. I received the following in the log.

TxtAddLine - Added line: [C:\winbuilder\Target\VistaPE\windows\system32\shortcut.inf] line: [!PDC\xCHM\xCHM.exe,!DS\xCHM.lnk,!PDC\xCHM,,] Option:".chm help file viewer",!PDC\xCHM\xCHM.exe,normal""

Compared to the following for the SysInternalsSuite script.

TxtAddLine - Added line: [C:\winbuilder\Target\VistaPE\windows\system32\shortcut.inf] line: [!PF\SysInternalsSuite\ZoomIt.exe,SysInternalsSuite\ZoomIt.exe.lnk,!PF\SysInternalsSuite,,,!PF\SysInternalsSuite\ZoomIt.exe,normal] Option:"Append"

@phox,

I really thought that these scripts would simply pass into the mists of time. Thanks again. "Universal"?! That's a big ask!

[phox]

I really thought that these scripts would simply pass into the mists of time. Thanks again. "Universal"?! That's a big ask!

Don't worry!

See samples of my api "universal" scripts.
They work OK in LiveXP and VistaPE projects.

Use them to adapt your scripts, please.

 BackUp.zip   3.78KB   327 downloads

[allanf]

Don't worry!

I see! It shouldn't be too difficult to incorporate API comands into the GUI scripts... a happy compromise! I hope I understand you correctly.

[Galapo]

@Galapo,

I had a look at converting your xCHM script. I didn't know before downloading that this is program whose archive is beautiful - two files that unzip and go straight into the Program's Folder. So no messing around to rearrange folders and files. It's a very handy program as well!

In the end no part of your script could be saved except your name! Here it is totally hacked out.

The changes you made I think were unnecessary. Here's the modified sections which follow's Pedro's suggestions to me on another script:

[Interface]

pCheckBox1="Add desktop shortcut",1,3,43,72,185,18,False

pCheckBox2="Add start menu shortcut",1,3,43,126,168,18,True

pCheckBox3="Add quicklaunch shortcut",1,3,43,99,180,18,False

pTextBox1="Start menu folder (blank for none):",1,0,43,165,168,21,

pBevel1=pBevel1,1,12,27,57,198,207

CheckBoxRam="Run from ram (boot.wim)",1,3,60,221,146,18,False

pTextLabel1="- For VistaPE only -",1,1,75,201,119,18,9,Normal

pBevel2=pBevel2,1,12,50,196,156,50



[process]

RunFromRam,%CheckBoxRam%

unpack,%encodedfolder%

If,%pCheckBox1%,Equal,True,Add_Shortcut,Desktop

If,%pCheckBox2%,Equal,True,Add_Shortcut,StartMenu,%pTextBox1%

If,%pCheckBox3%,Equal,True,Add_Shortcut,QuickLaunch

associate_file,chm,open

Something strange happened to the Shortcuts, and they didn't work. I received the following in the log.

TxtAddLine - Added line: [C:\winbuilder\Target\VistaPE\windows\system32\shortcut.inf] line: [!PDC\xCHM\xCHM.exe,!DS\xCHM.lnk,!PDC\xCHM,,] Option:".chm help file viewer",!PDC\xCHM\xCHM.exe,normal""

Shortcut generation is handled solely by the api. Either there is a bug with the VistaPE version, or you are using an older version which requires updating.

Hope this helps.

Regards,
Galapo.

[allanf]

The changes you made I think were unnecessary. Here's the modified sections which follow's Pedro's suggestions to me on another script:

@Galapo,

Thanks for the snippet. The code works well with VistaPE when running the Program from RAM. Excellent! One minor issue... the File-Association Icon is not working. In Vista, the "Magnifying-Glass" icon means no association. However, the Association is definitely there.

Shortcut generation is handled solely by the api. Either there is a bug with the VistaPE version, or you are using an older version which requires updating.

My scripts use no API Commands whatsoever! In fact, during testing, I rename api.script to make sure that it is not called by my scripts.

The problem with the Shortcuts was that I didn't read my own instructions... "No Punctuation" in the Program Description (the "Tool Tip", I think it's called.) It was the dot in ".chm help file viewer".



Also, as far as I am aware, VistaPE uses a different api.script to LiveXP. I assume that they have the same functionality. For a brief exchange between NightMan and PedroLe15, see this: VistaPE new site and new version (version 010 BETA), 08.10.2007; Post # 56:

"....

QUOTE (Pedro)Have you try my Api as it is ? I think it will be faster than your
NightMan : sorry, no "

BTW. I deleted those test scripts. They were pretty bad. Attached is the "Archaic API-free *GUI*" script.

[Galapo]

Thanks for the snippet. The code works well with VistaPE when running the Program from RAM. Excellent! One minor issue... the File-Association Icon is not working. In Vista, the "Magnifying-Glass" icon means no association. However, the Association is definitely there.

There is a bug here with the LiveXP and VistaPE APIs. I've posted Pedro concerning this, so hopefully it will be addressed soon. Funny thing is, the bug doesn't concern the icon association part but the executable association...

(Pedro)Have you try my Api as it is ? I think it will be faster than your
NightMan : sorry, no "

Hmmm. I didn't know there was different VistaPE APIs. Perhaps the above issue stems from this. My scripts assume the use of Pedro's api.

Regards,
Galapo.

[allanf]

I see! It shouldn't be too difficult to incorporate API comands into the GUI scripts... a happy compromise! I hope I understand you correctly.

Well. It was four o'clock in the morning here...

In the meantime....

Norton Ghost is not for the faint-hearted - without care, terrible things can go wrong!

The script requires Ghost32.exe (also known as RestoreGhost.exe on some Symantec Recovery Disks - rename it), identified as version 8.2.x.xxxx, and Ghostexp.exe. Both Executables should be placed in a folder named "NortonGhost" which should be created next to the script (that is, in %ScriptDir%).

EDIT: Do not select to Delete the Source Files unless you have a backup of the Executables!

Tested only with VistaPE running in VirtualBox with Ghost Image Files on DVD in the Host Drive. ... using the experimental 'VBoxManage -dvdpassthrough on' switch.



Well. I'm not sure if Ghostexp works, and the Ghost Images on the DVD did not verify...



EDIT. OK. One problem testing in VirtualBox - VB does not lock control of the Host CD/DVD Drive. Switching out of VB to Host system causes big trouble.
Also note for screenShot - DOS Ghost in "Virtual Partition" formats a DVD as CDF. Windows sees the CDF Format and thinks that the DVD is a CD! And shows incorrect capacity 700MB.