XeNTaX Forum Index
Forum Home Tools Blog GFFC MultiEx
It is currently Thu Apr 24, 2014 10:16 pm


You can make the ads go away by registering


All times are UTC + 1 hour




You can make the ads go away by registering



Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Multiex.dll , ever wanted one?
PostPosted: Wed Jun 25, 2003 6:51 pm 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
Soon MultiEx Commander 3.9 will be released.
Hopefully it will run on Win98/XP/2000.

Anyway, with this release multiex.dll will be run.
Yes, this is the main engine that runs on Binary MultiEx Script (BMS) files.

=============================

DOWNLOAD MULTIEX.DLL (52 Kb)

=============================
This package includes BMS files for Multiex.dll to use, 69 in total.
=============================



For any of you who'd like to implement multiex funtionality in your own programs, here's what the dllreadme.txt file will have to say.

Quote:
<==========================
MultiEx 3 ActiveX DLL
==========================>

Version : 1.00
COpyright : XeNTaX 2003
Author : M.W.Zuurman (AKA Mr.Mouse)
Website : http://www.xentax.com

---------------------------

Instructions for authors:

If you want to implement the MultiEx GameArchive Analysis
Engine in your programs you must be aware of the following:

You must regsvr32.exe it.

You must have Binary MultiEx Scripts (*.BMS) files that enable
processing of the archive you want to process!
(There are much included in the DLL package)


The CLASS you want to address is AMex3GetFileInfoClass.
The CLASS AMex3GetFileInfoClass gives you access to
the function Mex3GetFileInfo.

For example, assign a new AMex3GetFileInfoclass called RunMex and use
it to call the function : ie "RunMex.Mex3GetFileInfo".
The Syntax is like this :

------------------------------------------------
Integer Mex3GetFileInfo (String PathToBMS, String PathToArchive, String ArgumentList)
------------------------------------------------


Arguments you may pass to the engine :

-l : Log the process in a log file
(it will be saved in the App.Path as mex3.log)
-lst : by default the dll will create a file called multiex.lst
that lists important variables on the archiveformat as well
as the contents of the file. See "The List File"
With the argument -lst you tell the DLL to name it differently
USAGE : "-lst newname"
-pro : show a basic progress window during DLL operation
-p : Always show the Error MessageBox at the end of operation

The Return value is an integer and essentially the error code.
(0 = no errors)

-------------------------------------------------

The List File
-------------

Upon succesfull analysis of a gamearchive multiex.dll will
present you with a file called multiex.lst by default.

The format has a header that gives :

Long NumberOfFiles : Number of files in the archive
Long Mex3ComType : Compressiontype of the files in the archive (if any)
0 = none
750 = ZLibCompression1
Long Mex3ImpType : Imporationtype that lets you know:
iStandard = 710
(both fileoffsets and filesizes are mentioned in the
archive)
iSFileOff = 711
(only fileoffsets are mentioned)
iSFileSize = 712
(only filesizes are mentioned)
iNone = 713
(for MultiEx Commander : no importing allowed)
iStandardTail = 714
(Standard but with a tailpointer at the beginning)

Byte TailOffOffYes : Is there an offset of a pointer to a tail?
0 = No
1 = Yes
Long TailOffOff : The location of the offset of a pointer to a tail
in the archive.
Byte FileOffs_Rev : The (long) variables depicting the Offsets of
the different files in the archive are reversed in saved
format. So An offset of 12cd3400 would be written in the
archive as 00 34 cd 12. Low Byte->High Byte switched!
0 = No
1 = Yes
Byte FileSizes_Rev : Like above, now for the size variables for each file
in the archive

Then follows the body of information on each file in the archive
(NumberOfFiles times!)

The record for a single entry looks like this:

String (preceded by VB depictor for a string) Name of the File in the archive
Long (preceded by VB depictor for a long) Offset of the file in the archive
Long (preceded by VB depictor for a long) Size of the file in the archive
Long (preceded by VB depictor for a long) Offset of the Offset Variable
Long (preceded by VB depictor for a long) Offset of the Size Variable
NOTE : IF THE FILES ARE COMPRESSED THE FOLLOWING IS ADDED TO THE RECORD:
Long (preceded by VB depictor for a long) The Original Size of the file
Long (preceded by VB depictor for a long) Offset of the Original Size Variable


