Problems with handling WinRar archives on Windows 2000

[Jarda]

Hello, I still run Windows 200 SP4 and have problems with handling some WinRar archives made by new WinRar versions using Tcmd. I am simply unable to open these by one click in file manager. I got incorrect error message "Error in packed file XYZ.rar!" only, but I am pretty sure that the archive was correctly downloaded and is undamaged.

I googled a little and realized that E. Roshal supports no more Windows 2000 by new WinRar releases. But Tcmd does, moreover - Tcmd has wide Windows support starting from Windows 95! It´s all about proper unrar.dll library spreaded together with Tcmd. The current one is wrong, some procedures can not be handled by older OS (Windows 2000) But there is one simple solution - make your own unrar.dll too as some others (e.g. Altap Salamader creators) did:

http://forum.altap.cz/viewtopic.php?f=6&t=7464&p=27961&hilit=windows+2000+unrar#p27961
(Czech language only with some screenshots)

I know that the market share of Windows 2000 is not huge at this time but for sure larger than market share of Windows 95 or 98... And finally: Tcmd claims that support all Windows from 95 above - or not?

As I am not geek, I have no clue how technically difficult can be the releasing of patched library. But I downloaded and tested the new Altap Salamander file manager with bundled unrar library under Windows 2000. It works on all WinRar archives with no flaw.

[Dalai]

See these threads for explanation on the technical background as well as a DLL compiled to work on Win2k by milo1012:
BUG - unrar.dll 5.10.2 work not correctly in TCMD under W2K
Unrar on Windows 2000

Regards
Dalai

[Jarda]

See these threads for explanation on the technical background as well as a DLL compiled to work on Win2k by milo1012:
BUG - unrar.dll 5.10.2 work not correctly in TCMD under W2K
Unrar on Windows 2000

Regards
Dalai

Thanks, Dalai, for your quick answer, I read these threads before I created the bug thread.

I am not technician so I am unable to compile my own unrar.dll file. The default one installed with Tcmd 9.0 beta 6 unfortunately works only on some archives (probably made by older WinRar versions) as well as the modified one 5.40.2 compiled by "milo1012" (I simply renamed the default one and copied the modified unrar.dll file to the Tcmd directory).

When I use the same Tcmd version on Windows 7, I can open the archive correctly instead of getting the error message as on Windows 2000...

[Dalai]

I'm not sure if TC always falls back to unrar9x.dll on Win2k (and doesn't use unrar.dll at all), but I guess it does. So instead of overwriting unrar.dll you need to replace unrar9x.dll.

Regards
Dalai

[Jarda]

I'm not sure if TC always falls back to unrar9x.dll on Win2k (and doesn't use unrar.dll at all), but I guess it does. So instead of overwriting unrar.dll you need to replace unrar9x.dll.

Regards
Dalai

I just replaced original unrar9x.dll from Tcmd 9.0 beta 6 installer with the modified unrar.dll and voilá - it works! Vielen Dank!

[ghisler(Author)]

I have tried to compile the UNRAR DLL with Visual Studio 2005, and it works OK. However, it does not work on Windows NT 4, even when loading the TimeZone specific conversion functions dynamically. So apparently other functions are also missing.

Does anyone know a tool to find out which functions in a DLL are not available on a Windows version? I only know the fileinfo plugin, but that doesn't load on Windows NT4.

Furthermore, the self-compiled dll doesn't load on Windows 9x/ME due to the used Widechar functions.

[Dalai]

2ghisler(Author)
Maybe Dependency Walker works on NT4. Maybe PE Viewer plugin loads on NT4.

Regards
Dalai

[milo1012]

2Ghisler
You can use an old 1.x version of the fileinfo plugin for NT 4.0.
For example wlx_fileinfo191.zip will still work on NT 4.0. I can upload it if needed.

Anyway, I already explained in this post that these functions are missing for NT 4.0:
CreateHardLinkW
GetLongPathNameW

GetLongPathNameW can be easily swapped in VC++ by using the substitute functions from NewAPIs.h.
CreateHardLinkW can probably be replaced with MoveFileEx(), see for example this article:
http://blog.delphi-jedi.net/2008/04/12/ntfs-hardlinks-and-moving-files/

I considered doing it myself, but I don't think that the target audience for NT 4.0 is even measurable nowadays.

As for Win9x: I don't think that it's possible. Too many function changed since the last Win9x capable version.
You'd have to swap functions or make dynamically load them in nearly every C++ module, and even then you'd have to look for things like CreateHardLink() to be skipped for Win9x.

Additionally:I think the DLL uses and requires SSE (OS.hpp uses <intrin.h> to use SSE compiler intrinsics)
So if you want to make the long run, you'd need to add a check for the processor supporting SSE, because the DLL may load w/o problems, but as soon as you try to decompress, things will most likely crash. I'm not sure if you can catch the machine opcode exception in such case, and also I'm not sure if NT 4.0 fully supports SSE (at least not in every SP level).


Update: I forgot the main thing: the MSVC 2005 runtime doesn't support NT 4.0 AFAIK, it only supports Windows 98, ME, 2000 and above.
MSVC 2003 (.NET) is the last runtime to support Windows NT 4.0 and 95.
So you'd need to switch to 2003, but then you will not be able to use (compile) the stock SSE intrinsic function libs used by the current source, as some of them only work on 2005 and above.

[Horst.Epp]

I don't understand any try to make TC 9.0 working in NT4 or Win9x
Users of this old outdated systems can still use older TC versions.
Any effort to fully support such systems is wasting time.
Also making a bug report for TC 9 while WinRAR no longer supports such systems at all is useless.