[Windows Mobile Development and Hacking General] papo:
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:

LOCK:Disabled

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:

LOCK:Disabled -- 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 HIDE:Disabled -- 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 LOCK:Disabled 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