Spent a lot of time on it, trying to figure out what went wrong with mkrom when cooking 4.00.xx roms. finally figured it, well, almostly. here is a short step by step tutorial for people who do not want to set up the complicated kitchen but wish to use mkrom as in the good old 3.17 time.
I assume you already know the rom flush process already, if given a NBF file. also you need a linux box with perl.
I know quite a few people struggled and have not had a clue. and I believe there is some bugs in the mkrom package that gives the trouble.
1. download the newest mkrom from http://xda-developers.com/~itsme/download/mkrom_136.zip. this is the only piece of software you would need.
2. unpack it to, say mkrom, directory. then make directories cfg
3. get hold of a copy of rom file and its corresponding paramter files. the parameter files can be obtained from the demo kitch download ftp://kitchen:[email protected]/data look inside the "00_base ROM" and the parameter files should be under cfg directory of each rom directory. bascially the parameter files tells mkrom, where to start to put added files and how large space there is. there are two blocks of space that can be used. so the file has format
wincever=4
start1=81740000
size1=00040000
start2=81b00000
size2=003c0000
startbmp=81ec0000
startop=81b00000
the first three lines are same for all 4.00.xx roms, start2 varies for different roms, startbmp is also the same for all roms. startop should be the same as start2. size2 will be startbmp-start2, remember they are all in hex. you can calculate how large space there is once you get hold of the start2 parameter.
anyway, put the parameter files under the mkrom/cfg directory, with name "params"
4. copy a rom file (.nbf), say rom.nbf, into mkrom directory and run "./setup rom.nbf". this will creates several files under cfg.
5. mkdir a directory mkrom/romfile, enter it and make another directory file , then type "../dumprom ../cfg/rom.nb1 -4 -d file"
here comes the first bug. the setup.sh tells you that dumprom can only be used in windows box. but in fact, there is a compiled dumprom for linux in the directory (you might need to set it to be executable though). however, this linux version does not put extracted files into the "file" directory as it is supposed to, instead it just write file as "file\xxx" where xxx is the actual file name extracted from rom. it is a bug but as long as we know it, not a big deal. the is someone posted a correct version of dumprom in this forum though.
6. you should be able to find three files (or with the "file\" prefix added) with name default.fdf initobj.dat initdb.ini. these are the three files that needs to be process as indicated by setup.sh. follow the instruction to create the default.reg initobj.txt initdb.ini and copy them to cfg directory.
7. make a directory mkdir/files. you are ready to create a clean rom now by running "./mkrom output.nbf", the created output.nbf should be fine.
So far so good, followed the instruction of mkrom. next would need to add our files. then comes the problem. if you add files into the mkrom/files directory, and run "./mkrom output.nbf" again, it is almost definitely that the created rom is bad. I am not 100% sure why, but here is what I believe:
the mkrom script scan files in the "files" directory and put files in there into the "files1", "files2" directory, each of them is supposed to fill the two space in rom starting from "start1" and "start2" in parameter file. the size of files under "file1" should be less than "size1", similar "files2" and 'size2". when mkrom does this, it is highly possible that the three critial files "default.fdf, initobj.dat, initdb.ini" are placed into "files2" directory instead of "files1" directory and renders the rom bad.
here is what I did
edit the mkrom.sh, delete the line that splits files in "files" into "files1, files2" directory. change the three lines that convert the three critial files so that these three files are created in "files1" directory instead of "files" directory. then put your files into "files1" and "files2". just be careful, keep the size less than specified by "size1" and "size2".
then you can run "./mkrom.sh output.nbf" as before, and the resulted rom will be good.
hope this helps. however still a couple of problems
1. the fdf2reg.pl won't recoganize the default.fdf extracted from 4.00.21 rom or 4.01.00 rom
2. if i change the content of initobj.txt, the created rom won't boot. I might have done something wrong in initobj.txt though. but I used to be able to do this for 3.17 rom
3. I did not try to modify registry, as my only purpose is to put my files into ROM to save space. all registry can be done later by installing the software and choose not to overwrite existing files in ROM. must simpler.
the unix version of dumprom does not decompress files, that is why your default.fdf etc seem corrupted.
this is because I only have the decompression code in the form of a binary library, which I have not figured out how to link to under linux.
the only use of dumprom under unix is to find the offsets in rom where filepointers to default.fdf etc should be patched.
I should maybe disable the '-f' option in dumprom for the unix version, to make things less confusing.
but it looks to me that the dumprom under linux worked for pre- 4.00.16 rom. only not for after 4.00.21 roms. so are they different?
maybe the default.fdf was not compressed in the 3.x roms?
I am quite sure it does not work for compressed files under linux - I just did not implement the compression routines.
dumprom worked with 4.00.05 4.00.11 4.00.16 roms. I cooked 4.00.11 and 4.00.16 roms, and the rom was fine. I never used windows box during the process. only when i tried 4.00.21 and 4.01.00, there was error. anyway, i don't care, since I need as much rom as possible and 4.00.11 seems to be the best choice for me.
thanks for writting mkrom, a terrific tool. I don't like the way xda-developers.com promoting kitchen but not mkrom. mkrom is much simpler to setup and run, as long as you know about linux. the kitchen is much more complicated to get it to work and most people don't actually need such flexibility I believe.
ok i installed cygiwin and was with u till step 5, then i am lost.. when i run step 6 dumprom (in DOS) gives me an ewrror here atr the first few lines from dumprom( wiht latest ATT official release)
img 00000000 : hdr=8c0a1000 base=8c078000 commandlineoffset=8c077fe0
img 00040000 : hdr=800cdde0 base=80000000 commandlineoffset=7fffffe0
img 00180000 : hdr=8024db88 base=80000000 commandlineoffset=7fffffe0
img 00380000 : hdr=8039b334 base=80000000 commandlineoffset=7fffffe0
img 00670000 : hdr=80be2c40 base=80000000 commandlineoffset=7fffffe0
img 00c00000 : hdr=80e99400 base=80000000 commandlineoffset=7fffffe0
img 01050000 : hdr=813efc74 base=80000000 commandlineoffset=7fffffe0
img 01400000 : hdr=815d2ba4 base=80000000 commandlineoffset=7fffffe0
img 015f0000 : hdr=815f0650 base=80000000 commandlineoffset=7fffffe0
img 017c0000 : hdr=81bba0a4 base=80000000 commandlineoffset=7fffffe0
ERROR: could not find pointer for ofs 8c0a1000
invalid romhdr ofs 8c0a1000
ERROR: could not find pointer for ofs 00000000
7fffffe0 - 80000000 L00000020 unknown 30315750 452d3142 412d474e 2d30332e 2d353030 62373239 2d2d2d2d 2d2d2d2d
80000000 - 80000004 L00000004 romsection id=ea0003fe
80000004 - 80000040 L0000003c NUL
80000040 - 80000048 L00000008 'ECEC' -> 8c0a1000
errorsgalore...
so help me here how do i make sure the files extracted are all good also the size (as per ) windows explorer is 33+ not sure how all has been installed in the 32mb rom
did you get default.fdf initobj.dat initdb.ini out of dumprom. dumprom also reported tons of errors but as long as you get the three files out, it is ok.
Dumprom tries to figure out for each byte in the rom what it does. If it doesn't know it says 'unknown' this is not an error, just that dumprom could not determine the use of this byte. The 'could not find 00000000' message means that it encountered a NULL pointer somewhere in rom where it did not expect it, the other one is a pointer to RAM, which dumprom does not know exists. You can safely ignore these errors.
Dumprom was initially written to assist in figuring out what I did not know about the rom, so it tries to figure out stuff that is unknown. Later I added the code to extract files to it. Maybe I should split dumprom in one research tool, to do a detail examination of the rom, and one tool to only extract files.
Most files in rom are compressed, that is why they are more than 33M when uncompressed.
ok i understande the messages...
now here is what i did
ran ssnap and got a picture of the OS and did a compare and have a list of entries i want to add to registru and a folder with bunch of subfolders that need to be added on install
not sure how step 6 goes.. to convert the files to .reg and .txt and how/where do i add my files and registry entries....
any tips...
update...
i did fdf2reg and made a .reg file added my entries in there and then ran reg2fdf to recreatre the fdf...
i hope this is right now i need to fig out how to specify where the files i want added are to be copied i mean some go into windows some in new filders that need to be created...
plz tell me how to go forward.
you don't need to re-create the fdf file again, mkrom does it for you, you only need to take care of the default.reg file under cfg
I am not sure whether you can put files under directories other than \windows only. I did not try that. I suppose all files under /files1 and /files2 go to \windows directory just they happen to locate in different memory location in ROM
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
hi buddies, does anyone one know how to hack an app? for example, change a predefined （hard coded) path like "\storage card" to any other locations. I tried to use hex editor but couldn't find any paths hard coded. I know there's a program called "Olly Debugger" for Win32 which can change binary code to machine code. However it doesn't support PPC applications. Can anyone help?
Many thanks!!
If the path does not appear in the executable then it is not hard coded in the program.
Hard coded strings, string tables, static data and the like, get bundled together by the linker into a separate data segment. They would all appear in the same area within the exe.
The program is probably using FindFirstFlashCard() and FindNextFlashCard() functions to emumerate storage devices. "Storage Card" would be returned by this/these function(s) at run time.
Another reason may be that the executable has been 'signed'. In this case the code is encrypted with the certificate so the hard coded stuff cannot be seen. Altering the code here will invalidate the checksum and the operating system will refuse to run it.
hi stephj, thanks for your info! finally i can figure out the location is hard coded in a dll file instead.
btw do you know how to convert a module (in the form of folders) into a binary dll?
thanks!!
Not quite certain what you mean. A DLL file is the same structure as a .EXE except that it does not have a WinMain() function that a .EXE file has that the loader calls once it is loaded.
Once a DLL is loaded the loader can resolve the real address(es) of its exported function(s).
sorry, i was talking about the modules in rom cooking. after dumping the rom, some DLLs appear in the form of modules (which are folders). what I want to know is the ways to convert these folders into binary files.
In that case it's over to the chefs. My expertise is in the area of application development.
Thanks stephj!!
To convert module to file, look for recmod
It will give you a plain .exe/.dll you want to modify.
After you do it, restore it using reversmod