There, that's it! Note that you may not need all the header variables for your
purpose at all. Then just ignore those values.

-------------------------------------------------

For any additional help, visit the XeNTaX MultiEx Forums at

http://forums.xentax.com

-------------------------------------------------


_________________
Game Request Rules


Last edited by Mr.Mouse on Fri Mar 26, 2004 1:04 pm, edited 3 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 25, 2003 9:53 pm 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
To help you out, here's some C++ code to address the function:

Create a reftodll console application and write in reftodll.cpp

Quote:

#include "stdafx.h"
// you may want to #include <basetsd.h> as well

int main(int argc, char* argv[])
{
HRESULT hr;
CLSID clsid ;
// Initialize an appointment
CoInitialize(NULL);

//obtain the Class id
CLSIDFromProgID(OLESTR("multiex.AMex3GetFileInfoClass"),&clsid);

//Make RunMex the class of interest
_AMex3GetFileInfoClass *RunMex;

// Create the Class instance, if failure show a message
if (CoCreateInstance(clsid, NULL, CLSCTX_INPROC_SERVER,__uuidof(_AMex3GetFileInfoClass), (void**) & RunMex) >= 0)
{
// succes, tell user to press ok to start running
MessageBox(0, "Ok to run MultiEx", "", MB_OK);
// Run the Mex3GetFileInfo function, using the arguments
// hr is the resulting error number, 0 = no error
hr = RunMex->Mex3GetFileInfo("big.bms", "english.big", "-p -l -lst mylist.lst");
if (hr > 0 )
{
MessageBox(0, "MultiEx returned an error", "", MB_OK);
}
}
else
{
MessageBox(0, "Failed to address the DLL!", "", MB_OK); }
// Destroy the appointment
CoUninitialize();

return 0;

}


In the StdAfx header you have write:
Quote:
#import "multiex.dll"
using namespace multiex;

at the appropriate possition

There, that should do the trick. Compile everything and make sure you check the dependencies.

The example expects multiex.dll in the project directory and a big.bms file
for C&C: Generals BIG files , as well as the english.big file of the game in the app directory.

_________________
Game Request Rules


Top
 Profile  
 
 Post subject: Re: MultiEx DLL
PostPosted: Thu Jun 26, 2003 3:47 pm 
Offline
VVIP member
VVIP member
User avatar

Joined: Thu Jun 26, 2003 3:44 pm
Posts: 24
Location: Belgium/France/Peru
Has thanked: 0 time
Have thanks: 1 time
Hi!

I hope I can work on this soon. :D

Since your mail I found how to use ActiveX in Delphi... almost as easy as in VB. :P

ByE!

_________________
Dragon UnPACKer - The Open Source Game Archive Extractor


Top
 Profile  
 
 Post subject: Re: MultiEx DLL
PostPosted: Thu Jun 26, 2003 4:14 pm 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
Elbereth wrote:
Since your mail I found how to use ActiveX in Delphi... almost as easy as in VB. :P


8D Excellent, and hey, what's wrong with VB :P (CHECK OUT MY COOL C++ code ABOVE!! :P )

Right, I just need to run a few more tests on the thing, and add some games.

"This could be the beginning of a beautiful relationship!" - MultiDragon sound nice? 8)

_________________
Game Request Rules


Top
 Profile  
 
 Post subject: Re: MultiEx DLL
PostPosted: Thu Jun 26, 2003 7:03 pm 
Offline
VVIP member
VVIP member
User avatar

Joined: Thu Jun 26, 2003 3:44 pm
Posts: 24
Location: Belgium/France/Peru
Has thanked: 0 time
Have thanks: 1 time
Mr.Mouse wrote:
8D Excellent, and hey, what's wrong with VB :P
(CHECK OUT MY COOL C++ code ABOVE!! :P )


Nothing! I coded Dragon UnPACKer 4 in VB... :)

Mr.Mouse wrote:
Right, I just need to run a few more tests on the
thing, and add some games.


Ok! add as many games as you want! :)

