I have been working on MPQ code which can run on Mono (hence the cross-OS) for the past few months, and I am to the point where I can extract files using zlib or pklib compression properly on my Windows computer. I have no way of testing on a Mac, and the only Linux boxes I have access to are webservers or dns servers, so I don't want to test there. So, I humbly ask any Mac and Linux user willing to help me out to run the test program attached to this post, which is a simple GUI which shows files based on the listfile in the archive and allows to extract 1 file at a time (so no stardat.mpq unless yours has a listfile in it). Also, I don't think it's going to work on a big-endian machine. And don't try to extract sounds under penalty of application crash (huffman isn't quite working yet). According to the mono migration analyzer, there is no code in there which shouldn't run on version 1.2.5, 1.2.6, and 1.9. If the attachment doesn't work for some obscure reason, here is a [url=http://ismaili.cc/sc/MpqTester.zip]download link[/url]. Once I get all of decompression working properly, I'll post the source and then move on to adding files to archives. It'll all probably be GPLed, I think StormLib is, and this library is heavily based on it (I hope I'm not infringing on it by posting a build without the source right now, if I am, I'll post it). Update: This is now fully in C#, so there is only 1 dll + the tester application. No more mono-basic dependency in case that was annoying. Above post, attachment, and download link updated.

I have been working on MPQ code which can run on Mono (hence the cross-OS) for the past few months, and I am to the point where I can extract files using zlib or pklib compression properly on my Windows computer. I have no way of testing on a Mac, and the only Linux boxes I have access to are webservers or dns servers, so I don't want to test there.

So, I humbly ask any Mac and Linux user willing to help me out to run the test program attached to this post, which is a simple GUI which shows files based on the listfile in the archive and allows to extract 1 file at a time (so no stardat.mpq unless yours has a listfile in it). Also, I don't think it's going to work on a big-endian machine. And don't try to extract sounds under penalty of application crash (huffman isn't quite working yet).

According to the mono migration analyzer, there is no code in there which shouldn't run on version 1.2.5, 1.2.6, and 1.9.

If the attachment doesn't work for some obscure reason, here is a download link.

Once I get all of decompression working properly, I'll post the source and then move on to adding files to archives.
It'll all probably be GPLed, I think StormLib is, and this library is heavily based on it (I hope I'm not infringing on it by posting a build without the source right now, if I am, I'll post it).

Update:
This is now fully in C#, so there is only 1 dll + the tester application. No more mono-basic dependency in case that was annoying. Above post, attachment, and download link updated.

Not to bust a bubble but there a modding tool for every OS now. Thanks to shadowflare and the maker of the python tools.

Not to bust a bubble but there a modding tool for every OS now.
Thanks to shadowflare and the maker of the python tools.

Lol, I check the site after an hour or so, and the post is like 15 seconds old... I know, but using SC is my personal way of getting better at programming, so that's that. Plus combining hobbies is great no? I like programming and SC, so 2 in 1 combo. And programming scales better with my schedule than actually playing SC, so programming for SC even if it's already been done is more of a selfish thing on my part than a service I want to make to the mapping/modding community.

Lol, I check the site after an hour or so, and the post is like 15 seconds old...

I know, but using SC is my personal way of getting better at programming, so that's that. Plus combining hobbies is great no? I like programming and SC, so 2 in 1 combo. And programming scales better with my schedule than actually playing SC, so programming for SC even if it's already been done is more of a selfish thing on my part than a service I want to make to the mapping/modding community.

[quote=name:Twitch]Not to bust a bubble but there a modding tool for every OS now. Thanks to shadowflare and the maker of the python tools.[/quote] Mac has no mem editor.

Quote from Oo.Twitch.oO

Not to bust a bubble but there a modding tool for every OS now.
Thanks to shadowflare and the maker of the python tools.

Mac has no mem editor.

Macs cannot run EXE or DLL files. Those are Windows-only.

