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.

Attachments:

Post has been edited 1 time(s), last time on Jun 5 2008, 10:32 pm by fatimid08.

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.

Mac has no mem editor.

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

Mem editor will be a summer project for me.

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)

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

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 (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).


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.

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.

That is correct.

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.

Post has been edited 1 time(s), last time on Apr 18 2008, 9:52 am by ShadowFlare.

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).

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



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:

and also
and
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.

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.