Mr.Mouse wrote:
"This could be the beginning of a beautiful
relationship!" - MultiDragon sound nice? 8)


Hehe the plugin should be named MultiEx plugin for Dragon UnPACKer
or something like that. :)

_________________
Dragon UnPACKer - The Open Source Game Archive Extractor


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 26, 2003 8:28 pm 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
Hehe, well, we will have to see about the name :!: :P

One key function of MultiEx Commander though is that it enables the user to replace files in the game archive. Now, all that multiex.dll does is provide the user with the list file (as described above) that contains variables necessary for succesful file importation. It is MultiEx Commander that has the importation function. For succesful integration of multiex.dll function, I guess you will have to write such a function yourself, in Delphi, for your program to support it.

We might even consider creating a new dll that takes care of this. However, then we will have to recreate and merge the two programs, because then it really is the combination of the two programs that makes the one tool to rule them all. :wink:

MultiEx Commander has the WinZip-like GUI, Dragon UnPACK more like an Explorer interface.

_________________
Game Request Rules


Top
 Profile  
 
 Post subject: Re: MultiEx DLL
PostPosted: Thu Jul 24, 2003 3:44 pm 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:25 pm
Posts: 3850
Location: Home
Has thanked: 2 times
Have thanks: 60 times
Mr.Mouse wrote:
and hey, what's wrong with VB

you want a list? :x


Top
 Profile  
 
 Post subject: Re: MultiEx DLL
PostPosted: Thu Jul 24, 2003 3:48 pm 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
Captain wrote:
you want a list? :x


No thanks, I already have my own. :read:

_________________
Game Request Rules


Top
 Profile  
 
 Post subject: Re: some news about driver for Dragon UnPACKer 5
PostPosted: Tue Aug 12, 2003 7:43 pm 
Offline
VVIP member
VVIP member
User avatar

Joined: Thu Jun 26, 2003 3:44 pm
Posts: 24
Location: Belgium/France/Peru
Has thanked: 0 time
Have thanks: 1 time
Hi!

I started coding a driver for Dragon UnPACKer 5 that use MultiEx DLL.
I was able to generate a lst file for Doom2.wad (to test), but I still need to do the lst parsing.

I have one question:
Is it me (in my code) to detect the file format (and choosing the right BMS file) or do your DLL can do it ?
Because it is quite confusing.

ByE!

_________________
Dragon UnPACKer - The Open Source Game Archive Extractor


Top
 Profile  
 
 Post subject: Re: some news about driver for Dragon UnPACKer 5
PostPosted: Wed Aug 13, 2003 7:32 am 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
Elbereth wrote:
Hi!

I started coding a driver for Dragon UnPACKer 5 that use MultiEx DLL.
I was able to generate a lst file for Doom2.wad (to test), but I still need to do the lst parsing.

I have one question:
Is it me (in my code) to detect the file format (and choosing the right BMS file) or do your DLL can do it ?
Because it is quite confusing.

ByE!


No, as you also might have encountered, many formats do not have any ID tag anywhere in the file, other than the file extension. However, the file extension is not enough to identify a BMS file to use, because many games use archives with the same extension, but that are in fact totally different formats. :cry:

Now, IF a given format does have a ID tag, and you would pass the wrong BMS file to MultiEx.DLL, the dll would abort process and notify that the ID tag is invalid in your achive.

In MultiEx Commander the user selects the format prior to processing, because of the above mentioned reason. Then MultiEx Commander tells multiex.dll to use the BMS file that belongs to the user-chosen format.

In essence, you will have to write some small code (at least its small in MC :P ) to pass the right BMS file to MultiEx.DLL when appropriate. :)

_________________
Game Request Rules


Top
 Profile  
 
 Post subject: Re: some news about driver for Dragon UnPACKer 5
PostPosted: Wed Aug 13, 2003 9:50 am 
Offline
VVIP member
VVIP member
User avatar

Joined: Thu Jun 26, 2003 3:44 pm
Posts: 24
Location: Belgium/France/Peru
Has thanked: 0 time
Have thanks: 1 time
Mr.Mouse wrote:
No, as you also might have encountered, many formats do not have any ID tag anywhere in the file, other than the file extension. However, the file extension is not enough to identify a BMS file to use, because many games use archives with the same extension, but that are in fact totally different formats. :cry:


