moog wrote on 2021-02-06, 13:06:

It really depends on your setup. I can understand that compiling LibreOffice on a 2009 laptop, even with SSD and maxed out RAM can take at least 10 hours... but with a current-day Ryzen and 32GB RAM you can do it in 40-50 minutes if you know what you're doing.

I was talking specifically about e_wise running in DOSBox extracting Counter Strike.

OTOH, I once compiled some Fedora gcc package on a SheevaPlug for 45 hours, IIRC 😉.

moog wrote on 2021-02-06, 13:06:

This actually looks promising, but needs more work. I've managed to compile this for Mono without issue. It's just that:

Mono would probably have been better. I tried dotnet core and have not had such luck so far, mostly because of XML build configuration crap hell, I guess 🙁.

moog wrote on 2021-02-06, 13:06:

2. I've got a dump full of files and no info about directory structures and filenames so I can even recover from this state:

Well, you know what the files are supposed to be, right? Is it not trivial to map the dumped files to the filenames you expect? Possibly by using hashes? (Presumably the mapping will always be the same every time the installer is unpacked.)

Jorpho wrote on 2021-02-06, 17:46:

moog wrote on 2021-02-06, 13:06:

2. I've got a dump full of files and no info about directory structures and filenames so I can even recover from this state:

Well, you know what the files are supposed to be, right? Is it not trivial to map the dumped files to the filenames you expect? Possibly by using hashes? (Presumably the mapping will always be the same every time the installer is unpacked.)

You can't be serious. This project should be a reliable, general-purpose WISE unpacker. That means, it cannot be coupled with file maps. We're supposed to be able to use it within and outside of Portage for any and all WISE installers. Can you imagine where would 7-zip, WinZip, RAR or GNU tar be if they behaved like this?

Ringding wrote on 2021-02-06, 15:03:

moog wrote on 2021-02-06, 13:06:

It really depends on your setup. I can understand that compiling LibreOffice on a 2009 laptop, even with SSD and maxed out RAM can take at least 10 hours... but with a current-day Ryzen and 32GB RAM you can do it in 40-50 minutes if you know what you're doing.

I was talking specifically about e_wise running in DOSBox extracting Counter Strike.

OTOH, I once compiled some Fedora gcc package on a SheevaPlug for 45 hours, IIRC 😉.

It takes 10 days to compile GCC on PS3.

moog wrote on 2021-02-09, 21:52:

Ringding wrote on 2021-02-06, 15:03:

OTOH, I once compiled some Fedora gcc package on a SheevaPlug for 45 hours, IIRC 😉.

It takes 10 days to compile GCC on PS3.

😁 😁 😁

I’ve never approached Virtual Pascal in the past, but now that I’ve done so because of e_wise, I am a bit puzzled as to how the original author built a DOS executable out of this. I can only choose from OS/2, Win32 or Linux. And also after downloading and skimming the WDOSX package (because that’s the DOS extender used in the e_wise binary package), it is not obvious to me how to produce a binary for DOS.

moog wrote on 2021-02-09, 21:52:

This project should be a reliable, general-purpose WISE unpacker.

Huh? I thought this project was "an ebuild for Counter-Strike 1.5 for Gentoo Linux" using a singular redistributable package.

If you want to expand the scope of this project to be "a reliable, general-purpose WISE unpacker", then learning enough Pascal to reimplement e_wise is the only sensible approach. Surely mashing together something with DOSBox would be anything but "reliable" and "general purpose"?

Ringding wrote on 2021-02-09, 22:19:

I’ve never approached Virtual Pascal in the past, but now that I’ve done so because of e_wise, I am a bit puzzled as to how the original author built a DOS executable out of this. I can only choose from OS/2, Win32 or Linux.

I guess he must have used an earlier version of Virtual Pascal. Anyway, I don’t care so much as long as I can get it (e_wise) to build & run somehow.

Jorpho wrote on 2021-02-09, 23:38:

Huh? I thought this project was "an ebuild for Counter-Strike 1.5 for Gentoo Linux" using a singular redistributable package.

That was my understanding as well. A static renaming database of some form would be a perfect fit for this job.

