Pidgin 2.6.6 on Windows 95 OSR 2.1?

[Nokiamies]

I have been trying to get Pidgin 2.6.6, last version of Pidgin for Windows 98/ME to run on Windows 95 OSR 2.0. However during startup I get error about missing call kernel32.dll:virtualallocex

As far as I am aware that call is exclusive for the Windows NT family of operating systems and does not exist on Windows 9x. On 98 it starts without error and I got some sort of theory why: Windows 95 is identified as 4.00 by version number which is same as NT. Windows 98 is 4.10. I think for some reason program thinks it is on NT4 which 2.6.6 can also be run on and fails on that that call. Is there way to spoof version for single program under Windows 95 to show it as 4.10 instead of 4.00 or other way work around that issue? Any help will be useful

[jumper]

Only if the check looks into the registry can the version be spoofed. This is rarely the case.

Is this the installer or the app itself? And what is the full, exact text of the message (including title)?

 

[Nokiamies]

4 hours ago, jumper said:

Only if the check looks into the registry can the version be spoofed. This is rarely the case.

Is this the installer or the app itself? And what is the full, exact text of the message (including title)?

 

Installer works just fine. That is error it is creating. In English that says "file PIDGIN.EXE is linked to missing export function KERNEL32.DLL:VirtualAllocEx". What really baffles me here is that call does not exist on Windows 9x to begin with only on Windows NT and when I run it on vanilla Windows 98 or ME without kernel ex or anything else it starts up just fine. If program would rely on that call it would not start to begin with on 98. Pidgin 2.6.6 is last officially supporting 9x platform when using standalone legacy GTK runtime (https://web.archive.org/web/20110106073509/http://developer.pidgin.im/wiki/Installing Pidgin#CanIrunPidginonWindows98ME). I just though it may have something to do with fact 95 identifies itself as 4.00.1111 whereas 98 is 4.10.2222. 4.00 is also kernel number on NT 4.0 which made me assume for reason unknown executable is thinking to be under Windows NT platform. While I can use PSI 0.10 under Windows 95 to connect my Jabber server I prefer Pidgin since it support text mode file transfers if transfer proxy fails.

here is files I used

http://nokiamies.net/files/sw/pidgin-2.6.6-no-gtk.exe

http://nokiamies.net/files/sw/gtk-runtime-2.6.10-rev-a.exe

[jumper]

98, SE, and ME do have VirtualAllocEx, only 95 doesn't. Use ImportPatcher or Dependency Walker to find all missing functions. If there are only a few, I can write a wrapper.

 

[Nokiamies]

40 minutes ago, jumper said:

98, SE, and ME do have VirtualAllocEx, only 95 doesn't. Use ImportPatcher or Dependency Walker to find all missing functions. If there are only a few, I can write a wrapper.

 

Interesting, I always though only NT had it. Well anyway it seems to be only be depend on VirtualAllocEx and VirtualFreeEx calls. Here is also dwi log from dependency walker I did under Windows 95 if you need it

pidgin.dwi

Edited Thursday at 09:22 AM by Nokiamies

[jumper]

I patched 6 bytes to convert the VirtualAllocEx call into a working VirtualAlloc call, 5 bytes for VirtualFreeEx to VirtualFree, and 3 bytes to update the checksum to ward off malware false-positives. Check your messages for an attachment.

Pidgin 2.6.6 (unpatched) does launch on my 98 system, but isn't stable unless I enable KernelEx and set it to Win2K mode. So more patches will probably be needed.

 

[Nokiamies]

2 hours ago, jumper said:

I patched 6 bytes to convert the VirtualAllocEx call into a working VirtualAlloc call, 5 bytes for VirtualFreeEx to VirtualFree, and 3 bytes to update the checksum to ward off malware false-positives. Check your messages for an attachment.

pidgin.dll gave error about device not functioning. I decided to do full DLL check comparing 95 and 98SE and here is calls missing from important dll

IsDebuggerPresent:

program files/common files/gtk folder (gtk legacy runtime)
pango-querymodules.exe
libpangowin32-1.0-0.dll
libpango-1.0-0.dll
libgtk-win32-2.0-0.dll
libgthread-2.0-0.dll
libgobject-2.0-0.dll
libgmodule-2.0-0.dll
libglib-2.0-0.dll
libgdk-win32-2.0-0.dll
libgdk_pixbuf-2.0-0.dll
slibatk-1.0-0.dll
gspawn-win32-helper.exe

 

c:\program files\pidgin folder (install)
InterlockedCompareExchange:
pidgin.dll
libymsg.dll
libxml2.dll
libpurple.dll
liboscar.dll
libxml2.dll

2 hours ago, jumper said:

Pidgin 2.6.6 (unpatched) does launch on my 98 system, but isn't stable unless I enable KernelEx and set it to Win2K mode. So more patches will probably be needed.

 

Interesting. I have ran 2.6.6 on Vanilla Windows 98SE and ME for years without problems. Maybe it is cpu or ram related? I mostly tested it on Pentium 2/3 and K6 based systems. How did stability issue show up? Random bsoding or resource leak? Also I never tried it with less than 256mb ram.

[jumper]

I'm only seeing IsDebuggerPresent in libglib-2.0-0.dll. I think the others all import from libglib-2.0-0.dll.

With ImportPatcher you can patch:

• IsDebuggerPresent=GetCurrentProcess or
• IsDebuggerPresent=GetErrorMode

 

I'm seeing (right-click on folder, Find, Containing text) InterlockedCompareExchange in libxml2.dll and nspr4.dll. Try patching with ExitProcess for now. The code will need to be patched.

The instability is C Runtime Library errors upon second launch. Hopefully just my system.

 

 

[awkduck]

Not sure if this will improve the situation or not (maybe you solved it already?), but you could try using other builds of GTK+2. Pidgin does offer a package without GTK. Even if the builds are newer, they may have been built with different build environments and configurations. But, it should be noted that running with a global set of GTK dlls can be irritating (if you need more than one set of Global GTK dll versions).

OTOH, building Pidgen and GTK+2 with a different build environment and config could also solve the issue. I think Mingw32 has flags to set the max winver to support during compile (I believe there was two required).

I'm guessing an old Mingw32 and Msys would work (still on sourceforge); probably shouldn't need Cgywin's userland). The source documentation may provide a hint. There are times when setting the max winver flags can bork the build, if the code explicitly asks for something. But, GTK is less likely to cause an issue there. And from the looks of this issue, Pidgen probably wouldn't either, or it could be an easy fix.

Maybe of interest, this guy tested some different win32 GCC versions, and TDM-GCC may also be an option. You can find userland (msys) included versions of Mingw and TDM-GCC floating around on the net. Its harder to find, but there are fully bundled versions of Cgywin floating around, too (more useful for the usreland).

Don't have my old GTK+2 builds around anymore. Kept GTK+1.3 only, it seems. But that doesn't mean someone else's builds couldn't improve the situation.

Maybe here or here? You can also check on "mmnt dot ru slash int". Search gtk+ and then within results something like win32.

[Nokiamies]

10 hours ago, jumper said:

I'm only seeing IsDebuggerPresent in libglib-2.0-0.dll. I think the others all import from libglib-2.0-0.dll.

With ImportPatcher you can patch:

• IsDebuggerPresent=GetCurrentProcess or
• IsDebuggerPresent=GetErrorMode

 

I'm seeing (right-click on folder, Find, Containing text) InterlockedCompareExchange in libxml2.dll and nspr4.dll. Try patching with ExitProcess for now. The code will need to be patched.

 

 

I did patching and it first resulted illegal process on nss3.dll. So I decided try one from Retrozilla since I knew that version of library sure works on 95. Well it got as far as having tray icon but then it gave these two errors.

Interestingly enough I tried it again, only this time I had also irfanview open  to save screenshots and it resulted fault and illegal process on it too, but interestingly enough it did not crash. I guess it is since both rely on Microsoft VC6 runtime

 

11 hours ago, jumper said:

The instability is C Runtime Library errors upon second launch. Hopefully just my system.

It might be some runtime you have/do not have that is/is not in my system. What service did you add on pidgin? Jabber/XMPP? Some services are done by plugins and I never tested those.

5 hours ago, awkduck said:

Not sure if this will improve the situation or not (maybe you solved it already?), but you could try using other builds of GTK+2. Pidgin does offer a package without GTK. Even if the builds are newer, they may have been built with different build environments and configurations. But, it should be noted that running with a global set of GTK dlls can be irritating (if you need more than one set of Global GTK dll versions).

OTOH, building Pidgen and GTK+2 with a different build environment and config could also solve the issue. I think Mingw32 has flags to set the max winver to support during compile (I believe there was two required).

I'm guessing an old Mingw32 and Msys would work (still on sourceforge); probably shouldn't need Cgywin's userland). The source documentation may provide a hint. There are times when setting the max winver flags can bork the build, if the code explicitly asks for something. But, GTK is less likely to cause an issue there. And from the looks of this issue, Pidgen probably wouldn't either, or it could be an easy fix.

Maybe of interest, this guy tested some different win32 GCC versions, and TDM-GCC may also be an option. You can find userland (msys) included versions of Mingw and TDM-GCC floating around on the net. Its harder to find, but there are fully bundled versions of Cgywin floating around, too (more useful for the usreland).

Don't have my old GTK+2 builds around anymore. Kept GTK+1.3 only, it seems. But that doesn't mean someone else's builds couldn't improve the situation.

Maybe here or here? You can also check on "mmnt dot ru slash int". Search gtk+ and then within results something like win32.

I need look more into this. Pidgin is bit nitpick about GTK runtimes it needs. I used non GTK Pidgin installer and seperate legacy runtime. I mentioned these in earlier post.

On 9/17/2025 at 11:03 AM, Nokiamies said:

here is files I used

http://nokiamies.net/files/sw/pidgin-2.6.6-no-gtk.exe

http://nokiamies.net/files/sw/gtk-runtime-2.6.10-rev-a.exe

Thank you both for all help. I was never programmer myself, unless working with industrial machinery code is counted. Also this is stuff nobody teaches you since attitude is just buy new OS. I may not be professional this but I am slowly learning. I am pretty sure I can get this working eventually, but it requires lot of patience, debugging, curse words and time.

PSI 0.10 can do Jabber too and native Windows 95 support but it is very buggy and outdated XMPP feature wise compared to Pidgin 2.6.6. under Windows 9x which includes all nice features of newer Pidgin and compliance with multiple XMPP files transfer modes, even text mode fallback if all other fails which makes it more versatile in my use.