0.64 don´t run on W2k

[Jarda]

Hi,

I try to run XnViewMP 0.64 on Windows 2000 SP4 where v. 0.61 worked fine. Unfortunately there is no way to start the app - I downloaded the zipped one and manually rewrite the 0.61; after double click the exe file nothing happened. So I deleted the entire folder and unpack the archive to the empty folder with the same results. Please can You test/confirm the bug?

Jarda

[xnview]

Strange, i have only change the version of Qt, perhaps Qt doesn't support anymore W2K

[XnTriq]

The procedure entry point RtlCaptureContext could not be located in the dynamic link library KERNEL32.dll.

[Jarda]

I am sorry if You find the following sentences too stupid as I am not programmer:

Can be this bug fixed (e.g. updating the DLL) or workarounded?

BTW: I see in XnView 2.13 changelog that is declared as the last version with W2k support - is the reason for dropping support for W2k in next versions of XnView the same? Is dropping support for W2k to the very same time as for W95 really necessary?

[m.Th.]

I am sorry if You find the following sentences too stupid as I am not programmer:

No problem.

Can be this bug fixed (e.g. updating the DLL) or workarounded?

Theoretically, yes.
Practically, well... there are some complications.

By far, the very best solution is to "upgrade" to Windows 7 (highly recommended) or Windows XP. Of course, also Windows 8.1 is a very viable option if you want it. But this depends on the specs of your computer. Don't be afraid, the newer versions of Windows aren't so resource hogs compared with Win 2k. Also, win2k is a server OS. Perhaps you want to upgrade to newer versions? Windows 2003, 2003 R2 and especially newer editions (2008, 2012 etc.) are much much better OSes than Win 2000. I can recommend them with ease, even if I'm not a fan of Microsoft.

...but if you cannot drop the Win 2k from there (because it is a server?) then you have problems:

Each program relies its functionality on a gazillion of services (functions, procedures etc.) provided by the OS. This bunch of functions and procedures ("services") is called API (Application Programming Interface) and this API is organized in DLLs. One of the big problems in such situations - which happens also here - is that the code who relies heavily on the API isn't programmer's code (eg. Pierre) but the code of the 3rd party libraries which Pierre uses (in this case Qt). This, plus the fact that, in order to survive, Digia (Qt maker) has to support the latest and greatest gives us the almost 0 (zero) possibility to support this thing from the program's side.

OTOH, win2k is not supported anymore so no "official" updates, especially for such a core DLL like the KERNEL32.dll. Replacing it by hand with a newer version (from where?) can lead to very nasty side effects in OS itself, ranging from non-booting at all (DLL version mismatch), BSODs, missing procedure entry points (your case), and perhaps the worst, everything will be "ok" just that the data isn't saved, the USB isn't recognized, the screen isn't painted etc.

A slightly less dangerous version of the above is to put the newer KERNEL32.dll in the same folder with the program and pray to be recognized (and loaded) by the program instead of the OS' one, to NOT be recognized by other programs, to be everything ok etc. etc. etc.

Returning to the beginning: Put a newer version of Windows if you can. It will help you in many ways, not only in XnViewMP case.

BTW: I see in XnView 2.13 changelog that is declared as the last version with W2k support - is the reason for dropping support for W2k in next versions of XnView the same? Is dropping support for W2k to the very same time as for W95 really necessary?

Most probably yes. The APIs (see above for explanation) are updated in waves. And usually when an API is updated, they are updated with new subsystems. For ex. the difference from version A to version B isn't 2 or 3 utility functions but new big areas which are covered: Unicode, Right-to-Left writing, 3D drawing, theming, complex drawing effects (transparency, gradients on controls, animations etc.), Touch, USB3 support, SSD support - things like this. A "normal" programmer like us and even like Digia or other companies, is/are not able to do this 'by hand' alone if the OS doesn't support it.

W95-98 were the editions of the Desktop line of OSes, win2k was the edition for the Server line. I know for sure that the both lines share enough code (of course, is a very normal phenomenon) and hence is very normal that a certain infrastructure feature to be added simultaneously in the next generation of the Windows editions: Windows XP (internal version: Win NT 5.1) and Windows Server 2003 (internal: Win NT 5.2).

[CameronD]

...
BTW: I see in XnView 2.13 changelog that is declared as the last version with W2k support - is the reason for dropping support for W2k in next versions of XnView the same? Is dropping support for W2k to the very same time as for W95 really necessary?

It was discussed here and relates to the compilers used to build XnView.

W95-98 were the editions of the Desktop line of OSes, win2k was the edition for the Server line....

Not quite. win2k was the "pro" desktop. There was also a separate 2k server edition.

[XnTriq]

BTW: I see in XnView 2.13 changelog that is declared as the last version with W2k support - is the reason for dropping support for W2k in next versions of XnView the same? Is dropping support for W2k to the very same time as for W95 really necessary?

Good news: XnView Classic v2.20 will run on Windows 2000. I don't know what kind of tweaking Pierre did, but the toolbar works flawlessly now in both browse and view mode. No problems with skins, flat buttons, button text or customization!