D25Run version 0.2 - Duc Nguyen Trong
You can find the download link at: http://cdsp.iwebland.com
Discuss/Questions/Comments at: http://dhost.info/d25/forum/viewtopic.php?p=19
Remember that:
- Make sure you really close an application run by D25Run (close by Exit in its menu), not "minize" it by Close button of Windows so that D25Run can continue its jobs (because it will wait until app is really closed)
>> WHAT IS IT FOR ?
- Setup CAB files located in "Storage Card" (yes!) or in folder with spaces in name.
- For running programs which have spaces in its name & need parameters
(like: UnlockExtROM.exe with -unlock, -unhide, so that I can see my Extended Rom directory after a hard reset
- For importing registry file (uses KilmistRegEdit.exe <reg_file.reg>) so that I can restore all my settings (Owner info, settings, reg-code of apps) after a hard reset in flash ;-) You should merge all reg files into one for ease.
Example D25Run.txt
# This is command 1 (Register a REG file)
app=\Program Files\Kilmist Corporation\Kilmist RegEdit.exe
param="\My Documents\regme.reg"
# This is command 2 (install CAB file on Storage Card)
app=\windows\wceload.exe
param="\SD Card\D25Today.cab"
Have fun
XDA - Merge CABs
[Sorry for my english]
Works OK on BlueAngel.
I have 18 CABs in \Extended_ROM. They occupies 11.468.528 bytes. They can be merged into single CAB. It's size is 9.284.964 bytes.
Requirements:
- perl on windows [it will not work on unix nor linux sorry]
- cabwiz from Micro$oft
- some basic knowledge if command line, perl and cabwiz
- thinking
- "WinCE CAB Manager" will be very usefull.
- CABs to merge
---------
How to?
---------
Create clean directory.
---------
Create subdirectory ( I'm using .\[SCRIPT] ) and put there files:
CAB_merge.pl
CeSetup.dll
CheckFile.exe
Setup.DLL
Setup.DLL, CeSetup.dll and CheckFile.exe you can extract from any CAB from the \Extended_ROM
---------
Extract your CABs. One CAB == one directory. Be careful with "WinCE CAB Manager" - you will probably get directory named "Customization Tools". Rename them.
The result should look this:
+--[SCRIPT]
+--Album_BlueAngelAKU26_Generic_WWE_RC20
| +--[INSTALLDIR]
| +--[START MENU]
| | \--[PROGRAMS]
| \--[WINDOWS]
+--Album_EnableStreaming
| +--Windows
| \--[INSTALLDIR]
+--BandSel_BAWWE_140921.sa
| +--Windows
| \--[INSTALLDIR]
etc.
Don't worry if you got subdirs like "Windows" and "[WINDOWS]". Doesn't matter.
Look at attached file example_Tree.txt. May be it can help.
---------
Look for directories named "Temp". Read corresponding ..\Windows\_MoveFileList.txt and move files to their original locations. For example: move Temp\_HTCCamera.dll into ..\Windows\_HTCCamera.dll. (!) Don't remove underlines from name.
---------
Try to find duplicates. Decide, which one is too old (look at the time stamps or file-version - rigt_click/properties/version). Don't delete the old one - simply rename and put '~' on the beginning of the name. For example ~Album.exe. Such files will be ignored. If you can't find duplicates - don't worry. CAB_merge.pl will show you.
---------
Find files, which are not needed. For example "WESTTEK Native Office
Viewers.ppt" or "WESTTEK-Product Info.pdf" from ClearVUE. Rename them - put ~'s on the beginning of the name.
---------
Look at *.LNK. They will be imported as shortcuts, not files. If you wish
to have LNK files - edit them. For example Abum.lnk containing string:
20#"\Windows\Album.exe"
put 999 instead of the number:
999#"\Windows\Album.exe"
You will have to modify LNK files, if target file does not exist within the CAB.
---------
Look for files CM_Entries.xml. If you dont have any CM_Entries.xml, skip this step. Probably the best version of CM_Entries.xml can be found in your XDA in the \windows directory. Rename all CM_Entries.xml to ~CM_Entries.xml - they will be ignored. Create directory .\My_CM_Entries\Windows and copy here
CM_Entries.xml from your device. Maybe wiki can help.
---------
Some rules:
Files:
[INSTALLDIR]\CeSetup.DLL
Setup.DLL
[WINDOWS]\CheckFile.exe
[WINDOWS]\Customize.lst
[WINDOWS]\_MoveFileList.txt
will be ignored.
Files:
~*.*
*.BAK
will be ignored.
Files
_*.*
will got destination \Temp and will be listed in [WINDOWS]\_MoveFileList.txt. CeSetup.DLL will move them into appropriate directories, even if they are in use or locked. You will have to reboot your XDA.
File
\Windows\Platformxxx.reg or
[WINDOWS]\Platformxxx.reg
will be imported
File
*.inf
Registry and shortcuts will be imported. Other sections - copyFiles, Version, CeDevice will be ignored
Files
*.lnk
will be imported if possible.
---------
Execute: perl [SCRIPT]\CAB_merge.pl.
If nothing fails - you will get BA.INF in the current directory. In some cases, you will get Customize.lst, Platformxxx.reg _MoveFileList.txt too.
Execute: Cabwiz BA.inf /err CabWizErr.txt /cpu arm
If nothing fails - you will get BA.arm.cab
Read file CabWizErr.txt - check all warnings.
Look at BA.arm.cab. Check everything.
If everything looks ok, copy BA.arm.cab into your device.
Reset the device.
Try to install BA.arm.cab
If you get any message, that fil cann't be copied - skip them, go back to your source files and rename file - add underline's at the beginning. Remake everything:
perl .\[SCRIPT]\CAB_merge.pl
Cabwiz BA.inf /err CabWizErr.txt /cpu arm
copy
restart
install
and so on.
If everything looks ok: modify CAB_merge.pl modify line
$main::cpFileFlag = 0x00000001;
to have
$main::cpFileFlag = 0x00000002;
and remake CAB:
perl .\[SCRIPT]\CAB_merge.pl
Cabwiz BA.inf /err CabWizErr.txt /cpu arm
Your CAB is ready. Replace source CABs from \Extended_ROM with reult of your effort. Remember to modify \Extended_ROM\config.txt.
Need customization? Look at the begining of CAB_merge.pl
Good luck.
[ Based on plenTpak's already great AutoInstall4 (2008/03/28) ]
The scripts included here require MortScript and are intended to help automatically install and configure software, copy files and folders, and import registry and provisioning stuff - this all with little or no user interaction!
So should you need to install a new ROM or install new software versions, just go ahead and let User Customization take care of the rest...
Usage:
Unpack SDConfig.txt and scripts to storage card (and review them )
Dump any install files (silently installable only!), script files (e.g. to process the interactive install files, see further), registry files, provisioning files, and files and folders to copy, into the AutoRun subfolder.
Hard-reset, or start the RunAutoRun script
Hope this makes things easier for some people!
By default, it uses this file structure:
Code:
_ Storage Card\
|_ SDConfig.txt
|_ SDConfig\
|_ <MortScript cab>
|_ AutoWait.mscr
|_ AutoRun.mscr
|_ AutoRun\
|_ <your stuff here>
I rarely need to change my SDConfig file anymore and I just drop all of my AutoRun stuff (cab/mscr/zip/reg/xml files and also regular files and folders) in the dedicated AutoRun folder, it's that easy!
The AutoRun folder may contain any or all of the following:
cab files to install silently and mscr scripts to run,
regular files/folders to copy,
zip archives to unpack,
reg files to import,
xml files to concatenate.
All is processed (and logged!) in the same order as listed above, with all items sorted alphabetically first.
After installing, files are copied/unpacked, then registry files are imported, and finally the xml files are concatenated into a single provisioning file that is called by SDConfig.txt.
Here are some important notes for each item:
I use scripts to install the more interactive cabs: e.g. instead of putting Fringcab.cab here, I put a Fringcab.mscr here, and move Fringcab.cab elsewhere (i.e. a sibling folder called "Interactive"); my Fringcab.mscr installs Fringcab.cab but then also takes care of the interactive installation part of it.
The "regular" files are files that do not fit the other categories (cab/mscr/zip/reg/xml); regular files/folders found here will be xcopied to the root folder on the device (creating folder structure if necessary) - quite like plenTpak explained here.
Zip archives are unpacked to the root folder on the device (creating folder structure if necessary); zip archives are smaller to store, but unpacking is less tolerant than xcopying when it comes down to read-only or system files and such...
Not thoroughly tested the registry import since I use xml files for registry changes also; if I recall correctly from my brief testing, I believe the reg file should not be unicode for the script to be able to parse it correctly, so mind the encoding!
A provisioning file is always generated, so that SDConfig does not fail on a missing file.
About the AutoWait script: see here and here. To summarize roughly: 1 AutoWait call is needed for each full 3-minute block that your AutoRun requires to run. Apart from extra run time, it will not do any harm to add extra AutoWait calls to your SDConfig file.
Remark: The AutoRun script can take a parameter to use a custom sibling folder instead of the default AutoRun folder (e.g. a folder "Games"), but I failed to pass that parameter directly from SDConfig. However, yet another script can take care of that, as follows:
create a script for each custom folder (e.g. a script "Games.mscr"), with the following contents:
Code:
CallScript( SystemPath("ScriptPath") \ "AutoWait.mscr" )
CallScript( SystemPath("ScriptPath") \ "AutoRun.mscr", SystemPath("ScriptName"), "^NL^^NL^ processing " & SystemPath("ScriptName"), & "..." )
adapt the SDConfig.txt file to copy and call the new script(s) just created (which in turn will call the original AutoRun script, so do not forget about AutoWait here too!)
A RunAutoRun script is also included in the zip file, to test the SDConfig/AutoRun without hard-resetting your device.
Personally, I use MortScript-4.11b7-PPC.cab and these scripts together with ROMS using SDAutorun v2.0 - and I only have my Trinity to use it on.
Main related links:
MortScript
AutoInstall4
User Customization
SDAutoRun v2.0
Use all at your own risk!
[ reserved ]
The script does not check if it is run manually or automatically, nor does it check the mortscript version it runs with, nor does it actively try to avoid double installation of mortscript, but feel free to post your own code to include these interesting features. Another feature could be to automatically detect the name of the storage card root folder in order to support different languages...
thank you mousio tested with xml, cabs, and folder/files.. very good
Great idea! Automating the automated process of SDAutoRun!
Taking the automated process to next level . AWESOME!!! . you developers are not going to let me get me out of cooking frenzy
The script does not check if it is run manually or automatically, nor does it check the mortscript version it runs with, nor does it actively try to avoid double installation of mortscript, but feel free to post your own code to include these interesting features. Another feature could be to automatically detect the name of the storage card root folder in order to support different languages...
Click to expand...
Click to collapse
If I can find some spare time for this...
Thanks for this tool!
I've only got one issue with it, and that is AutoWait related. It seems that after 6 minutes (I'm installing a lot of cabs), SDAutorun continues to execute the rest of SDConfig.txt, it complains about a missing AutoRun.xml (as the AutoRun.mscr hasn't generated it yet), then the device hangs.
Reading your instructions, it seemed that the solution would be to add more lines of EXEC:\Temp\AutoWait.mscr to the SDConfig.txt, but this appeared to have no effect at all!
If there is any other possible solution for dealing with long-running scripts, I'd love to hear it.
Alex
Would splitting them up into sub scripts work better?
Cuts down the time for each script, but may be more complex.
mousio said:
If I can find some spare time for this...
Click to expand...
Click to collapse
Here is the code that seems to work for me with regard to StorageCard location for international people.
Code:
# STORAGE CARD PATH
Sub StorageCardLogic
If (Length(RegRead("HKLM","System\StorageManager\Profiles\SDMemory","Folder")) > 0)
StorageCardPath = "\" & RegRead("HKLM","System\StorageManager\Profiles\SDMemory","Folder")
ElseIf (Length(RegRead("HKLM","System\StorageManager\Profiles\SDMMC","Folder")) > 0)
StorageCardPath = "\" & RegRead("HKLM","System\StorageManager\Profiles\SDMMC","Folder")
ElseIf (Length(RegRead("HKLM","System\StorageManager\Profiles\PCMCIA","Folder")) > 0)
StorageCardPath = "\" & RegRead("HKLM","System\StorageManager\Profiles\PCMCIA","Folder")
EndIf
EndSub
Storage Card logic
Long time no post
Based on several sources, including yours, this is now similar to what is in my latest version:
Code:
RegStorageCard1 = RegRead( "HKLM", "System\StorageManager\Profiles\SDMemory", "Folder" )
RegStorageCard2 = RegRead( "HKLM", "System\StorageManager\Profiles\SDMMC", "Folder" )
RegStorageCard3 = RegRead( "HKLM", "System\StorageManager\Profiles\PCMCIA", "Folder" )
RegInternalStorage = RegRead( "HKLM", "System\StorageManager\Profiles\moviNAND", "Folder" )
RegAutoPart1 = RegRead( "HKLM", "System\StorageManager\Profiles\moviNAND", "AutoPart" )
RegAutoPart2 = RegRead( "HKLM", "System\StorageManager\Profiles\moviNAND\FATFS", "AutoPart" )
If( RegAutoPart1 = 1 || RegAutoPart2 = 1 )
storagecard = "\" \ RegInternalStorage
ElseIf( NOT IsEmpty( RegStorageCard1 ) )
storagecard = "\" \ RegStorageCard1
ElseIf( NOT IsEmpty( RegStorageCard2 ) )
storagecard = "\" \ RegStorageCard2
ElseIf( NOT IsEmpty( RegStorageCard3 ) )
storagecard = "\" \ RegStorageCard3
Else
storagecard = "\Storage Card"
EndIf
Anyone know the command please!
Thanks a lot
Code:
LOCK:Enabled lock the device so no user action is possible
CAB: \Extended_ROM\... install a CAB file use
EXEC:\Extended_ROM\... execute a file
CPY1:\Extended_ROM\sourcefile specify source for copy command
CPY2:\windows\targetfile copies CPY1 file to target
XML: \windows\... execute a provisioning XML file
LOCK:Disabled unlocks the device
RST: Reset execute a reset at the end
CFG: \Storage\Config2.txt include configuration from another file e.g. Config2.txt (same syntax as Config.txt)
HIDE:Enabled hides the autorun screen so that user interaction can take place.
HIDE:Disabled shows the autorun screen after user interaction.
SHOW:\Extended_ROM\... shows the image specified as the background to AutoRun. Must be a bmp.
TSK: \Windows\... Makes a theme the default theme. Works on Diamond/Raphael shipped AutoRun only!
zd_lc said:
Anyone know the command please!
Thanks a lot
Code:
LOCK:Enabled lock the device so no user action is possible
CAB: \Extended_ROM\... install a CAB file use
EXEC:\Extended_ROM\... execute a file
CPY1:\Extended_ROM\sourcefile specify source for copy command
CPY2:\windows\targetfile copies CPY1 file to target
XML: \windows\... execute a provisioning XML file
LOCK:Disabled unlocks the device
RST: Reset execute a reset at the end
CFG: \Storage\Config2.txt include configuration from another file e.g. Config2.txt (same syntax as Config.txt)
HIDE:Enabled hides the autorun screen so that user interaction can take place.
HIDE:Disabled shows the autorun screen after user interaction.
SHOW:\Extended_ROM\... shows the image specified as the background to AutoRun. Must be a bmp.
TSK: \Windows\... Makes a theme the default theme. Works on Diamond/Raphael shipped AutoRun only!
Click to expand...
Click to collapse
Why don't you set a wallpaper in a reg file or a rgu file?
(don't know which key and slot, but that would be pretty easy to find)
Really!? can it work?
I change the app.reg file
It dont work at all
why?
tighter specifications for config.txt and other customizing files
big sorrow, my huge and complicated customization failed on new rom.
after a dozen reflashing I finally located problem.
IN NEW ROMs, there is "RunCC" app which completely replaces "autorun" (autorun.exe and associates are not present)
- "RunCC" is by default using script files, with the same names as were in ROMs customized by "autorun" (config_operator.txt, config.txt...)
- commands used in script files in "RunCC" are compatible with commands from "autorun", but many are not supported, look below
why we need customization on the first place?
- as our custom roms are already customized of course, we don't need it for the same reason as it was meant to be used,
but as customization is executed right after initialization of a new rom, and before any of other startup apps or today screen plugins that's making it a good tool for running little scripts with user choices, or programs registering scripts, or registry, notification, file changes.
advantages of RunCC:
- more flexible for operators, OEM companies, and parties doing customization
if there is bug in one of script txt files, (or it's missing) customization will continue with next file
every operator has assigned it's config*.txt file, now if one have bug, other would still run
- change priority for executing script files
- can execute config*.txt files from SD cards without custom made sdAutoRun.exe
* well, except the option of running SD configs, there's isn't much advantage in all this for us cooks, as there is only one customizer-the cooker
disadvantages:
- not supporting HIDE: and LOCK: commands - not possible to use with user-input type customizing apps
- can't redirect script files to each other (command CFG
files to be run are defined in special file (with kind of basic C++ commands): RunCC.lua
this could lead to possible conflict with creating file of the same name + troubles if someone like me is trying to use his own config_papo.txt script file, like he was used to. This leads to personal damage in wasted time, electrons and burned out nerve cells
==================================================
scheme as scripts are usually executed by "autorun" customization:
[HKEY_LOCAL_MACHINE\COMM]
"AutoRunCFG"="\\Windows\\<config>.txt"
* not applicable with RunCC
|
v
config_operator.txt
|
v
config_PT.txt
|
v
config_AP.txt
|
v
config_end.txt
|
v
config.txt
last line in every file have to contain "CFG: \windows\<next_cfg_file>.txt
last one should contain:
LOCKisabled
RST: Reset
* disabling lock on end should make next start complete (without need to start by clicking on start)
==================================================
by "RunCC" customization:
RunCC.lua file: defines all possible script (config*.txt) files, and priorities of excuting with parameter:
RunDefault, RunExtra, RunCustomer (I didn't check on the order, I suppose 'RunDefault' is first)
by default, all script files, as you can see them above are defined, if you use any of them, your commands will be executed, if you use file with different name it won't even if you try to redirect by CFG: command (need to edit RunCC.lua)
CFG:, LOCK:, HIDE: is ignored with RunCC
==========================================
commands:
LOCKisabled -- enable user input (it's semicolon followed by big D letter of course. don't put smilie there like it's shown here)
LOCK:Enabled -- disable user input
HIDE:Enabled -- hides windows logo, background process could be seen HIDEisabled -- covers it back
* if only HIDE:Enabled, status will still not show running program name - if you running scripts which calls on app names, you need LOCKisabled too for them to work
* HIDE: pair (maybe LOCK as well) can't be used twice in one txt file (process would stop)
* LOCK & HIDE don't work with the new autorun
CAB: \windows\... --- install CAB
EXEC:\windows\... --- exe file
XML: \windows\... --- provisioning XML file
CFG: \Storage\Config2.txt --- continue with another autorun, txt file. need to be specified on the last line
TSK: \Windows\... --- theme tsk (not working in all versions of "autorun", not with RunCC)
FILEOP:\windows\... --- New format for file operations files (it's possible it only works with RunCC)
CPY1:\windows\source --- copy (source file)
CPY2:\windows\folder\target --- copy (target file)
RST: Reset --- perform reset
SHOW:\windows\... --- shows custom image file during process. Must be BMP
* note that three letter commands have space after semicolon, in new version of autorun it's not needed, but why not rather using it.
* first file (usually config_operator.txt) is unicode, the rest of it is usually ansi, but could be unicode as well.
* common mistake is using parameters - NOT ALLOWED
* spaces - SDAutorun can handle them (I didn't test for "autorun")
if you need parameters, call mortscript's renamed autorun.exe file which would call the same named script where you could put RUN command with program name and parameters
---
SDAutorun:
you can continue, on SD card having your cab files there to be installed after flashing someone's custom ROM, his ROM has to be "comatible". That is done by adding "sdautorun.exe" and command EXEC:\windows\sdautorun.exe in script file.
(search for sdautorun)
==================
My conclusion is, we don't need RunCC and we want back our old good "autorun"
1. disable RunCC ext package
2. download "autorun" attached to this post. it consist of three EXTs. include all three of them
3. in "Autorun" EXT I added reg entry to disable "RunCC" as this is being run in "init" section which is organized with chaotic style by assigning random numbers 1-100 to each app and hoping to not hit the same twice, you need to check with your rom if RunCC has the same as in my case: 58
if you don't remove entry to run "RunCC", nothing wrong would happen, it's just not healthy in general to have shortcuts to nonexistend exes to be run every start.
I am working on the attachment. will add it later today/tomorrow
Interesting info thanks could you please upload some examples as this is all new to me
Many thanks [email protected]
sure, still trying to get more from it. then I'll upload that substitutive autorun I promised before.
examples.. you can find it in your phone, search config*.txt files in windows folder
or for runCC the file: runcc.lua - windows folder or
in OEM - ControlBlock