Instructions for use

[jazir555]

How do you compile this program to use it? How do does the program function? I want to combine/extract multipart cab files. There are no written instructions on how to use this, i would appreciate if you could update the description with a tutorial.

[twogood]

Hi! What operating system are you using?

[jazir555]

Windows 10

…

On Mon, Apr 1, 2019, 10:04 PM David Eriksson ***@***.***> wrote: Hi! What operating system are you using? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#92 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeR3rx2jxZHrC3yGHe09WFsK3Y6fY7b7ks5vcuT7gaJpZM4cWwxD> .

[twogood]

Please go here to download unshield.exe:

https://ci.appveyor.com/project/twogood/unshield/build/artifacts

[twogood]

Did it work for you @jazir5 ?

[gingerbeardman]

I'm a very proficient macOS user and former Apple engineer, yet I had trouble getting anything out of unshield for a short while.

Finally, I did this:
unshield -d data1 x data1.cab

and then this:
unshield -d data2 x data2.cab

To get what I needed.

Note: no trailing filename or wildcard is needed.

[twogood]

Sorry for the non-obviousness @gingerbeardman !

The syntax with x to extract is meant to be similar to that of tar.

You should not need to extract individual .cab files, just run it on data1.cab and you should get all files.

[ericchristoffersen]

Hi People. First, I'm really glad this project exists. It was about 6 hours for me to get at the files I wanted.

What I wasn't happy about was a nearly endless set of problems with compiling and then running the program on native windows. Mostly the issues were with limitations and assumptions in the file parsing and construction code and I was maybe unlucky with some directory name choices. I don't see how windows people are supposed to use this if the directory separators are hard coded as '/'. What is the environment that this is supposed to run in on windows?

I finally lost it dealing with whatever visual studio was doing with cmake and then all the disjoint dependencies so pasted all the sources I needed into a new directory and hoovered them into a new vs2019 project - that let me iterate quickly. I still link a separate zlib but I slammed everything else under one roof, and then c++'d it.

I rewrote a bunch of the string and file parsing so work more robustly. I'm sorry I'm not playing well with others but this was expedient for me. Is there any interest in the changes here? Or should I just paste the sources up somewhere else. I used std::filesystem::path which worked really well. And regex was nice to eliminate more crazy. I have no idea about linux builds though, what assumptions I've violated especially wrt wchar_t and how difficult it might be to adapt it back to linux and non-cxx17 toolchains.

Edit: command I use now for unpack is:

unshield.exe -D 3 -d "d:\data\file 19.23 x1\output" x "d:\unpacktest.1\data2.cab"

The -D 3 lets me see all the intermediate stuffs which was useful until it finally started working.

Edit 2: Dumped it here:

https://github.com/ericchristoffersen/Unshield_MSVC2019

[twogood]

@ericchristoffersen Sorry about the Windows build issues, all Windows stuff is contributed and barely supported :) I'm glad you could make it work for your case! Maybe I should just kill the Windows "support" and request that people run unshield in Windows Subsystem for Linux (WSL)?

[ericchristoffersen]

Wow. Cool. I had no idea that the WSL existed. Not sure I want to spend my system drive space for that but... sorta cool.

The advice to not use windows would be a solid minimum. I can't understand in what way windows is supported today. Its really, really not. :) Either that or I totally missed the boat.

The existing directory code is just terrible with weird restrictions and it hurts linux as well. No support for unicode paths?

That new std::filesystem stuff is pretty terrific. For example there's a function called:

std::filesystem::create_directories

That would let you delete a bunch of mank.

I made more changes today - now almost everything is an object and data is kept in vectors.

Simpler and cleaner.

Thanks again for supprting this source and making it available here. I really appreciate it existing. The alternatives to porting this were vile.

[twogood]

@ericchristoffersen What zlib buld did you use? Because I think the primary issue with building unshield on Windows is that it can be built with different toolchains and the dependencies can be downloaded in various ways. And when adding support for one way, the other ones easily break.

[ericchristoffersen]

Building: zlib was no problem. Cmake ingestion by visual studio 2017 was a problem, I blame msvc, it totally ran off the rails and made a huge mess for this project.

The real issue is that once the sources are built this project totally won't work because it is hard coded to use '/' as a directory separator. Is hard coded to unix ascii paths. Plenty of cases throughout the project but first example look at the implementation of:

unshield/src/unshield.c

Line 94 in f097b07

static bool make_sure_directory_exists(const char* directory)/*{{{*/

Which is called from extract_file:

unshield/src/unshield.c

Line 367 in f097b07

static bool extract_file(Unshield* unshield, const char* prefix, int index)

See all the string processing and the hard coded forward slashes? The search for the '.'?

Here is more portable c++ version:

https://github.com/ericchristoffersen/Unshield_MSVC2019/blob/4b34e819bf7f1b43b6abb9d35f389c8cf706c894/src/unshield.cpp#L327

Really you should check out std::filesystem, is pretty cool, can eliminate a lot of old boilerplate.

[twogood]

I'm pretty sure that the Windows APIs handle forward slashes just fine?