NoNameNeeded

Ok, I noticed that it's missing (but I couldn't care less). So there shouldn't be any problems I guess. Well, thanks a lot!

Oh ok, I think I know what it might mean. The first line was already the way you suggested. In the second line there was 89 instead of 00 and so I changed it and saved the file and set it back to the normal comdl32.dll and it seems to work now. I can't believe it yet, is there any drawback? And how on earth did you do that?

What's that supposed to mean?

I tried the commonvcph.dll from version 6 (demo) but of course it doesn't work. It would have been a big surprise if it worked.

comdlg32.dll it is I've uploaded both the modified commonvcph file and a comdlg32.dll file so dumping them into the wavelab folder should suffice. https://workupload.com/file/WtwLCsTB3W3

That was to be expected. But does it crash when you redirect the file (as explained in my first post)?

Yes, that would be interesting. And it would also be interesting if redirecting to an older comdlg32.dll file works on 32Bit Win 7 because it does on Vista 32Bit.

Weird. But maybe that's part of the problem: Because it uses the new comdlg version it crashes. But at least it opens the dialog box (before it crashes) so it does seem to improve compatibility a bit. But on the other hand it also crashes when you redirect it to use an older comdlg version.

The fix applies to Windows Vista. And in Windows Vista it does fix the problem. But I'm not using Windows Vista. For those interested this is what a guy wrote on a forum about it: I can confirm that this fix will also work with my version (3) on Windows Vista 32Bit I don't know if it's a 64bit vs. 32Bit problem but unfortunately on Windows 7 64Bit it doesn't work. Would be interesting to see if it works on Windows 7 32Bit but I dont't have that.

I know that this problem also exists in much newer versions of this application, even Wavelab 5 has the same problem, so updating to version 3.04g can't change much. The reason why I mentioned the GetOpenFileNameW stuff is only that I hoped it might be helpful to anyone to track down the problem.

I've tried pretty much every Windows comdlg32.dll I could find from NT3.51 to Vista When I use the one from Windows 98 it kinda works but without the listbox, it's blank. But saving and opening files does work but it's very unstable and prone to crash. I then tried the Reactos version of this file and this one seems to work best. Absolutely stable but still without a working listbox. I don't know if that's important but redirecting to a comdlg32.dll file from Windows XP DOES work great on Windows Vista, the open/save dialog works without any problems. But not on Windows 7, unfortunately.

It does work in a virtual XP machine, yes. But that's not really what I wanted to achieve.

I've already tried that. Didn't change anything. What I also did is that I changed the function it calls from GetOpenFileNameA to GetOpenFileNameW As I've learned, the w-version of that function uses unicode. When I change the function the open/save dialogs do pop up (even without redirecting anything) but the file extensions seem to be in japanese and no file can be opened or saved, probably due to an incompatibility with Unicode (the application is old and so there is no unicode stuff) However, I was wondering if there is a kind of replacement function that I can used instead that doesn't need unicode?

I don't know if that's too much to ask but can someone build me a XP-compatible comdlg32.dll file that is self-contained, i.e. it doesn't depend on any other system files but has everything included that is needed to save or open files? If that is even possible? The reason why I ask is that I found out that my problem (see comments above) can be (almost) solved by redirecting to a comdlg32.dll file that comes with ReactOS (the Windows clone that will never be finished) and it seems to work ok except for the fact that the listbox is missing (the part of the open/save dialog box where you can navigate through folders or click on files etc.) I think that's due to the fact that ReactOS isn't Windows and so it can't retrieve the file list or something

No, I'm not in Russia neither is my IP russian. I think they must have configured something to display pages in russian if possible. I don't use the loader so the loader.ini flag would'nt really help anyway. I haven't really tested the browser thoroughly yet, so I don't know which webpages will (or would) also show up in russian. I did notice however that it crashes more often on youtube than it does with the regular chinese version. At first I thought it has to do with the cyrillic characters but now that youtube is in english, that can't be the reason. Strange. Update: No, it's not the russian version, it's also the chinese version that crashes frequently on youtube. Maybe it's a problem with version 2250 of the browser because with the older one that didn't happen.