Yeah I know...

Mr.Mouse wrote:
Now, IF a given format does have a ID tag, and you would pass the wrong BMS file to MultiEx.DLL, the dll would abort process and notify that the ID tag is invalid in your achive.


Hmm ok. And do I have a way to know from the BMS file is there is ID tag checking ?

Mr.Mouse wrote:
In MultiEx Commander the user selects the format prior to processing, because of the above mentioned reason. Then MultiEx Commander tells multiex.dll to use the BMS file that belongs to the user-chosen format.


I should download your tool to see how it works. :P

Mr.Mouse wrote:
In essence, you will have to write some small code (at least its small in MC :P ) to pass the right BMS file to MultiEx.DLL when appropriate. :)


That's what I though. You see in Dragon UnPACKer 5 the plugins have two exported functions IsFormat and ReadFormat. The IsFormat tells from the extension if it can read the file (or using ID tags if the Deeper argument is TRUE) and then Dragon UnPACKer 5 run all the drivers that answered TRUE to IsFormat with ReadFormat, if no driver could read the file then I display and error. So I was thinking in making a table to associate BMS files with extensions in my driver (which the user could change).

Another note:
What OCX and DLLs do your MultiEx.DLL needs ?
(because I was forced to install the VB6 runtime to get it to work on my computer)

_________________
Dragon UnPACKer - The Open Source Game Archive Extractor


Top
 Profile  
 
 Post subject: Re: some news about driver for Dragon UnPACKer 5
PostPosted: Wed Aug 13, 2003 10:37 am 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
Elbereth wrote:
Hmm ok. And do I have a way to know from the BMS file is there is ID tag checking ?


Well, at the moment the only two ways to see wether there is ID tag checking is to open the BMS in Mex3Scriptor (that comes with the MultiEx Commander package) and examine the script. If there's a command :
IDString "somestring"
then yes. You might also open the BMS file with a hex editor and examine its tail, to see if there's some kind of ID tag string in the tail.

Elbereth wrote:
I should download your tool to see how it works. :P


:roll: :!:

Elbereth wrote:
That's what I though. You see in Dragon UnPACKer 5 the plugins have two exported functions IsFormat and ReadFormat. The IsFormat tells from the extension if it can read the file (or using ID tags if the Deeper argument is TRUE) and then Dragon UnPACKer 5 run all the drivers that answered TRUE to IsFormat with ReadFormat, if no driver could read the file then I display and error. So I was thinking in making a table to associate BMS files with extensions in my driver (which the user could change).


Yes, that seems a good idea. 8)

Elbereth wrote:
Another note:
What OCX and DLLs do your MultiEx.DLL needs ?
(because I was forced to install the VB6 runtime to get it to work on my computer)


Really? That's kind of strange. Was there some kind of error? If so, what error did it display? It may be that the "progress" window needs some OCX/DLL. Please tell me the error you encountered. so I can fix any bugs or dependencies.

_________________
Game Request Rules


Top
 Profile  
 
 Post subject: Re: some news about driver for Dragon UnPACKer 5
PostPosted: Wed Aug 13, 2003 2:45 pm 
Offline
VVIP member
VVIP member
User avatar

Joined: Thu Jun 26, 2003 3:44 pm
Posts: 24
Location: Belgium/France/Peru
Has thanked: 0 time
Have thanks: 1 time
Mr.Mouse wrote:
Really? That's kind of strange. Was there some kind of error? If so, what error did it display? It may be that the "progress" window needs some OCX/DLL. Please tell me the error you encountered. so I can fix any bugs or dependencies.


The error was with MSCOMCTL.OCX that wasn't registered, I installed the VB6 runtime because I knew this file was registered during the install.
After installing the VB6RT all was ok so there is maybe other OCX dependencies.

By the way MultiEx Commander 3.8b crash sometimes here, everytime I do some kind of action. The first time it just crashed everytime I pressed something on the interface.

