Firstly, I'm not a Linux user. I'm a Windows programmer but I have a passing knowledge of Linux (and several friends who are Linux programmers). I write a Windows application which gets launched as a child process by a popular Linux DAW. My program was first written many years ago when the (then) current version of Wine was about v0.9.58. Over a hundred people are using my program with old versions of Wine and I've had no complaints so far.
Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function). Both customers went to a web site called WineTricks from where they were able to install an alternative version of MSVCP60.dll. My app now gets past the place where it previously crashed although it now crashes further on... :-(
It looks as if the MSVC6 runtime module(s) that now come with Wine aren't the same as the ones from v0.9.58. Either they're different versions of the Microsoft DLLs or maybe they're now being implemented by somebody else, perhaps as part of Wine development? Either way, they don't work with my particular app any more.
I still have Visual C++6 installed on an old computer, together with both the source code and the (InstallShield) packager for my original app. So is there anything I can do to make this work? For example, do I need to link against a particular version of the MSVC6 runtime? Or do I need to configure my packager so that it specifically distributes the runtime modules that my app linked to? I never did that in the past - because whichever runtime came with Wine seemed to work. Any advice?
John
Hello John!
On 06/15/2012 06:22 AM, John Emmas wrote:
Firstly, I'm not a Linux user. I'm a Windows programmer but I have a passing knowledge of Linux (and several friends who are Linux programmers). I write a Windows application which gets launched as a child process by a popular Linux DAW. My program was first written many years ago when the (then) current version of Wine was about v0.9.58. Over a hundred people are using my program with old versions of Wine and I've had no complaints so far.
Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function). Both customers went to a web site called WineTricks from
That is fairly trivial to figure out. Start your app with Wine on the command line and it will crash with an exception: Call from <address> to unimplemented function MSVCP60.<function>
Once you have those please open a bug on http://bugs.winehq.org/ for them.
where they were able to install an alternative version of MSVCP60.dll. My app now gets past the place where it previously crashed although it now crashes further on... :-(
It looks as if the MSVC6 runtime module(s) that now come with Wine aren't the same as the ones from v0.9.58. Either they're different
MSVCP60.dll wasn't available in wine-0.9.58. It was introduced in wine-1.3.19. They were probably using the dll that came with your app or installed it from somewhere else.
versions of the Microsoft DLLs or maybe they're now being implemented by somebody else, perhaps as part of Wine development? Either way, they don't work with my particular app any more.
Please open a bug for those issues too.
I still have Visual C++6 installed on an old computer, together with both the source code and the (InstallShield) packager for my original app. So is there anything I can do to make this work? For example, do
Open the bug reports :) If there is a free downloadable version/demo that exhibits the same issues please add it to the "URL" field.
bye michael
On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote:
Hello John!
On 06/15/2012 06:22 AM, John Emmas wrote:
Firstly, I'm not a Linux user. I'm a Windows programmer but I have a passing knowledge of Linux (and several friends who are Linux programmers). I write a Windows application which gets launched as a child process by a popular Linux DAW. My program was first written many years ago when the (then) current version of Wine was about v0.9.58. Over a hundred people are using my program with old versions of Wine and I've had no complaints so far.
Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function). Both customers went to a web site called WineTricks from
That is fairly trivial to figure out. Start your app with Wine on the command line and it will crash with an exception: Call from <address> to unimplemented function MSVCP60.<function>
Once you have those please open a bug on http://bugs.winehq.org/ for them.
Thanks for the suggestion Michael,
I'm still trying to track this down with my 2 customers but one of them told me something very interesting this afternoon. It seems that the more recent versions of Wine have 2 distinct modes:- a 'native' mode (which he thinks uses genuine Microsoft DLLs) and some other mode which uses what he called 'fake' DLLs. The native mode seems to be working. It's the other mode that crashes. I need to check if that's the same with the second customer but in the meantime, can anyone confirm if these two modes do co-exist these days? It's very different from my older Wine which used only Microsoft DLLs AFAIK. I should have some better info next week.
John
On Fri, Jun 15, 2012 at 11:59 PM, John Emmas johne53@tiscali.co.uk wrote:
On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote:
Hello John!
On 06/15/2012 06:22 AM, John Emmas wrote:
Firstly, I'm not a Linux user. I'm a Windows programmer but I have a passing knowledge of Linux (and several friends who are Linux programmers). I write a Windows application which gets launched as a child process by a popular Linux DAW. My program was first written many years ago when the (then) current version of Wine was about v0.9.58. Over a hundred people are using my program with old versions of Wine and I've had no complaints so far.
Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function). Both customers went to a web site called WineTricks from
That is fairly trivial to figure out. Start your app with Wine on the command line and it will crash with an exception: Call from <address> to unimplemented function MSVCP60.<function>
Once you have those please open a bug on http://bugs.winehq.org/ for them.
Thanks for the suggestion Michael,
I'm still trying to track this down with my 2 customers but one of them told me something very interesting this afternoon. It seems that the more recent versions of Wine have 2 distinct modes:- a 'native' mode (which he thinks uses genuine Microsoft DLLs) and some other mode which uses what he called 'fake' DLLs. The native mode seems to be working. It's the other mode that crashes. I need to check if that's the same with the second customer but in the meantime, can anyone confirm if these two modes do co-exist these days? It's very different from my older Wine which used only Microsoft DLLs AFAIK. I should have some better info next week.
John
You can set this for each dll (in winecfg for example), it's not a some kind of mode. Have a look at the wiki for winecfg [1].
- Matijn
On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote:
On 06/15/2012 06:22 AM, John Emmas wrote:
Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function).
That is fairly trivial to figure out. Start your app with Wine on the command line and it will crash with an exception: Call from <address> to unimplemented function MSVCP60.<function>
Once you have those please open a bug on http://bugs.winehq.org/ for them.
Thanks Michael,
That version number should have been 1.3.35 BTW, not 1.5.35. I'll file a bug report tomorrow but in the meantime it looks like the missing function is std::ios_base::Init() (it's probably the constructor for the Init class). I'm going from a backtrace that I got when I tried Crossover Linux (which exhibited the same problem).
If anyone thinks of any useful information I'll add it to the bug report.
John
BACKTRACE FOLLOWS:- Unhandled exception: unimplemented function msvcp60.dll.??0Init@ios_base@std@@QAE@XZ called in 32-bit code (0x7b83aed2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7b83aed2 ESP:0033fcc8 EBP:0033fd2c EFLAGS:00000212( - -- I -A- - ) EAX:7b827985 EBX:7b8961e8 ECX:00000000 EDX:80000100 ESI:80000100 EDI:004e120c Stack dump: 0x0033fcc8: 0033fd4c 00000008 7bca774c 80000100 0x0033fcd8: 00000001 00000000 7b83aed2 00000002 0x0033fce8: 7e50f460 7e51415b 00110000 00000000 0x0033fcf8: 00000000 7ee6863c 7ee6863c 00431870 0x0033fd08: 0033fd58 7ee186e9 0000000d 004ef298 0x0033fd18: 7ee6863c 7e090000 7b83ae8a 7ee6863c Backtrace: =>0 0x7b83aed2 in kernel32 (+0x2aed2) (0x0033fd2c) 1 0x7e50f3f8 in msvcp60 (+0x2f3f7) (0x0033fd5c) 2 0x7e4f4065 in msvcp60 (+0x14064) (0x0033fdc0) 3 0x00433f55 in ardourxchange (+0x33f54) (0x0033fdc0) 4 0x004a9fde in ardourxchange (+0xa9fdd) (0x0033fe70) 5 0x7b85b23c call_process_entry+0xb() in kernel32 (0x0033fe88) 6 0x7b85c40f in kernel32 (+0x4c40e) (0x0033fec8) 7 0x7bc72a70 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8) 8 0x7bc7547d call_thread_func+0x7c() in ntdll (0x0033ffa8) 9 0x7bc72a4e RtlRaiseException+0x21() in ntdll (0x0033ffc8) 10 0x7bc4b8fe call_dll_entry_point+0x61d() in ntdll (0x0033ffe8) 0x7b83aed2: subl $4,%esp Modules: Module Address Debug info Name (73 modules) PE 340000- 352000 Deferred zlib1 PE 400000- 5e1000 Export ardourxchange PE 5f0000- 6c9000 Deferred iconv PE 10000000-100ee000 Deferred libxml2 PE 5f400000-5f4f2000 Deferred mfc42 PE 6f140000-6f198000 Deferred libsndfile-1 ELF 7b800000-7ba16000 Dwarf kernel32<elf> -PE 7b810000-7ba16000 \ kernel32 ELF 7bc00000-7bcc4000 Dwarf ntdll<elf> -PE 7bc10000-7bcc4000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7e086000-7e0b9000 Deferred uxtheme<elf> -PE 7e090000-7e0b9000 \ uxtheme ELF 7e0fc000-7e102000 Deferred libxfixes.so.3 ELF 7e1d8000-7e1f9000 Deferred libexpat.so.1 ELF 7e1f9000-7e224000 Deferred libfontconfig.so.1 ELF 7e224000-7e22d000 Deferred libxi.so.6 ELF 7e22d000-7e232000 Deferred libxrandr.so.2 ELF 7e232000-7e23b000 Deferred libxrender.so.1 ELF 7e23b000-7e241000 Deferred libxxf86vm.so.1 ELF 7e241000-7e262000 Deferred imm32<elf> -PE 7e250000-7e262000 \ imm32 ELF 7e262000-7e37f000 Deferred libx11.so.6 ELF 7e37f000-7e38e000 Deferred libxext.so.6 ELF 7e38e000-7e3a7000 Deferred libice.so.6 ELF 7e3a7000-7e3b1000 Deferred libsm.so.6 ELF 7e3b1000-7e446000 Deferred winex11<elf> -PE 7e3c0000-7e446000 \ winex11 ELF 7e446000-7e4b2000 Deferred libfreetype.so.6 ELF 7e4b5000-7e4bf000 Deferred libxcursor.so.1 ELF 7e4d2000-7e569000 Dwarf msvcp60<elf> -PE 7e4e0000-7e569000 \ msvcp60 ELF 7e569000-7e5df000 Deferred rpcrt4<elf> -PE 7e570000-7e5df000 \ rpcrt4 ELF 7e5df000-7e6e6000 Deferred ole32<elf> -PE 7e600000-7e6e6000 \ ole32 ELF 7e6e6000-7e7dd000 Deferred comctl32<elf> -PE 7e6f0000-7e7dd000 \ comctl32 ELF 7e7dd000-7e9ee000 Deferred shell32<elf> -PE 7e7f0000-7e9ee000 \ shell32 ELF 7e9ee000-7ea58000 Deferred shlwapi<elf> -PE 7ea00000-7ea58000 \ shlwapi ELF 7ea58000-7eb17000 Deferred gdi32<elf> -PE 7ea60000-7eb17000 \ gdi32 ELF 7eb17000-7ec57000 Deferred user32<elf> -PE 7eb30000-7ec57000 \ user32 ELF 7ec57000-7ec7c000 Deferred mpr<elf> -PE 7ec60000-7ec7c000 \ mpr ELF 7ec7c000-7ec8f000 Deferred libz.so.1 ELF 7ec8f000-7ecfe000 Deferred wininet<elf> -PE 7eca0000-7ecfe000 \ wininet ELF 7ecfe000-7ed5f000 Deferred advapi32<elf> -PE 7ed10000-7ed5f000 \ advapi32 ELF 7ed5f000-7ed72000 Deferred libresolv.so.2 ELF 7ed76000-7ed7a000 Deferred libxinerama.so.1 ELF 7ed7a000-7ed92000 Deferred version<elf> -PE 7ed80000-7ed92000 \ version ELF 7ed92000-7edb3000 Deferred iphlpapi<elf> -PE 7eda0000-7edb3000 \ iphlpapi ELF 7edb3000-7ede4000 Deferred ws2_32<elf> -PE 7edc0000-7ede4000 \ ws2_32 ELF 7ede4000-7ee72000 Deferred msvcrt<elf> -PE 7ee00000-7ee72000 \ msvcrt ELF 7efba000-7efe0000 Deferred libm.so.6 ELF 7efe2000-7efe6000 Deferred libxau.so.6 ELF 7efe6000-7f000000 Deferred wsock32<elf> -PE 7eff0000-7f000000 \ wsock32 ELF b7c31000-b7c37000 Deferred libxdmcp.so.6 ELF b7c39000-b7c3d000 Deferred libdl.so.2 ELF b7c3d000-b7d6b000 Deferred libc.so.6 ELF b7d6b000-b7d83000 Deferred libpthread.so.0 ELF b7da3000-b7ee5000 Dwarf libwine.so.1 ELF b7ee6000-b7f03000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 winewrapper.exe 00000009 0 0000000c services.exe 0000001d 0 0000001c 0 00000016 0 00000015 0 00000013 0 0000000e 0 0000000d 0 00000010 winedevice.exe 0000001a 0 00000017 0 00000012 0 00000011 0 00000018 plugplay.exe 0000001e 0 0000001b 0 00000019 0 0000001f explorer.exe 00000020 0 00000021 (D) C:\Program Files\ArdourXchange\ArdourXchange.exe 00000022 0 <== System information: Wine build: wine-1.4-6831-gf832abc Platform: i386 Host system: Linux Host version: 2.6.19-4-rt
On Fri, Jun 22, 2012 at 3:38 PM, John Emmas johne53@tiscali.co.uk wrote:
If anyone thinks of any useful information I'll add it to the bug report. ... BACKTRACE FOLLOWS:- Unhandled exception: unimplemented function msvcp60.dll.??0Init@ios_base@std@@QAE@XZ called in 32-bit code (0x7b83aed2).
This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109
You could add a comment there instead of opening a new bug that could end up as being duplicate. I suggest you to get a new backtrace with wine debug symbols installed (if possible in wine 1.5.7).
Best wishes, Bruno
On 22 Jun 2012, at 20:17, Bruno Jesus wrote:
On Fri, Jun 22, 2012 at 3:38 PM, John Emmas johne53@tiscali.co.uk wrote:
... BACKTRACE FOLLOWS:- Unhandled exception: unimplemented function msvcp60.dll.??0Init@ios_base@std@@QAE@XZ called in 32-bit code (0x7b83aed2).
This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109
Thanks Bruno,
The problem seems to have been around for a very long time. Is it proving difficult to track down or something?
John
On Fri, Jun 22, 2012 at 5:27 PM, John Emmas johne53@tiscali.co.uk wrote:
On 22 Jun 2012, at 20:17, Bruno Jesus wrote:
... BACKTRACE FOLLOWS:- Unhandled exception: unimplemented function msvcp60.dll.??0Init@ios_base@std@@QAE@XZ called in 32-bit code (0x7b83aed2).
This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109
Thanks Bruno,
The problem seems to have been around for a very long time. Is it proving difficult to track down or something?
I don't know, maybe someone else can answer that. What I know is that Piotr Caban is the one behind most of msvcp* bug resolutions.
Bruno
-
Bruno Jesus -
John Emmas -
Matijn Woudt -
Michael Stefaniuc