Macs cannot run EXE or DLL files. Those are Windows-only.

Mem editor will be a summer project for me.

Mem editor will be a summer project for me.

[quote=name:fatimid08]Also, I don't think it's going to work on a big-endian machine.[/quote] If that doesn't work, then it is a bug in Mono. (assuming there exists a version of Mono that runs on a big-endian architecture)

Quote from fatimid08

Also, I don't think it's going to work on a big-endian machine.

If that doesn't work, then it is a bug in Mono. (assuming there exists a version of Mono that runs on a big-endian architecture)

[quote=name:Praetor]Macs cannot run EXE or DLL files. Those are Windows-only.[/quote] Macs can run exes built using the .Net Framework compilers if you use Mono. for more info, refer to www.mono-project.com

Quote from Praetor

Macs cannot run EXE or DLL files. Those are Windows-only.

Macs can run exes built using the .Net Framework compilers if you use Mono. for more info, refer to www.mono-project.com

[quote=name:Praetor]Macs cannot run EXE or DLL files. Those are Windows-only.[/quote] What the fuck do I care, and what does that have to do with it not having a mem editor? Just because SC isn't an .exe doesn't mean SC isn't loaded into the memory.

Quote from Praetor

Macs cannot run EXE or DLL files. Those are Windows-only.

What the fuck do I care, and what does that have to do with it not having a mem editor? Just because SC isn't an .exe doesn't mean SC isn't loaded into the memory.

