This work is licensed under a Creative Commons License.
First thing for me: I'm running RedHat Fedora Core 2, and it does not come with a standard package of Wine, so I have to go looking to download one. I poke around at winehq.org and manage to find something in SRPM format (in particular I'm using the file wine-20041019-1fc2winehq.src.rpm) which seems to be the go. So this thing goes through rpmbuild and looks OK, it installs OK and I even install the wine-devel package just in case. So far so good, takes bloody ages to compile but who cares about that... long as it works huh?
I'll make a side note here that the MPLAB running on WIN98 always worked fine EXCEPT an annoying pop-up that would keep telling me to upgrade the OS because the software was not compatible with WIN98. That sort of shits me, but the pop-up was only a harmless nag so I could get some work done.
OK, so I unzip the MPLAB660.zip to get /tmp/MPLABV~1.EXE and then use wine to run that program. Sure enough, it goes through the installer then stops dead and says that you need to have "Internet Explorer 5". The installer steadfastly refuses to go past this point. This shits me more than a little bit. Fair enough to make it a warning or something but even on MS-Windows there are plenty of users who don't want IE because they don't trust it. MPLAB only uses IE to display a few of the help pages and it might occur to the boneheads at Microchip that if they write their help in HTML properly then people can read it on any browser. I've got 4 different browsers to use on Linux so the last thing I need is to be told that I have to install yet another one.
Warning: the specified Windows directory L"c:\\windows" is not accessible. Warning: the specified System directory L"c:\\windows\\system" is not accessible.
Now, the wine documentation tells me that the wineinstall program will set these directories up for me, but sure enough there is no wineinstall program in the wine-20041019-1fc2winehq package -- how predictable. Well I finally find the wineinstall program by digging through the source code (which is why SRPM is such a handy format) and to my surprise the wineinstall program actually does recompiling, installation of binaries and a bunch of other stuff. Stranger still it won't run as root, but for about 90% of the stuff it does it needs to be root so it has "su" dotted all through it along with various messages that say you need to be root in order to run this... Sheesh, once people start to understand MS-Windows it seems to mess with their good sense and they can't write unix code properly anymore. From a security point of view, since wineserver runs at bootup, if the wine distribution is not trustworthy then that program is a security hole right there. Since the same wineinstall script asks for the root password (in several places) it is actually LESS secure than just running it as root to begin with (because it might snarf the plaintext password) and you are trusting it one way or another.
Let's get beyond these trifling problems and on to what matters -- the ACTUAL program that you need to create the key directories is NOT wineinstall at all (forget what the documentation says), the program you need is wineprefixcreate which IS available in the Fedora package (just no documentation is available). The pain in the arse is that wineprefixcreate also screws around with the dosdevices. Somehow, once I had run wineprefix create just once, now I got different results running wine because it would not create a link to the CDROM device or other devices and it would no longer use /usr/share/wine/wine-c but would create C drive under ~/.wine/c_drive instead. Something strangely inconsistent is happening in the setup here. How did it create the long list of links before? Why doesn't it happen now? Why does this behind-the-scenes-weirdness seem so typical of anything with "Windows" in its name?
Screw it... now I have a C-drive skeleton and I can build the links myself.
That gets me past the "cannot change to destination folder" error and now I can use the "wcmd" shell so switch into the D: (which I have linked to /mnt/cdrom) and then run ie.exe to get into the installer. Amazingly, it goes and unpacks the CAB files. I get this scrolling up millions of times and it hangs at 63% complete:
fixme:thunk:CommonUnimpStub generic stub: ? fixme:thunk:CommonUnimpStub generic stub: ? fixme:thunk:CommonUnimpStub generic stub: ? fixme:thunk:CommonUnimpStub generic stub: ?
I leave it run for a while and browse the web, it has installed some stuff into /usr/share/wine/wine-c so maybe it will finish...
Fifteen minutes later it is still 63% installed and no change in the filesystem can be observed. Seems to be in an endless loop. I press the Cancel button and it warns me that setup is not complete (ya don't say) so I keep telling it to cancel and I get:
Please wait while Setup is canceling... This may take several minutes. Warning: Do not restart your computer. Restarting your computer now could harm your system.
And off it goes into nowhere land again; brilliant! So a ctrl-C seems appropriate and I try the installer again, who knows what might happen, now it detects that an earlier setup attempt has failed and I figure I might as well see if the resume option works. Worth a try huh? Well I get the same fixme messages as above and it runs mighty slow... gets to 62%, hangs, try to cancel, won't cancel, same as before.
I notice that the /etc/wine/config has temp set to e: and I didn't have a link to e: in my dosdevices so I link e: to /tmp and try again... totally in the dark here because the error message is so meaningless. Behaviour is same again. Drat.
Much searching later, found WINE bug number 2107 which explains this problem but doesn't explain how to fix it (typical).
Much more searching, found some mailing list comments that suggest the solution is related to forcing some libraries to become builtin rather than native (because the installer tries to use its own native libraries which themselves are incomplete). So I try:
export WINEDLLOVERRIDES="*advapi32=builtin"
Hey, different things are happening now... but still failure. It doesn't endless loop anymore but it does fail to install with a very generic error message.
But wait! I didn't use the advapi32=builtin this time, so I do the export from above and try the installer again, fortunately it lets me resume and doesn't download all the junk again but sadly it comes to a grinding crash and lands in the debugger:
err:setupapi:SetupDefaultQueueCallbackA delete error 2 "c:\\windows\\inf\\ie5dom.inf" wine: Unhandled exception (thread 001c), starting debugger... WineDbg starting on pid 0x1b Unhandled exception: page fault on read access to 0x47d204dc in 32-bit code (0x500b354f). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:500b354f ESP:0023fd00 EBP:0023fd54 EFLAGS:00210202( - 00 - -RI1) EAX:00530000 EBX:00da92c4 ECX:00000040 EDX:477f04d8 ESI:47d204dc EDI:500c7ab8 Stack dump: 0x0023fd00: 00000001 00000001 00da92c4 00000044 0x0023fd10: 00000000 00000000 00000000 00000000 0x0023fd20: 00000000 00000000 00000000 00000000 0x0023fd30: 00000000 00000000 00000000 00000000 0x0023fd40: 477f04d8 00000008 0000000c 00000010 0x0023fd50: 00530000 0023fd74 500b20e3 500b218b Backtrace: =>1 0x500b354f (0x0023fd54) 2 0x500b20e3 (0x0023fd74) 3 0x00d78f2afixme:dbghelp:elf_load_debug_info_from_file Unsupported Dwarf2 information for ntdllcall_dll_entry_point+0x12 in ntdll (0x0023fd8c) 4 0x00d7a3df MODULE_InitDLL+0x10f in ntdll (0x0023fe08) 5 0x00d7a5ae process_attach+0x9e in ntdll (0x0023fe38) 6 0x00d7a66a process_attach+0x15a in ntdll (0x0023fe68) 7 0x00d7ce8c LdrInitializeThunk+0x22c in ntdll (0x0023ff20) 8 0x0061040bfixme:dbghelp:elf_load_debug_info_from_file Unsupported Dwarf2 information for kernel32 start_process+0xbb in kernel32 (0x0023fff4) 9 0x002fff01fixme:dbghelp:elf_load_debug_info_from_file Unsupported Dwarf2 information for libwine.so.1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x500b354f: repe movsl (%esi),%es:(%edi)
Now one thing I notice about the wine debugger: it's not very good at giving you source code reference, even for the files that you do have source code for! Weirdly, if I use something like:
objdump -S /usr/lib/wine/ntdll.dll.so | less
Then I can see source code, so the debugging info must be available (note that I have the rpmbuild tree still in /usr/src/redhat/BUILD so that source code is on the system). Somehow that code is not available from winedbg, which makes it difficult to understand what is going on. I do notice that the "call_dll_entry_point+0x12 in ntdll" is a bit of special inline assembler and the stack points to just after a "call" instruction (which is what you would expect for a stack trace) and I also notice that the address 0x500b20e3 seems a bit wild compared to the other addresses in there. Also the crash address 0x500b354f turns up more stuff on google (so I'm not the only one who has seen this crash). I might wait for a newer version to turn up on the download directory.
You can find various version ID numbers here
It gave me messages about various device drivers and USB in particular but I don't want any USB stuff -- I just want MPLAB *wimper*. How hard do they have to make it? Anyhow, I think I got a full install.
One problem, it doesn't run... I get a pop-up saying "no error message is available".
The closest I got to understanding this is this message which is two years old but which says that MPLAB only works if you copy the "comctl comdlg etc" dlls files over from a working MS-Windows. I haven't tried this, don't really know what to copy.
Using WINEDEBUG=+ole and running in the debugger, I get:
trace:ole:__CLSIDFromStringA {E4BCAC13-7F99-4908-9A8E-74E3BF24B6E1} -> 0x89fa08
trace:ole:__CLSIDFromStringA {EBF2320A-2502-11D3-8BD1-00600893B1B6} -> 0x89fa08
trace:ole:__CLSIDFromStringA {EE0B9CA0-A81E-11D3-9BD1-0080C7150A74} -> 0x89fa08
trace:ole:__CLSIDFromStringA {EED36461-9EA5-11D3-9BD1-0080C7150A74} -> 0x89fa08
trace:ole:__CLSIDFromStringA {F17E8672-C3B4-11D1-870B-00600893B1BD} -> 0x89fa08
trace:ole:__CLSIDFromStringA {FEA4300C-7959-4147-B26A-2377B9E7A91D} -> 0x89fa08
trace:ole:COMCAT_CLSID_IEnumGUID_Release
trace:ole:COMCAT_ICatInformation_Release
trace:ole:COMCAT_IUnknown_Release
trace:ole:WINE_StringFromCLSID 0x432060->{8DB953D6-99C8-4677-B028-89DD92AD4B18}
trace:ole:OleInitialize ((nil))
trace:ole:CoInitializeEx ((nil), 2)
fixme:ole:CoRegisterMessageFilter stub
trace:ole:WINE_StringFromCLSID 0x7fdd4b2c->{8DB953D6-99C8-4677-B028-89DD92AD4B18}
trace:ole:CoGetClassObject
CLSID: {8db953d6-99c8-4677-b028-89dd92ad4b18},
IID: {00000001-0000-0000-c000-000000000046}
warn:ole:CoGetClassObject class {8DB953D6-99C8-4677-B028-89DD92AD4B18} not registered inproc
trace:ole:WINE_StringFromCLSID 0x432060->{8DB953D6-99C8-4677-B028-89DD92AD4B18}
First chance exception: 0xe06d7363 in 32-bit code (0x002a4953).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:002a4953 ESP:0089f848 EBP:0089f8a4 EFLAGS:00000202( - 00 - - I1)
EAX:0089f848 EBX:003514c0 ECX:00000000 EDX:00000008
ESI:0089f8e4 EDI:0089f868
Stack dump:
0x0089f848: e06d7363 00000001 00000000 002a48c0
0x0089f858: 00000003 19930520 0089f90c 0043a0b8
0x0089f868: 009af321 ffffffff ffffffff 0089f880
0x0089f878: 7c34214f 7c38b190 0089f8bc 7c3478e7
0x0089f888: 00000004 7c3416b8 7c3416e9 7fdd4ad0
0x0089f898: 00432060 7c380edc 0089f8e4 0089f8e4
Backtrace:
=>1 0x002a4953 RaiseException+0x93 in kernel32 (0x0089f8a4)
2 0x7c359aederr:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 53445352 in module msvcr71
??0__non_rtti_object@@QAE@ABV0@@Z+0xf87 in msvcr71 (0x0089f8e4)
3 0x00408124 (0x0089f9d4)
4 0x00407315 (0x0089fab4)
5 0x0040e240 (0x7c342151)
6 0xe87c37a3 (0xa868186a)
7 0x00000000 (0x00000000)
0x002a4953 RaiseException+0x93 in kernel32: subl $4,%esp
Running the regsrv32 program on every dll file in the "dlls" directory seemed to help, I got further but got more errors, now regarding languages stuff. Then I get a glimpse of a working MPLAB screen and it crashes out to the debugger once more:
fixme:ole:CoRegisterMessageFilter stub
fixme:font:WineEngCreateFontInstance Untranslated charset 56
fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name "EST" to an entry in TZ_INFO
fixme:ntdll:TIME_GetTZAsStr Please add appropriate entry to TZ_INFO and submit as patch to wine-patches
fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name "EST" to an entry in TZ_INFO
fixme:ntdll:TIME_GetTZAsStr Please add appropriate entry to TZ_INFO and submit as patch to wine-patches
fixme:ole:CoCreateInstance no classfactory created for CLSID {12421eb7-4f43-a0d4-830a-f8d0eea8e231}, hres is 0x80040150
fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name "EST" to an entry in TZ_INFO
fixme:ntdll:TIME_GetTZAsStr Please add appropriate entry to TZ_INFO and submit as patch to wine-patches
fixme:ole:CoCreateInstance no classfactory created for CLSID {489322ed-251d-4d29-bba5-5bb74dafd28a}, hres is 0x80040150
fixme:ole:CoCreateInstance no classfactory created for CLSID {78ccb5cb-36a1-4440-b5f4-5360997702bf}, hres is 0x80040150
fixme:ole:CoCreateInstance no classfactory created for CLSID {7c9a940c-b3d1-4bb2-8005-3448195cab38}, hres is 0x80040150
fixme:ole:CoCreateInstance no classfactory created for CLSID {cfcd335a-dd99-4207-ab54-ff6e7c5a60bb}, hres is 0x80040150
fixme:ole:CoCreateInstance no classfactory created for CLSID {eb849b23-1bc8-38c9-253d-7b4d14a25597}, hres is 0x80040150
wine: Unhandled exception (thread 000d), starting debugger...
For each of the "CoCreateInstance no classfactory created for CLSID" messages, I'm getting a dialog box with "Failed to initialize legacy language suite with CLSID" and a matching hexadecimal number. These CLSID's are such a great idea... a totally arbitrary number that bears no resemblance to the filename that it represents so you basically have no chance of figuring out which file you are going to need. All I could think of was dumping the entire registry to text and searching. I found this:
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}]
@="TLCC8E.INI"
"DoNotLoad"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\Tools]
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\Tools\{d37d755c-034b-4896-83bb-8c1f74dda1f6}]
@="MPASM.MTC"
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\Tools\{d37d755c-034b-4896-83bb-8c1f74dda1f6}\{58963c7e-b41f-4859-8c9a-c4f34364f0b4}]
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\Tools\{eae4e6f3-501b-48f3-aaa3-4ee51a9204f5}]
@="MPLINK.MTC"
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\Tools\{eae4e6f3-501b-48f3-aaa3-4ee51a9204f5}\{42a20e31-236e-47fb-851a-fd464985044b}]
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\Tools\{f2efcac9-2d17-064e-7546-b16df9964ff6}]
@="CC8E.MTC"
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\Tools\{f2efcac9-2d17-064e-7546-b16df9964ff6}\{c1e40f78-5da3-1a91-7292-022a0372504d}]
[HKEY_LOCAL_MACHINE\Software\Microchip\MPLAB IDE\Legacy Language Suites\{12421eb7-4f43-a0d4-830a-f8d0eea8e231}\{a966b167-e301-64bf-e5fd-721e8cdf3fae}]
Well there is the magic CLSID number but does it mean anything to me? Not really... It just seems to link to more meaningless magic numbers. This is really the work of an evil genius, layers of total crap piled on more crap.
More head scratching and debugging got me to looking at the xrender trace which shows something also bad:
trace:xrender:LookupEntry found font in cache 0 trace:xrender:X11DRV_XRender_SelectFont h=-11 w=322761716 weight=100 it=23 charset=89 name=L"MS Sans Serif" trace:xrender:dec_ref_cache dec'ing entry 0 to 9 trace:xrender:LookupEntry 0 trace:xrender:LookupEntry 7 trace:xrender:LookupEntry 1 trace:xrender:LookupEntry 2 trace:xrender:LookupEntry 6 trace:xrender:LookupEntry 3 trace:xrender:LookupEntry found font in cache 3 trace:xrender:X11DRV_XRender_ExtTextOut 0x814, 0, 0, 00000002, 0x133cf8cc, L"", 0, (nil)) trace:xrender:X11DRV_XRender_ExtTextOut rect: 2,0 - 436207632,22 trace:xrender:X11DRV_XRender_ExtTextOut align = 0 bkmode = 2 mapmode = 1 trace:xrender:X11DRV_XRender_ExtTextOut 0x814, 0, 0, 00000002, 0x133cf8bc, L"", 0, (nil)) trace:xrender:X11DRV_XRender_ExtTextOut rect: 436207630,0 - 436207632,3 trace:xrender:X11DRV_XRender_ExtTextOut align = 0 bkmode = 2 mapmode = 1 trace:xrender:X11DRV_XRender_ExtTextOut 0x814, 0, 0, 00000002, 0x133cf8bc, L"", 0, (nil)) trace:xrender:X11DRV_XRender_ExtTextOut rect: 0,0 - 2,3 trace:xrender:X11DRV_XRender_ExtTextOut align = 0 bkmode = 2 mapmode = 1 trace:xrender:X11DRV_XRender_SelectFont h=-11 w=322761716 weight=100 it=23 charset=89 name=L"MS Sans Serif" trace:xrender:dec_ref_cache dec'ing entry 3 to 0 trace:xrender:LookupEntry 3 trace:xrender:LookupEntry found font in cache 3 trace:xrender:X11DRV_XRender_ExtTextOut 0x814, 8, 3, 00000004, 0x133cf814, L"Find in Files"..., 13, (nil)) trace:xrender:X11DRV_XRender_ExtTextOut rect: 8,3 - 436207632,22 trace:xrender:X11DRV_XRender_ExtTextOut align = 0 bkmode = 1 mapmode = 1 trace:xrender:X11DRV_XRender_ExtTextOut real x,y 8,3 trace:xrender:X11DRV_XRender_ExtTextOut allocing pict = a0044b dc = 0x814 drawable = 01200033 trace:xrender:UploadGlyph buflen = -1336644656. Got metrics: 227145x31932 adv=1914,-27363 origin=-227143,31932 wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x102cd3b3). In 32 bit mode. fixme:dbghelp:elf_load_debug_info_from_file Unsupported Dwarf2 information for x11drvRegister dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:102cd3b3 ESP:133cef38 EBP:133cf12c EFLAGS:00010297( - 00 RISAP1C) EAX:00000000 EBX:102e11d4 ECX:102da820 EDX:133cefa0 ESI:00000000 EDI:00000000 Stack dump: 0x133cef38: 00000003 102e353a 102df75b 102dfb30 0x133cef48: b0546bd0 00037749 00007cbc 0000077a 0x133cef58: ffff951d fffc88b9 00007cbc 133cef84 0x133cef68: 00000000 133cefa0 102da820 3d2ee8c3 0x133cef78: 0000774c 133cef9e 133cefd0 00000000 0x133cef88: 133cf100 4da635bc 00000000 b0546bd0 Backtrace: =>1 0x102cd3b3 UploadGlyph+0x6d3 in x11drv (0x133cf12c) 2 0x102ce57e X11DRV_XRender_ExtTextOut+0x86e in x11drv (0x133cf428) 3 0x102b3e05 X11DRV_ExtTextOut+0x85 in x11drv (0x133cf530) 4 0x5e372d44fixme:dbghelp:elf_load_debug_info_from_file Unsupported Dwarf2 information for gdi32 ExtTextOutW+0xb4 in gdi32 (0x133cf56c) 5 0x592e280afixme:dbghelp:elf_load_debug_info_from_file Unsupported Dwarf2 information for user32 DrawTextExW+0x40a in user32 (0x133cf678) 6 0x592e2e1e DrawTextW+0x6e in user32 (0x133cf6c4)
I don't like the looks of that negative buflen... and the metrics look like crap too. I added a chunk of protection code here. Must admit that I have bugger all idea what is going on but as they say, "ya need protection".
--------------------------------------------------------------------------------
*** xrender.c~ 2004-08-12 09:45:34.000000000 +1000
--- xrender.c 2004-11-10 00:27:31.854866664 +1100
***************
*** 595,600 ****
--- 595,606 ----
TRACE("Turning off antialiasing for this monochrome font\n");
}
+ if( buflen > 1000000 ) // sanity checking
+ {
+ FIXME( "ridiculous buflen=%u in UploadGlyph\n", buflen );
+ return FALSE;
+ }
+
if(entry->glyphset == 0 && X11DRV_XRender_Installed) {
switch(entry->aa) {
case AA_Grey:
--------------------------------------------------------------------------------
And the protection made a big difference, so I'm getting closer to the problem.
fixme:xrender:UploadGlyph ridiculous buflen=2958322640 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=1034056920 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=1033667528 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=2958322640 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=1034056920 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=1033667528 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=2958322640 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=1034056920 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=2368979800 in UploadGlyph fixme:xrender:UploadGlyph ridiculous buflen=1033667528 in UploadGlyph
And lots more similar to the above. Doesn't really help me understand what is going on but... it doesn't crash anymore.
So here it is... MPLAB on Linux with zero Microsoft components (think I deleted all the abortive attempts to install IE, gets difficult to be sure when the installer bombs with a half-job and files scattered everywhere, some day I might start from a clean wine install and see if any of these steps are repeatable).
I would rate wine as still pretty green. Given the complexity and instability of MS-Windows itself and given that wine is attempting to emulate every version of MS-Windows from 3.1 through to XP all at once while maintaining Linux and BSD compatibility I doubt that wine will ever be a mainstream tool that "just works" out of the box.
This work is licensed under a Creative Commons License.