Now when I run MultiEx it search for some stuff on internet and then the main window appear. Now if I press Info > Supporting formats (Allowing import) I got the following error (same error everytime it crashed even when doing something else):

Erreur d'exécution '35603': Clé non valide.
(which means something like Runtime error '35603': Invalid key)

If I press OK the program just close.

I am running under Windows XP Pro Corporate with SP1 and all Windows Update patches until today.

_________________
Dragon UnPACKer - The Open Source Game Archive Extractor


Top
 Profile  
 
 Post subject: Re: some other questions about MultiEx DLL
PostPosted: Wed Aug 13, 2003 4:47 pm 
Offline
VVIP member
VVIP member
User avatar

Joined: Thu Jun 26, 2003 3:44 pm
Posts: 24
Location: Belgium/France/Peru
Has thanked: 0 time
Have thanks: 1 time
In the readme you write:

Code:
Long    Mex3ComType   : Compressiontype of the files in the archive (if any)
                          0   = none
           750 = ZLibCompression1


Now when I open Doom 2 WAD file (this is the first file I found on my harddisk) this field value is 99. What does that mean ? (because for me Doom 2 IWAD file isn't compressed)

So this also leads to some problem because you write:
Code:
NOTE : IF THE FILES ARE COMPRESSED THE FOLLOWING IS ADDED TO THE RECORD:
Long   (preceded by VB depictor for a long)   The Original Size of the file
Long   (preceded by VB depictor for a long)   Offset of the Original Size Variable


So I coded it that way:
If Mex3ComType is not 0 then read 2 long values and then next entry
If it is 0 then next entry

The problem is for the Doom 2 IWAD this doesn't work because the 2 long values do not exist...

I just tried with Shadow Warrior GRP file (which I also know is uncompressed) and the Mex3ComType is still 99.

One last question:
How do I know where the LST file is saved ?
Sometimes it is saved in the multiex.dll directory and sometimes in the same directory as the source file. I would really appreciate to give him the full path to the LST file to create.
I tried giving a path after the -lst parameter but it doesn't work.

_________________
Dragon UnPACKer - The Open Source Game Archive Extractor


Top
 Profile  
 
 Post subject: Re: some other questions about MultiEx DLL
PostPosted: Wed Aug 13, 2003 8:58 pm 
Offline
Site Admin
User avatar

Joined: Wed Jan 15, 2003 6:45 pm
Posts: 8452
Location: Dungeons of Doom
Has thanked: 282 times
Have thanks: 406 times
Elbereth wrote:
In the readme you write:

Code:
Long    Mex3ComType   : Compressiontype of the files in the archive (if any)
                          0   = none
           750 = ZLibCompression1


Now when I open Doom 2 WAD file (this is the first file I found on my harddisk) this field value is 99. What does that mean ? (because for me Doom 2 IWAD file isn't compressed)

So this also leads to some problem because you write:
Code:
NOTE : IF THE FILES ARE COMPRESSED THE FOLLOWING IS ADDED TO THE RECORD:
Long   (preceded by VB depictor for a long)   The Original Size of the file
Long   (preceded by VB depictor for a long)   Offset of the Original Size Variable


So I coded it that way:
If Mex3ComType is not 0 then read 2 long values and then next entry
If it is 0 then next entry

The problem is for the Doom 2 IWAD this doesn't work because the 2 long values do not exist...

I just tried with Shadow Warrior GRP file (which I also know is uncompressed) and the Mex3ComType is still 99.


:oops: You are quite right, I wrote the readme.txt with air in my head instead of brains. The value = 99 = No Compression. Not 0. So , you read 99 and that means no compression and no elongation of the entries. Sorry for that.

Elbereth wrote:
One last question:
How do I know where the LST file is saved ?
Sometimes it is saved in the multiex.dll directory and sometimes in the same directory as the source file. I would really appreciate to give him the full path to the LST file to create.
I tried giving a path after the -lst parameter but it doesn't work.


Well, it takes full paths in my book!

For example : "F:\Code\VISUAL~1\MC39ME~1\data\multiex.lst"

It simply takes a string and uses that as a Path...it really should work the way you want to. :|

_________________
Game Request Rules


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next


You can make the ads go away by registering


All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group