Can it run from command line? Can I extract specific files via file name? Currently, SEN uses mpq-tools ([url=https://babelize.org/mpq-tools.php]https://babelize.org/mpq-tools.php[/url]) to get .chks out of maps by making an educated guess at which file it is. Although it seems to work 99% of the time, I would like to make it simpler. I do notice that mpq-tools actually updated from .3 to .4. I thought it was a dead project ^^. I'll have to look at that later.

Can it run from command line?
Can I extract specific files via file name?

Currently, SEN uses mpq-tools (https://babelize.org/mpq-tools.php) to get .chks out of maps by making an educated guess at which file it is. Although it seems to work 99% of the time, I would like to make it simpler.
I do notice that mpq-tools actually updated from .3 to .4. I thought it was a dead project . I'll have to look at that later.

Euh Syphon, I don't think he was referring to you. I think it's because my attachement contains an exe and 2 dlls, and he thought they wouldn't run on Mac, but those are specially built to run with Mono on any platform it supports (of which Mac is one). [quote]If that doesn't work, then it is a bug in Mono. (assuming there exists a version of Mono that runs on a big-endian architecture)[/quote] Forgot to answer that. MPQs are made little-endian even on big-endian systems I believe, and the BitConverter class will read as big-endian if I understand its behaviour correctly. That could make for interesting results. [quote]Can it run from command line? Can I extract specific files via file name?[/quote] And no, it doesn't run from command line, that's just a test app to make you people test if it works on Mac and Linux. If it does, I'll have to make the map screenshot app Yoshi used on Maplantis for a time use that, and then that app does work from the command line. It does extract via name, it's the only option right now as a matter of fact. Send name and locale, and it extracts for you.

Euh Syphon, I don't think he was referring to you. I think it's because my attachement contains an exe and 2 dlls, and he thought they wouldn't run on Mac, but those are specially built to run with Mono on any platform it supports (of which Mac is one).

Quote

If that doesn't work, then it is a bug in Mono. (assuming there exists a version of Mono that runs on a big-endian architecture)

Forgot to answer that. MPQs are made little-endian even on big-endian systems I believe, and the BitConverter class will read as big-endian if I understand its behaviour correctly. That could make for interesting results.

Quote

Can it run from command line?
Can I extract specific files via file name?

And no, it doesn't run from command line, that's just a test app to make you people test if it works on Mac and Linux. If it does, I'll have to make the map screenshot app Yoshi used on Maplantis for a time use that, and then that app does work from the command line.

It does extract via name, it's the only option right now as a matter of fact. Send name and locale, and it extracts for you.

[quote=name:fatimid08]Euh Syphon, I don't think he was referring to you. I think it's because my attachement contains an exe and 2 dlls, and he thought they wouldn't run on Mac, but those are specially built to run with Mono on any platform it supports (of which Mac is one).[/quote] That is correct.

Quote from fatimid08

Euh Syphon, I don't think he was referring to you. I think it's because my attachement contains an exe and 2 dlls, and he thought they wouldn't run on Mac, but those are specially built to run with Mono on any platform it supports (of which Mac is one).

That is correct.

[quote]Forgot to answer that. MPQs are made little-endian even on big-endian systems I believe, and the BitConverter class will read as big-endian if I understand its behaviour correctly. That could make for interesting results.[/quote] If Mono does not do the conversion, then that would very severely break things, and the purpose of Mono is compatibility, so I see no reason for them to make it so programs running in Mono need to care about big endian on the target architecture. Think of it this way. Programs that were only developed on Windows for the .NET Framework, which by design Mono is intended to be able to run, would not run properly (if at all) on a big endian system even in Mono if Mono was designed in the way you say. That's kind of like saying that a port of an x86 emulator to a big endian architecture should run the emulated x86 cpu in big endian mode instead of what it is supposed to be -- it just doesn't make sense. Of course many parts would use big endian internally, but to the program it is running, it must work as if it is little endian, as the program expects.

Quote

Forgot to answer that. MPQs are made little-endian even on big-endian systems I believe, and the BitConverter class will read as big-endian if I understand its behaviour correctly. That could make for interesting results.

If Mono does not do the conversion, then that would very severely break things, and the purpose of Mono is compatibility, so I see no reason for them to make it so programs running in Mono need to care about big endian on the target architecture.

Think of it this way. Programs that were only developed on Windows for the .NET Framework, which by design Mono is intended to be able to run, would not run properly (if at all) on a big endian system even in Mono if Mono was designed in the way you say. That's kind of like saying that a port of an x86 emulator to a big endian architecture should run the emulated x86 cpu in big endian mode instead of what it is supposed to be -- it just doesn't make sense.

Of course many parts would use big endian internally, but to the program it is running, it must work as if it is little endian, as the program expects.

Your argument makes sense, but then what's the use of the IsLittleEndian field? Maybe the BitConverter class is architecture dependent, and for independence, you would need to use the BinaryReader or something. Also, has anyone been able to run the test app on Mac or Linux successfully?

Your argument makes sense, but then what's the use of the IsLittleEndian field? Maybe the BitConverter class is architecture dependent, and for independence, you would need to use the BinaryReader or something.

Also, has anyone been able to run the test app on Mac or Linux successfully?

I would, but at the current time I cannot install mono because it requires a password (as of now I don't know it).

I would, but at the current time I cannot install mono because it requires a password (as of now I don't know it).

[quote=name:fatimid08]Your argument makes sense, but then what's the use of the IsLittleEndian field? Maybe the BitConverter class is architecture dependent, and for independence, you would need to use the BinaryReader or something. Also, has anyone been able to run the test app on Mac or Linux successfully?[/quote] Heh, I'm sure Microsoft has put in some weird things here and there in the .NET Framework classes that aren't particularly useful. Maybe if Microsoft made a version for some big endian architecture they would do that, but people who want to make things that are actually compatible aren't likely to implement something in a way that would be incompatible just because Microsoft intended to have it that way. ;)

Quote from fatimid08

Your argument makes sense, but then what's the use of the IsLittleEndian field? Maybe the BitConverter class is architecture dependent, and for independence, you would need to use the BinaryReader or something.

Also, has anyone been able to run the test app on Mac or Linux successfully?

Heh, I'm sure Microsoft has put in some weird things here and there in the .NET Framework classes that aren't particularly useful. Maybe if Microsoft made a version for some big endian architecture they would do that, but people who want to make things that are actually compatible aren't likely to implement something in a way that would be incompatible just because Microsoft intended to have it that way.

I like your map editor, so I gave this a shot. I installed Mono, and then tried to run your program, to no success. My OS is Ubuntu 7.10 Gutsy [code]laserdude@laserdude-desktop:~/MonoMPQ$ mono MpqTester.exe ** (MpqTester.exe:6863): WARNING **: The following assembly referenced from /home/laserdude/MonoMPQ/MpqTester.exe could not be loaded: Assembly: Microsoft.VisualBasic (assemblyref_index=1) Version: 8.0.0.0 Public Key: b03f5f7f11d50a3a The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/laserdude/MonoMPQ/). ** (MpqTester.exe:6863): WARNING **: Could not load file or assembly 'Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The entry point method could not be loaded laserdude@laserdude-desktop:~/MonoMPQ$[/code] It appears I don't have VB installed. I'd say it's pretty backwards for something 'cross-platform' to require something that's not cross platform.

I like your map editor, so I gave this a shot. I installed Mono, and then tried to run your program, to no success. My OS is Ubuntu 7.10 Gutsy

Code

It appears I don't have VB installed. I'd say it's pretty backwards for something 'cross-platform' to require something that's not cross platform.

I thought the VB runtime came with Mono, wtf... Found a few things or their page: [quote]Starting with Mono 1.2.3, packages of the Mono Visual Basic Compiler and Visual Basic Runtime are available at our Downloads page.[/quote] and also [quote]includes the Visual Basic 8 compiler written in Visual Basic 8, and Mainsoft's Visual Basic runtime for 2.0[/quote] and [quote]VB.NET compiler and runtime were released.[/quote] for the current 1.9 version That's why I decided to do it on VB.Net, because they said they packaged it with Mono. If you can't find it, I'll start porting it all to C# next week (I didn't use it in the first place because it takes me more time to work with C-like syntax compared to VB syntax). Also, the MoMA tool which analyzes wether or not everything I call is supported by Mono tells me it should all work, so I really don't know.

I thought the VB runtime came with Mono, wtf...

Found a few things or their page:

Quote

Starting with Mono 1.2.3, packages of the Mono Visual Basic Compiler and Visual Basic Runtime are available at our Downloads page.

and also

Quote

includes the Visual Basic 8 compiler written in Visual Basic 8, and Mainsoft's Visual Basic runtime for 2.0

and

Quote

VB.NET compiler and runtime were released.

for the current 1.9 version

That's why I decided to do it on VB.Net, because they said they packaged it with Mono. If you can't find it, I'll start porting it all to C# next week (I didn't use it in the first place because it takes me more time to work with C-like syntax compared to VB syntax).

Also, the MoMA tool which analyzes wether or not everything I call is supported by Mono tells me it should all work, so I really don't know.

This might be useful..not sure http://rpmfind.net/linux/rpm2html/search.php?query=mono(Microsoft.VisualBasic) Simply various Microsoft.VisualBasic runtimes for mono based on the OS you're running.

This might be useful..not sure
http://rpmfind.net/linux/rpm2html/search.php?query=mono(Microsoft.VisualBasic)

Simply various Microsoft.VisualBasic runtimes for mono based on the OS you're running.

I could collaborate with you on this project if you want, including helping with the VB to C# conversion, if you decide to do so. I also started an mpq library for .NET (but in C#) a while back. I think I had it coded to the point of being able to extract uncompressed files, but I haven't continued from there yet.

I could collaborate with you on this project if you want, including helping with the VB to C# conversion, if you decide to do so.

I also started an mpq library for .NET (but in C#) a while back. I think I had it coded to the point of being able to extract uncompressed files, but I haven't continued from there yet.