project64
project64 copied to clipboard
project64
Latest builds break Windows XP support
Tried to test Project64 on the only machine I got access to, which uses Windows XP SP3. When trying to open PJ64, I get the following error message.
Project64.exe - Entry point not found
The procedure entry point CancelIoEx could not be located in the dynamic link library KERNEL32.dll.
OK
I have confirmed that Windows XP support has been broken since Aug 18, 2017. Last good build: v2.4.0-425-g 631c471 17th August 2017
Bad commit: https://github.com/project64/project64/commit/47fd0632ff9cc547695b9c295c3a5d72454a8a94
@JunielKatarn Willing to look into this to see if it has a simple enough solution? Not a whole lot of interest in keeping XP support I'm afraid. Might be time to drop it? With code additions such as these and a strive for more accuracy in the near future, it might end up becoming a maintenance burden. @project64 what's your opinion on the matter?
it is not hard to fix it, when @shygoo add his debugger he said it would break XP. I would still like to fix it .. most likely it is just dynamically loading the function CancelIoEx, it might mean the debugger javascript section is broken on XP .. but that is fine
@oddMLan I'm willing, but I won't have time very soon.
Moreover, my personal builds at http://hyvart.com/download/project64 have been produced without Windows XP support for a while (buildbot-related reasons).
If someone else already has a diagnostic, I'll be happy to help testing.
The problem is here And examples of fixes could be https://github.com/dolphin-emu/dolphin/commit/9ee50a273098751e91046475d5f9b7468e3acb9e or this
I tested this on an XP VM today. After removing CancelIoEx, I still received an error with Project64-Audio. It all works fine using alternate plugins. I'd have to see about using a remote debugger to figure out why.
Should be fixed in: https://github.com/project64/project64/pull/1636
Can anyone confirm Windows XP still works fine with Project64? Especially the bundled GLideN64 plugin. Some API calls say Vista and above only so I'm not sure.
Addding (maybe irrelevant) information: the same issue happens under ReactOS x86 (the aim is NT 5.2). Ignoring that assert I can access to the program and start games on it. But the software is not correctly opened, so feels unstable.
ExceptionCode: c00000fd CS:EIP 1b:514c09 DS 23 ES 23 FS 3b GS 0 EAX: 03092000 EBX: 000b6fc8 ECX: 0308ae24 EDX: 03093678 EBP: 03093690 ESI: 00163ed8 ESP: 0309367c EDI: 000b6fc8 EFLAGS: 00010206 Address: <Project64.exe:114c09> (C:\Program Files\Project64 3.0\Project64.exe@400000) Frames: <Project64.exe:64a2b> (C:\Program Files\Project64 3.0\Project64.exe@400000) <Project64.exe:63e54> (C:\Program Files\Project64 3.0\Project64.exe@400000) <Project64.exe:653c8> (C:\Program Files\Project64 3.0\Project64.exe@400000) <Project64.exe:65107> (C:\Program Files\Project64 3.0\Project64.exe@400000) <Project64.exe:141eef> (C:\Program Files\Project64 3.0\Project64.exe@400000) <kernel32.dll:1c980> (C:\ReactOS\system32\kernel32.dll@7c620000) err:(/win32ss/user/user32/windows/messagebox.c:1048) MessageBox: L"The exception unknown software exception (0xc00000fd) occurred in the application at location 0x00514c09.\r\n\nClick on OK to terminate the program.\nClick on CANCEL to debug the program." err:(/win32ss/user/user32/windows/window.c:524) CreateWindowExW RegisterSystemControls (/win32ss/user/ntuser/message.c:946) err: Message WM_PAINT count 2 Internal Paint Set? FALSE (/ntoskrnl/ob/obwait.c:179) Invalid handle FFFFFFFF passed to NtWaitForMultipleObjects (/dll/win32/kernel32/client/except.c:612) Starting debugger: 'C:\ReactOS\System32\drwtsn32 -p 888 -e 1140 -g'
The debugger is not really starting.
This issue happens too under Windows XP (32 or 64 bits) in last nightly 1975a993
@julenuri ReactOS is still a thing...? Honestly, I doubt the Project64 developers would even consider it, compatibility-wise. Are there any stats on how many users it actually has worldwide? I'd imagine vastly more-people would use "WINE" on Linux distros to run Windows apps, than do ReactOS!
If you go to the homepage on here for this project (https://github.com/project64/project64) it does still say there that Windows XP is the minimum-requirement.
An average user would consider that this would apply to the latest Stable version (3.0.1), but not-necessarily the latest Dev (development) version. So... if the current stable version does not, in-fact, support Windows XP then surely those requirements should get amended?
Also: the Project64 website (https://www.pj64-emu.com) doesn't mention system specs anywhere I can find!
Nightlies use the default VS2015 toolchain, and mentioning the unexisting v142_xp toolset doesn't help much either. https://github.com/project64/project64/blob/develop/appveyor.yml https://github.com/project64/project64/pull/1642
If you care, it wouldn't hurt to try to compile the thing yourself, so that the switch could be a cakewalk here.
@mirh: I've downloaded what I think is the most-recent Visual C++ 2015 Redistributable to work under Windows XP (from https://www.microsoft.com/en-us/download/details.aspx?id=52685) but even after installing it, no-version of Project64 after the 2.3.2.202 release loads. There is no error-message, and all three files in the "Logs" folder remain empty.
Looks like 2.3.2.202 is also the last to support Windows Vista
If you test 2.4.0.1868 or one of the later milestone releases, the main window will load (unlike on XP), but when you double-click on any ROM, you just get:
Project64.exe - Entry Point Not Found The procedure entry point K32EnumProcessModules could not be located in the dynamic link library KERNEL32.dll
This was on a Vista Home Premium (32-bit) install with Service Pack 2, and the Platform Update.
According to this blog-post by Microsoft, if you get such an error it is because "you are running your application on an OS other than Windows 7 or Windows Server 2008 R2" because "some APIs [were] moved from psapi.dll to kernel32.dll". So on Vista, it looks like later versions of Project64 only look in kernel32.dll for those calls, and not in psapi.dll when running on Vista.
So, again, it would really help if someone could update both the GitHub landing-page and the Project64 official website to let users know what the last supported versions are for OSes below Windows 7!
Thanks
As far as I know, support for WinXP has been broken for years.
VS2015 has some bugs with platform toolset v140_xp and can produce broken code for WinXP. VS2017 and VS2019 are the latest versions that produce usable code with platform toolset v141_xp for WinXP.
I just tried running v3.0.1-5664-2df3434 and v4.0.0-5846-35c2da4 on my WinXP VM, they both quit silently after language selection.
@Jj0YzL5nvJ: yes, all of the latest versions will show the "Welcome" screen on XP, where you can choose the language, video plugin and ROM folder, but after that won't show the main UI, though there is no error. On Vista, you do get an error.
It would help if the README on the homepage for this Project could be updated by someone to say:
Operating System • Windows 7 SP1 and newer • Still using Windows XP or Vista? Go here and download version 2.3.2
It would also be nice if when you ran a newer version on either XP or Vista, they would show a message like this:
The default visual studio 2015 toolsets are v140, which isn't windows xp compatible. The CancelIoEx thing, isn't even a problem anymore since #2110.
Then it's mysterious why it crashes after language selection, but as far as vista is concerned, something is calling this function (probably one of the dependencies). I don't think it's probably all that much of an effort to bisect and get this working, but somebody has to spend its time tinkering a bit at least.
@mirh: likely not worth fixing, given Vista use-share thesedays will be tiny (going by StatCounter, XP as-of last-month had a share of just-under 0.4%; Vista is so-low they don't even bother to count it separately).
I'd just say that version 2.3.2 of Project64 is the last one for XP and Vista and update both the README on here, and the "Public Releases" page on the official website to make this clear.
@julenuri ReactOS is still a thing...? Honestly, I doubt the Project64 developers would even consider it, compatibility-wise. Are there any stats on how many users it actually has worldwide? I'd imagine vastly more-people would use "WINE" on Linux distros to run Windows apps, than do ReactOS!
Yes, it is still a thing. Users? I dunno. 4000 downloads/week the last 0.4.14 release. But this doesn't show the real activity. I should say that is pretty similar in both projects, acording to the last month of search in Google Trends comparison.
Anyway, there are people that still checks if their software works in our API, and debug things on it. So I attached the info for the ticket if helps in any way.
In the user-no-dev mode, I wonder if it should be as easy for the user like reverting that guilty commit, compile it, and everything will start at first.
PS: Well, and don't surprise if people are still using XP in 2022 or the Wii in 2025. :upside_down_face:
As I said, I'm not really expecting for much effort being needed. Of course you have to spend some hour playing with visual studio and bisecting though, but for as much as I know everything may be just as simple as dropping the stupid ass discord plugin.
The rule's just: if you care, that's enough to be worth it. If you don't, peace.
p.s. there's also plenty of kernel extenders that you can try alternatively p.p.s. if your system's bad enough that vista/7 ain't a choice, chances are linux (or at least, whatever the graphics driver for your ancient gpu) is going to suck even more
Based on the dates in this thread, it seems very possible to be Discord RPC, it 100% doesn't work in XP so should not be run on XP at least. If someone can try
- Running on XP with Discord RPC disabled (use a config file from a working version that has it disabled) and if that doesn't work
- Try to modify the code so it doesn't try to call the RPC library at all
Maybe we can see if that's all, or if there are more issues.
ReactOS is considered pre-alpha, so probably not anything we can do about that really other then wait for it to become more complete and stable.
This is just me thinking aloud but... I think even if we fix Windows XP support (which I don't think will be incredibly difficult), eventually it'll get broken again. And if not Windows XP, then Vista/7/8/8.1, etc. Maybe once Project64 supports Android and Linux it will be easier to fix issues with earlier versions of Windows, I'm not sure about that. But I will say drivers and software for Windows earlier then Windows 7 in 2022 is super rare and sometimes has bugs and limitations. Windows Vista and below are all EOL, and other operating systems are going to follow at some point. I think if you are still using Windows XP or an earlier version of Windows then Windows 7, it might be a good time to look into switching to something more modern and updated, be it Windows or Linux.
@flagrama: I've edited the "Project64.cfg" file to add the setting you requested:
[Settings] Current Language=English Enable Discord RPC=0
Testing in a Windows XP Home SP3 virtual-machine with Project64 release 3.0.0.5648 that change does indeed then allow the main UI to open... BUT going to Options then Configuration shows this:
Project64.exe - Entry Point Not Found The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll
If you click [OK], you are able to still access the Configuration window afterwards, though. (It would appear that function was introduced in Windows Vista).
Sadly, the virtual-machine I am using doesn't offer 3D acceleration, so I'm unable to test if a ROM works... but it does go to a black-screen with the error "glActiveTexture", unlike Vista, where there is a system-level error before this. So I'd suggest it may well then work, yes.
Anyone with a real XP install (or VM which offers GPU support) that could test and confirm?