Jump to content

Audacity 2.3.0 fails to run on Windows XP


sdfox7

Recommended Posts

So I tried upgrading from Audacity 2.2.2 to version 2.3.0 (https://www.fosshub.com/Audacity.html). It was a no go. For reasons unknown, according to this Wiki, 2.3.0 is not 'supported' on Windows XP.

By reading the Audacity forum, it appears it could be an issue related to Visual C++, but I currently have several versions of that so I am stumped.

I don't know how to use Dependency Walker. Can someone else look into this? Version 2.3 seems to be a minor update to 2.2.

aud230.jpg

Link to comment
Share on other sites


It comes down to InitializeProcThreadAttributeList and DeleteProcThreadAttributeList, two kernel calls.

These two calls are the same that vsfilter uses. When I compiled vsfilter with v141_xp it didn't work.

I'm gonna quote a message I previously posted:

Quote

During the last few days I've been trying to compile the latest VSFilter for XP and it does compile with v141_xp toolset (and specifying /Zc:threadSafeInit-), but it doesn't work and ends up with an Invalid Access Memory Location (998) on run-time.

I noticed that two kernel calls are missing in Windows XP: InitializeProcThreadAttributeList and DeleteProcThreadAttributeList.

Unfortunately, these two functions have been introduced in Windows Vista.

InitializeProcThreadAttributeList is a bool.
It returns a zero value if it fails or a non-zero value if it succeeds.
It has lpAttributeList (which is the attribute list and it can be NULL to determine the buffer size required to support the specified number of attributes), dwAttributeCount (which is the count of attributes to be added to the list), dwFlags (which is a reserved parameter and it must be zero) and lpSize.

BOOL InitializeProcThreadAttributeList( LPPROC_THREAD_ATTRIBUTE_LIST lpAttributeList, DWORD dwAttributeCount, DWORD dwFlags, PSIZE_T lpSize );

DeleteProcThreadAttributeList is a void and thus it does not return a value. It simply has lpAttributeList which is the attribute list created by the InitializeProcThreadAttributeList function.

void DeleteProcThreadAttributeList( LPPROC_THREAD_ATTRIBUTE_LIST lpAttributeList );

Audacity is open source, but I've never compiled it. I tried to do it quickly and it does run, but it fails to create page-files and returns the error "Exception Processing Message c0000145 Parameters c00000fd 75b1bf7c 75b1bf7c 75b1bf7c.

 

https://github.com/audacity/audacity

Edited by FranceBB
Link to comment
Share on other sites

Still, it's always better to have statically compiled files that work on your system. I don't know which build you used, but I generally don't trust other people compiling it, not because of malicious intent, but because I don't know which parameters they used and which assembly optimisations they turned on as I generally use either MSVC with SSE2 or GCC targeting my own processor with SSE4. Some people managed to get better performances on Intel Parallel Studio, though, even on old hardware, but I've never used it. Still, whenever there aren't hand-written intrinsics, it all depends on the compiler ability to make them automatically: they'll never be as fast as the hand-written ones, but still.

Anyway, for this build, at least SSE2 are required. If you wanna try to run it without SSE2, you can compile it yourself by disabling all the assembly optimisations in the compiler options. That should output an executable compatible with old MMX processors with plain C code instructions.

As to the linking, I suggest you to turn on the static link because it's always better to include the dll. In an ideal world, you could dynamically compile and let users install and update the Redistributable. This way, you would allow users to keep the Redistributable updated and you wouldn't have to make a new release every time a security patch is released by Microsoft: as a matter of fact, your executable would benefit from the Redistributable already installed in the system, so whenever users update, your programme is updated too. Too good to be true, huh? Well, in the real world, you want to include the Redistributable in your executable for two main reasons: the first one is that not everyone have the C++ Redistributable installed on his/her system nor they keep them updated and the second one is that whenever an update comes out, you may wanna test it on your executable, 'cause it shouldn't break any functionality of your programme, but what if it does?

That's my humble opinion, though.

In a nutshell: whenever a programme is open source, statically compile it yourself targeting your system and CPU. ;)

Link to comment
Share on other sites

3 hours ago, someguy25 said:

Seems not working for me :dubbio:

Both the main executable and the wxWidgets DLLs, when inspected with a HexEditor, reveal dependencies on missing stub dlls  kernelxp.dll and advapixp.dll; I am not at all savvy in this field, but presumably these stub DLLs handle (redirected) API calls not present inside XP's proper dlls, i.e. kernel32.dll and advapi32.dll; obviously, more expert members here can elaborate on this, I have just scratched the surface... :whistle:

Perhaps @FranceBB forgot to include them in his package, or assumes they are to be easily found elsewhere... :huh: BTW, you'd also need msvcp140.dll and vcruntime140.dll present in the folder for the app to run, if, that is, you don't have the redistributable for MSVC++ 2015/2017 installed system wide...

Link to comment
Share on other sites

The name KERNELXP.DLL is used in Dibya's Extended Kernel. Either the Extended Kernel is expected, or it will conflict with the Extended kernel.

I would need to know what specific APIs are being used in KERNELXP.DLL to check the Extended Kernel.

Link to comment
Share on other sites

I'm sorry, I made a boo boo.

This is what happens when I test in my system only due to laziness to fire up a VM.

This is the link to the installer: Link

Tested and working in a VM.

@sdfox7 let me know anyway.

@VistaLover and @rloew yes, @Dibya made a redirect to handle calls not available in the original kernel long time ago 'cause v141_xp doesn't always output a runnable file: for instance, GetTickCount64 gets redirected to GetTickCount.

Edited by FranceBB
Link to comment
Share on other sites

5 hours ago, FranceBB said:

I'm sorry, I made a boo boo.

This is what happens when I test in my system only due to laziness to fire up a VM.

This is the link to the installer: Link

Tested and working in a VM.

@sdfox7 let me know anyway.

@VistaLover and @rloew yes, @Dibya made a redirect to handle calls not available in the original kernel long time ago 'cause v141_xp doesn't always output a runnable file: for instance, GetTickCount64 gets redirected to GetTickCount.

Guys your the best:worship:

be pavadinimo.JPG

Link to comment
Share on other sites

@sdfox7 it was working fine in my VM and it's working fine for @someguy25 as well, however in my VM I do have all the C++ Redistributable, .NET Framework and all the POSReady updates. ucrtbase it's included with the C++ Redistributable 2015, but I can include it, no problem. New installer: Link

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...