OK, guys, there's a misunderstand.
I'm writing an ebuild for Counter Strike.
Someone else is writing a WISE unpacker.

End-user expectations from an ebuild is that it installs requested software or assets. This is currently implemented. It will be followed up with ebuilds for FTEQW (engine) and FreeCS (libre data and game logic) in order to deliver an easy to use Counter-Strike experience for Gentoo users.
End-user expectations from any unpacker or de-archiving software, is that it reproduces the archive's content outside of the archive file. While WiseUnpacker clearly delivers much better performance, it's not perfect.

What e_wise can do better:
- work on Linux (must have) and current-day Windows (nice to have)
- preserve directory structure rather than rely on spawning Batch scripts that fill in for this shortcoming (must have)

What WiseUnpacker can do better:
- preserve directory structure (must have)

I expect to be working on more ebuilds of past proprietary games, which is why I will be using either WISE unpacking tool. Also users who install my ebuilds will probably be glad they build faster.

e_wise built from source using the latest Virtual Pascal (from 2006) works on Windows 10. I tried this today. But it does not build out of the box, because some parts of the home-grown gettext mechanism seem to be missing. I patched it and initialized all the string pointers by hand, statically. It works and generates the same output as the old binary. So at least this proves that one can learn from its source code how the file renaming works.

I also tested the Linux build from the latest Virtual Pascal, but it aborts with a runtime error similar to the one from the binary package, but it at least gets to the first file and crashes after having done some output and creating the file. Whereas the one from the binary package crashes immediately, without even displaying the banner, IIRC.

After all, this application runs natively on x86_32 and x86_64 Linux. In the latter case, of course, it must contain CONFIG_COMPAT_32=y.
It uses modify_ldt so the kernel must include it CONFIG_MODIFY_LDT_SYSCALL=y

1mkdir e_wise && cd e_wise
2curl -JOL http://kannegieser.net/veit/programm/e_wise.arj
37z x e_wise.arj
4chmod +x E_WISE_L
5mv E_WISE.INI e_wise.ini
6curl -JOL http://www.magiciso.com/Setup_MagicISO.exe
7i386 -R3 ./E_WISE_L Setup_MagicISO.exe .

Interesting! Indeed, both -R and -3 are necessary for it to not crash.

You know what? Screw it. I've posted the sources on https://github.com/grepwood/e_wise and right now they're decoded so anyone can actually work with them on a modern system. I'll be gradually re-writing this in plain C.

I like your initiative. However, if you are going to go through all this effort anyway, would you consider packaging this up in a distro-neutral format as well (or instead)? AppImage, Flatpak, or (if you must) Snap?

Since this is a binary game you're packaging anyway, a Gentoo ebuild doesn't really add much in terms of compiler optimisation or anything.

Translating from Pascal should actually be rather straight forward. If you need help with German, just ask!

If I find time, I’ll share my hacky patch that I made in order to make it build with Virtual Pascal during the weekend.

digger wrote on 2021-02-25, 22:28:

I like your initiative. However, if you are going to go through all this effort anyway, would you consider packaging this up in a distro-neutral format as well (or instead)? AppImage, Flatpak, or (if you must) Snap?

I'll consider.

digger wrote on 2021-02-25, 22:28:

Since this is a binary game you're packaging anyway, a Gentoo ebuild doesn't really add much in terms of compiler optimisation or anything.

No, that's wrong. Counter-Strike 1.5 can be played with FTEQW engine and FreeCS game logic - these 2 components are free software. The missing part is original freeware Counter-Strike 1.5 assets which were never officially distributed in other form than WISE installers. My undertaking must survive copyright bullying and therefore, this file must be delivered in pristine condition and then only as part of post-install action (I believe this is what Debian packages sometimes do) extracted so that we actually have the assets in a form useful to the engine and game logic.

Ringding wrote on 2021-02-26, 12:08:

Translating from Pascal should actually be rather straight forward. If you need help with German, just ask!

If I find time, I’ll share my hacky patch that I made in order to make it build with Virtual Pascal during the weekend.

Pull requests and a readme explaining how to even compile this fossil will be most appreciated.