Related
I copied a CAB file in files2 (from mkrom) and I put a line in initobj.txt, the line in initobj.txt is:
Directory("Program Files"):-File("m.cab","\Windows\m.cab")
When I did double click on m.cab a pop-up window said me:
"Cannot find 'm' (or one of its components). Make sure the path and filename are correct and all the required libraries are avaliable"
But if I copy the m.CAB with Active Sync It works,
Any idea.
It needs a cab installer!
The problem is that I erased the CabInstall.exe, but I didn`t change the entry in registry for the one that goes with the wceload.exe which is the cab installer that comes with windows CE by default.
I want to deny or restrain installation of applications on the fly as an service/process or by making changes in the registry on WM5 devices. Any ideas? The app preferely in C++/C#
CAB files are installed by wceload.exe in the windows directory.
You can overwrite this file with a blank exe, or remove the CAB extension reference to it in registry under HKEY_CLASSES_ROOT.
Deny or restrain inst. of apps
Thanks, yes I've thought about this - but this isn't a very dynamic solution. When a person run a CAB I want to check if app is okay to install from a "List" - then show a popup with a message saying something like "Sorry, you are not allowed to install this application. Please contact your company IT Admin for more info".
Is the .CAB association in HKEY_CLASSES_ROOT linked to wceload - so I could run an app to validate CAB, and if ok execute wceload..?
levenum said:
CAB files are installed by wceload.exe in the windows directory.
You can overwrite this file with a blank exe, or remove the CAB extension reference to it in registry under HKEY_CLASSES_ROOT.
Click to expand...
Click to collapse
Write up a registry entry in HKEY_CLASSES_ROOT to associate .CAB files with your custom file. Then, when the user taps on a CAB file, your program reads it, compares it against its list and, if it's approved, calls WceLoad with the appropriate parameters.
The key would probably look something like this:
HKCR\cabfile\shell\open\command
(default) = "<path to your app>" "%1"
(%1 will be replaced with the path to the CAB file).
Then, if the CAB was approved, call WceLoad with the following parameters:
\windows\wceload.exe "<path to cab file>" /nodelete
Note that some apps, may call wceload.exe directly. I am not sure if Activesync does it, but I know a couple of custom installers that do.
If you really want to secure the device against unothorized software do the following:
Rename wceload.exe to something else like wceload1.exe.
Create you own wceload.exe, but make sure you capture and preserve all command line parameters in case you need to transfer them to the original file for proper installation.
This way you can be sure no one will install anything without your permission.
Olso, keep in mind wceload is used to switch themes as well. (It handles *.tsk files).
Very much..
Thank You all!!
[ 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
First off, I'd like to thank Sleuth255 for SDAutoRun, and to mousio for his AutoRun tool which provided the inspiration for this project.
SDConfigGen is a command line tool for the PC which inspects a collection of files to be installed, then produces an SDConfig.txt and other associated scripts and provisioning files to allow SDAutoRun to automatically install them.
It differs from mousio's solution in that rather than having SDAutoRun call a MortScript to do all the work, this tool creates an SDConfig.txt to do the majority, only calling scripts for specific functionality when required. Scripts (and therefore MortScript) may not even be required, if nothing being installed needs automation.
Installation
Unzipping the contents of the archive will produce this folder structure:
\
Storage Card\SDConfig\Cabs\
Files\
Scripts\
Settings\
Sys\First things first - to use any of the script-based functionality a copy of the MortScript installation cab file must be placed within the Sys folder. Download MortScript-4.11b7.zip (or newer version) from http://www.sto-helit.de, then extract \cab\MortScript-4.11b7-PPC.cab from it.
Usage
If the name of the Storage Card will be different on your target device, then rename that folder to whatever it will be. Otherwise, just leave it as it is.
Within the sub-folders of SDConfig, add the files you want to be installed.
Cabs:
Any .cab files in this folder will be installed. If the installation of a .cab file requires user interaction (to confirm a license window, for example), then create a .mscr script file of the same name containing instructions to be executed while the cab file is being installed.
For example, if you need to install a cab file: "eWallet-PocketPC-Install.cab",
create a file called "eWallet-PocketPC-Install.mscr" too. This file contains
MortScript to be run while the cab installer is being run, for example:
Code:
windowTitle = "Software License Agreement"
WaitFor(windowTitle, 60)
SendLeftSoft(windowTitle)
Note that you don't need to worry about actually installing the cab, or waiting for installation to finish - just write the automation code itself.
The SDAutoRun UI will be hidden while an interactive cab is being installed like this, and a MortScript status window shown instead. The device will be responsive to user input, so if any non-automatable interaction is required, that can be done manually.
Files:
After the cab files have been installed, all files in this folder will be copied directly to the root folder. To copy files to sub-folders, place them in sub-folders of this folder. For example, to copy files to the Windows folder, create a Windows folder here and place the files within it.
Standard (English) folder names will automatically be replaced by variables, so files in the "Files\Program Files" folder here will be copied to %CE1% folder by SDAutoRun.
The file copy operation is actually performed by generating a CopyFiles.xml provisioning file in the Sys folder, and it is this that goes in the SDConfig.txt file. This method was chosen as it avoids the path length limit of copying directly in SDConfig.txt, and allows for the %CEn% variable subsitution scheme.
Settings:
After the files have been copied, any settings in this folder will be applied. Settings may either be .xml provisioning files (which are added directly to SDConfig.txt), or registry data in .reg, .rgu or .cereg files. Registry data files will be automatically converted to xml provisioning files within the Sys folder, which are then added to SDConfig.txt.
Scripts:
After the settings have been applied, any .mscr scripts within this folder will be executed. SDConfigGen will generate instructions in SDConfig.txt to automatically handle copying them to the \Temp folder and renaming them to replace spaces by underscores before execution if required.
Note that the device will not be interactive at this point, so don't write scripts that require user interaction.
Sys:
Apart from placing a copy of MortScript-4.11b7-PPC.cab in here, you shouldn't touch the contents of this folder; they will be automatically cleaned out and generated by the SDConfigGen tool.
Notes
I've provided RegToXml as a standalone .exe file so that registry data files can be manually converted to .xml provisioning files, if required. This is not generally necessary, though, as it will occur automatically as part of the SDConfigGen process.
Due to limitations of SDAutoRun, during installation some files need to be copied to the \Temp folder on the device before execution. A TempCleanup.xml provisioning file is generated in the Sys folder by SDConfigGen which is the last thing executed by SDConfig.txt. It should remove any temporary files that were placed in the \Temp folder, but will not remove the folder itself, or any other files within it.
SDAutoRun also requires that SDConfig.txt be ASCII, which means that if any files contain characters outside that range (such as accented characters), they can not be directly referenced. SDConfigGen will automatically detect this, and generate provisioning XML files to transparently rename the files before processing them, then back again afterwards.
The last statement in the SDConfig.txt is the RST: Reset statment, to reset the device.
The only part of the file structure that can be changed is the name of the "Storage Card" folder - the other folders cannot be renamed or moved. By default, when the SDConfigGen tool is run, it works with the first sub folder under the folder the .exe file is placed. To override this behaviour, pass the folder path to SDConfigGen.exe as a command line argument.
Cabs, settings and scripts are executed in alphabetical order, grouped by subfolder. Subfolders will be executed first, so for example the contents of Cabs\Prerequisites\ would be installed before the files directly in Cabs\ (but after files in Cabs\A\). All interactive cabs are executed first, followed by non-interactive ones.
All generated files (except SDConfig.txt) are in Unicode UTF-16 encoding.
To have SDConfigGen create a log file of the generation process, use the SDConfigGenWithLog.bat file included in the archive. It will create a results.log file containing the messages that would normally be output to the console.
This is still an early version, so there will probably be bugs with it. I've used it successfully for setting up my own device several times now, but I can't make any guarantees. Please do post any bug reports or suggestions here though!
Alex
Updates
0.6:
All output files are now in UTF-16 encoding, with the exception of SDConfig.txt, which is in ASCII.
If files referenced by SDConfig.txt have names containing non-ASCII characters, provisioning files to automatically rename them before they are accessed, and to restore them afterwards will be generated.
Subfolders are now supported in the Cabs, Settings and Scripts folders. Files within subfolders will be processed first, in alphabetical order of subfolder name.
File folder variable substition made case insensitive
Added SDConfigGenWithLog.bat file for easy logging of output to a log file
0.5.1:
Removed .svn files from the file structure (oops!)
0.5:
Made warning message on skipping registry files less confusing
RegToXml: Now supports empty values for String, MultiString and Binary values
RegToXml: Made ,ore robust to invalid data - if a value contains invalid data, only that value is skipped.
RegToXml: The line number is now reported with any error or warning message.
RegToXml: Whitespace allowed to surround the = in value lines.
0.4:
RegToXml: Fixed nesting bug with registry key deletion conversion
RegToXml: Now supports comments (lines starting with ; )
0.3:
RegToXml now assumes that registry files without Unicode BOM's are encoded in the system default ANSI codepage, rather than UTF-8 (this means that if your registry file is UTF-8, it must contain a Byte Order Mark to be read correctly)
0.2:
Files are now installed in alphabetical order by file name (within their own group). For example, first interactive cabs A-Z, then non-interactive cabs A-Z. This allows control over installing cabs that require others to be installed before or after them.
.NET Framework (required)
Lookin Mighty Fine Siuer.
Not in the Testing Time yet.
But does the scripts folder eventually combine the scripts into one?
(lazy Bum At Work, Not Able to test it)
No, the scripts in the scripts folder are not combined into a single script, they are all executed separately. Would there be some benefit to trying to combine them into a single script before execution?
AlexVallat said:
No, the scripts in the scripts folder are not combined into a single script, they are all executed separately. Would there be some benefit to trying to combine them into a single script before execution?
Click to expand...
Click to collapse
No, you are absolutely right there is now good reason for it.
It's better to have them seprated, makes finding **** Ups easier.
Don't know what i was thinking or why..
AlexVallat,
Thanks for your job, you soft is amazingly simple which is a great pro compared to SASHIMI for instance.
So yhis afternoon I started to put all my files in the appropriate folders and when I launch SDConfigGen with the folder path I don't get in the config.txt file \Storage Card\ before the files to execute but the path I gave as parameter. I think transforming the path given into \Storage Card\ could help.
One other point, as a poor French guy your RegToXml converter does not handle all the French extended character set such as é, à, ... Could you make it support this characters.
Anyway for now it is fully usable but requires SDConfig.txt file edition before launching the whole process. Tomorrow it will be hands-on time as I plan to upgrade my Polaris ROM so more news to come regarding SDCofingGen usage.
The_Steph
The_Steph said:
AlexVallat,
Thanks for your job, you soft is amazingly simple which is a great pro compared to SASHIMI for instance.
So yhis afternoon I started to put all my files in the appropriate folders and when I launch SDConfigGen with the folder path I don't get in the config.txt file \Storage Card\ before the files to execute but the path I gave as parameter. I think transforming the path given into \Storage Card\ could help.
One other point, as a poor French guy your RegToXml converter does not handle all the French extended character set such as é, à, ... Could you make it support this characters.
Anyway for now it is fully usable but requires SDConfig.txt file edition before launching the whole process. Tomorrow it will be hands-on time as I plan to upgrade my Polaris ROM so more news to come regarding SDCofingGen usage.
The_Steph
Click to expand...
Click to collapse
Hm my pall had the same thing but changing to Unicode seemed to solve his XML issue. NOt sure if this is the same but worth the try.
Great work alex!
Question:
Anyway to verify the syntax of the provisioning XML files?
Any tools out there that can create these files or verify them? I think a tool like this would be great.
NEVERMIND! I just saw your reply in the reg2xml converter thread! THANKS!
The_Steph: Thanks for your comments!
The idea with the path is that the name of the folder is used to control the name of the Storage Card on the device. So if you name your folder Storage Card, that's what goes in the SDConfig.txt. If, on your device, it has a different name (due to language changes, or whatever), then you need to rename the folder appropriately.
Thanks for the bug report about accented characters in RegToXml. I will fix that and post an updated version soon.
gtxaspec: I could verify that the files were valid XML, but the more useful check that they contain valid provisioning instructions is beyond the scope of this project. Not least because the documentation describing what are valid instructions is confusing and can be inaccurate. With anything other than the file and registry providers, it usually ends up being a case of trial and error. With the file and registry providers, using the auto-generation capabilities of SDConfigGen will avoid most surprises.
Alex
Version 0.3 released
I've just updated the first post to release version 0.3. This should address the accented characters issue raised by The_Steph, however it does mean that if your registry file is UTF-8 encoded, it must include Byte Order Marks to indicate this. Otherwise, it will be assumed to be encoded in the system default code page.
I've also added a feature that files are now installed in alphabetical order (within each group). If you need to make sure that certain cabs are installed before others, this can now be done by renaming them, usually by including a numeric prefix.
Alex
reg2xml bugs
Hi Alex,
Converting everything to xml and using standard provisioning is an interesting approach!
Only obviously reg2xml has got some problems still with .reg files containing certain characters:
I've attached you a sample file which is not converted correctly at three points, each with a different error cause.
- Comments (Lines beginning with ";") in the .reg files are sometimes (not in every case, could not see what the trigger is) leading to an aborted conversion.
- Some characters like the arrow character (ASCII 27/1BHex) are also a problem.
Maybe the attached file helps in finding the bug.
BTW: Do you also have a tool that is converting just the other way around: From XML to reg indstead of from reg to XML?
Sometimes I need to have a .reg file instead of an .XML. And importing the XML and then trying to find all registry entries to export it back to a .reg can be a very tedious thing when the imports are not all together in one registry branch.
Thanks!
Thanks for the bug report, asango. Yes, I forgot about comments, I'll fix that and release an update soon. I'm looking into what the best way to handle control characters like 0x1B is (which is 'Escape', according to the ASCII chart I'm looking at). Obviously crashing is not an acceptable behaviour, so I'll have some sort of fix for it.
I don't have a XmlToReg tool, but it sounds like a good idea - I'll probably write one over the weekend.
Alex
Great, looking forward to that, thank you!
Version 0.4 released
The first post has been updated to version 0.4. RegToXml has been updated to add support for comments in .reg files.
Unfortunately there appears to be no way to include control characters in an XML file. If the character itself, or even the character entity (like , then the file is regarded as malformed and not accepted. I have therefore not been able to do anything to fix this (sorry asango!).
If anyone knows of a way that a provisioning file could be used to set a registry string value containing these characters, please let me know.
On a more positive note, the requested XmlToReg tool is up - I've given it its own thread here: XmlToReg.
Alex
Yes, the comments are now handled corectly, perfect!
Some other thing is still an issue:
test.reg: Converting...
test.reg: Conversion failed. (Unexpected value format: dword) Skipping.
In this case the output file is not generated at all, seems that not only the value is skipped but this causes the whole file not being written.
This leads to another suggestion: Would it be possible to indicate the line number where a problem happened?
This would make it much easier to find the problem.
And regarding the non handled escape characters:
This also leads to aborting. Would it also be possible to just skip them and issue a warning but go on with the conversion and with writing the outout file for the rest of the entries?
Now that is odd. "dword" is a perfectly valid value format, it shouldn't have produced that error. Any chance you could send me the .reg file that produced it?
Line numbers should be do-able, I'll add that to the next version.
The "skipping" message there referred to the "test.reg" at the start of the message, not to the dword value. I agree it looks misleading as it is currently worded though, I'll improve that.
About recovering from errors and skipping only invalid values rather than the whole file - this will be quite tricky. By the time I am notified of invalid characters by the XmlWriter, it has already given up in a sulk and can't be persuaded to continue writing any further. I'll need to do some sort of pre-vetting before passing data on to it. If I come up with any good ideas on how to do this, I'll include it in the next version.
Alex
asango, here's a candidate RegToXml.0.5.0 - could you check if it is still reporting the "Unexpected value format: dword" error with your file? It now reports line numbers, which might help track down the problem. It should also be able to recover from an invalid value and skip just that value, although I'm not sure how well that is working yet.
Alex
Hi Alex,
Great, the line numbers are making things much easier and this way I even found the reason for this error very easily:
Here's the point where it is failing:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\RIL]
"NITZEnable"= dword:00000001
...with this error message:
test.reg: Converting...
[Line 194] Error: Invalid value (Unexpected value format: dword)
Skipping: HKEY_LOCAL_MACHINE\Drivers\BuiltIn\RIL\NITZEnable
Done.
As soon as I'm deleting the blank between the "=" and "dword" everything is ok.
Maybe you can allow blanks after the "=" in general?
This would solve this issue definitely
And yes, by the way the xml file is now generated despite of this error, very good!
Asango
Hmm... I'm not sure whitespace is supposed to be allowed around the = sign. It doesn't make anything ambiguous though, so there's no good reason not to relax the matching. Try this 0.5.1 which allows whitespace around the = sign, hopefully that should now parse your file correctly.
Alex
Yes, now I can see no other issues with the RegToXml tool, good work!
Also the whole cold boot import is ok with one exception:
Only the CopyFiles.xml which is generated by the SDConfigGen.exe is not copying all the files from the "Files" diectory during its execution.
Tried to import that xml manually with the xml option of Taskmgr and also got an error, but since the error is *very* uninformative and not showing the line number and my CopyFiles.xml is rather big I could not find the problem.
Could it be that the reason for the error is that if a file is already existing or read only that this will stop the rest of the import?
asango said:
Yes, now I can see no other issues with the Only the CopyFiles.xml which is generated by the SDConfigGen.exe is not copying all the files from the "Files" diectory during its execution.
Tried to import that xml manually with the xml option of Taskmgr and also got an error, but since the error is *very* uninformative and not showing the line number and my CopyFiles.xml is rather big I could not find the problem.
Click to expand...
Click to collapse
Second hands-on day with SDConfigGen and I have the same issue with v0.4. CopyFiles.xml is not executed at all. Probably a syntax error issue as stated by asango (I've done the same tests as him).
The_Steph
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