https://bugs.winehq.org/show_bug.cgi?id=45212
Bug ID: 45212 Summary: Getting IPicture errors - not implemented, cannot connect Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs@winehq.org Reporter: gcos7@yahoo.com Distribution: ---
32-bit wine prefix. Program is called IFS. Program needs jet and vbrun6 so I installed those with winetricks. Program had error. Trie installing ole.dll with winetricks but no difference. I have downloaded various versions of oleaut32.dll as I was told in the wine linux forum to do so. None made any difference. Online searches indicated sometimes installing dcom98 fixed the problem. I have downloaded 3 diferent version of dcom98 but none will install saying I am not running the correct version of Windows. I even recreated the wine prefix as Windows 98 but it still would not install dcom98.
The developer of the program responded to my query and said they have the exact same problem with wine on any operating system and the only way to get it working is via a full blown Windows XP vm.
The program aborts and the tail of the log file shows:
[code]0009:fixme:variant:VarDateFromUdateEx unsupported flags: 4 0009:fixme:variant:VarDateFromUdateEx unsupported flags: 4 0009:fixme:olepicture:OleLoadPictureEx (0x147c824,774,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32eb10), partially implemented. 0009:fixme:olepicture:OleLoadPictureEx (0x1494204,774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32e28c), partially implemented. 0009:fixme:olepicture:OleLoadPictureEx (0x1494204,140233,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32e25c), partially implemented. 0009:fixme:olepicture:OLEPictureImpl_get_hPal unimplemented for type 3. Returning 0 palette. 0009:fixme:ole:NdrCorrelationInitialize (0x32c32c, 0x32c4bc, 1024, 0x0): semi-stub
0009:fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4ed2-6699-11cf-b70c-00aa0060d393} 0009:fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4f92-6699-11cf-b70c-00aa0060d393}[/code]
The problem seems to be in the way wine handles calls to the IPicture functions. I know the IPicture functions are supposed to be contained in oleaut32.dll, but no version works. I have searched the net and found this same error for various games and apps.
Since oleaut32.dll contains the functions, there must be something in the way wine handles calls or something to it. The log would indicate that some of the olepicture calls are only partially defined. See:
[code]0009:fixme:olepicture:OleLoadPictureEx (0x147c824,774,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32eb10), partially implemented. 0009:fixme:olepicture:OleLoadPictureEx (0x1494204,774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32e28c), partially implemented. 0009:fixme:olepicture:OleLoadPictureEx (0x1494204,140233,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32e25c), partially implemented. 0009:fixme:olepicture:OLEPictureImpl_get_hPal unimplemented for type 3. Returning 0 palette. 0009:fixme:ole:NdrCorrelationInitialize (0x32c32c, 0x32c4bc, 1024, 0x0): semi-stub[/code]
In my programming past a stub was either no code or only part of the code and the code stub was never completed.
Just me, but I think those need to complete successfully or the OLDPictureImpl_FindConnectionPoint fails:
[code]0009:fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4ed2-6699-11cf-b70c-00aa0060d393} 0009:fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4f92-6699-11cf-b70c-00aa0060d393}[/code]
This seems to be an error across multiple applications and apparently across several releases of wine. Since it kicks out those errors with any version of oleaut32.dll I feel the problem must reside somewhere in wine.
I am very new to wine and very new to filing a bug. I hope I have provided the information needed. Any help on this would be greatly appreciated.
David Eaton
gcos7@yahoo.com
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #1 from Dave gcos7@yahoo.com --- I did some more research and found that the OLEPictureImpl_get_hpal with a type of 3 indicates:
https://msdn.microsoft.com/en-us/librar ... 69(v=vs.85).aspx.
This goes along with the error I think is the root of the problem: the ipicture set hpal fails as shown in the log. This returns a palette of zero which is associated with the picture. I assume that the connection fails because no palette was assigned. According to the log the ipicture set hapl is " unimplemented for type 3". This would indicate to me that wine is missing the code to handle the ipicture set hpal with a type of 3. Where is this code?
If my research is correct, this is what is not implemented: PICTYPE_ICON 3 The picture type is an icon. When this value occurs in the PICTDESC structure, it means that the icon field of that structure contains the relevant initialization parameters.
When the ipciture set hpal fails for this type (icon) then the return value is null. No wonder the connect fails - null values.
Top
https://bugs.winehq.org/show_bug.cgi?id=45212
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #2 from Dave gcos7@yahoo.com --- Created attachment 61430 --> https://bugs.winehq.org/attachment.cgi?id=61430 log file for the error
https://bugs.winehq.org/show_bug.cgi?id=45212
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download CC| |dark.shadow4@web.de Version|unspecified |3.8 Status|UNCONFIRMED |NEW URL| |https://pardee.du.edu/downl | |oad-ifsv731 Ever confirmed|0 |1
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Confirming.
Don't know which wine version the OP used, so setting version to 3.8.
Problem disappears after using native oleaut32.dll.
Free download is available, but it needs registration and "winetricks -q jet40". (installation requires a few gigabytes space)
Might look into it when I have time during the weekend.
Forum discussions: https://forum.winehq.org/viewtopic.php?f=8&t=30629 https://forum.winehq.org/viewtopic.php?f=8&t=30613
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #4 from Dave gcos7@yahoo.com --- I did download the oldaut32.dll files in various releases but no go. After seeing the comment on registering the dll I know this is something I didn't do. I tried setting the wine prefix as needed and then "regsrv32 oleaut32.dll" but it comes back saying regsrv32 not found. I assume this is me as a novice at all of this not knowing how to do it ;)
I will try the wine 3.8 as I don't think that's what I have, and figure out how to register the dll. I'll post back the results.
Thanks
https://bugs.winehq.org/show_bug.cgi?id=45212
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- (In reply to Dave from comment #4)
I did download the oldaut32.dll files in various releases but no go. After seeing the comment on registering the dll I know this is something I didn't do. I tried setting the wine prefix as needed and then "regsrv32 oleaut32.dll" but it comes back saying regsrv32 not found. I assume this is me as a novice at all of this not knowing how to do it ;)
You just misspelled it—you want to execute `wine regsvr32 oleaut32.dll`.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #6 from Dave gcos7@yahoo.com --- Thanks for the heads-up on the spelling!
I just did the following so I was running "clean".
- deleted old wine prefix
- created new wine prefix via:
WINEARCH-win32 WINEPREFIX-/home/me/WINE-PREFIEX/IFs winecfg
- ran winetricks on the prefix and added the 2 required dll's:
jet40 vbrun6
- downloaded the newest oleaut32.dll i could find on the dll files web site
- unpacked and copied the oleaut32.dll file to the prefix windows/system32
- ran "regscr32 oleaut32.dll" and it showed it registered it
- tried running the setup for the program on the wineprefix, but now I get many messages, all the same and then the process aborts. Since all the messages are the same I'm just showing the last message and then the stack overflow message:
wine: Call from 0x7bc51ed9 to unimplemented function api-ms-win-crt-private-l1-1-0.dll._o__seh_filter_dll, aborting 002e:err:seh:setup_exception_record stack overflow 1280 bytes in thread 002e eip f74570e2 esp 00230e30 stack 0x230000-0x231000-0x330000
Should I try to find an older version of oleaut32.dll or did I do something dumb again?
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #7 from Dave gcos7@yahoo.com --- Created attachment 61436 --> https://bugs.winehq.org/attachment.cgi?id=61436 screenshot of IFsGUIprj.ocx missing error
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #8 from Dave gcos7@yahoo.com --- Created attachment 61437 --> https://bugs.winehq.org/attachment.cgi?id=61437 log file for IFsGUIprj.ocx error
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #9 from Dave gcos7@yahoo.com --- Recreated everything - left out vbrun6 and the program still starts. Had an error so I used winetricks to install vbrun6. No difference - still got an error. I have added an attachment of the screen shot and the new log file. It almost looks to me like it is somehow (if possbile) creating a ocx on the fly and it fails. I searched for the ocx file - IFsGUIprj.ocx - on the prefix and it isn't found. If it is one of it's dependencies as the screen shot might imply I have no idea what. I will email the developer again and see if they can give me something to go on. It at least appears that perhaps the newer oleaut32.dll file, after registering, got around the initial problem.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #10 from Dave gcos7@yahoo.com --- Never mind the IFsGUIprj.ocx. buried down in the 900+ pages of the readme for the application was a very small blurb that said if you got that error to just uninstall the application and reinstall it again. So I did. Back to the original error. How is that happening with the new oleaut32.dll installed, registered and the override? Seems like perhaps the override isn't taking or in someway something built in to wine is interfering. Back to the drawing board on this one.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #11 from Dave gcos7@yahoo.com --- I do have an additional question on this:
Where is OLEPicture defined in wine? Is this separate from oleaut32.dll?
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #12 from Fabian Maurer dark.shadow4@web.de --- Don't just download an DLLs from somewhere on the internet, that's dangerous. Take the win7 or winxp version of the dll, create a win32 wineprefix and copy it into system32. Then add a dll-override. Make sure you take the 32bit dll, btw.
Where is OLEPicture defined in wine? Is this separate from oleaut32.dll?
No... It's right there, in oleaut32/olepicture.c. You still seem to have a misconception on how COM works, and since I can't that quickly explain here, please look it up. Basically, there is the interfaces and the implementation. You only need to know IPicture and know how to get an implementation, but how the implementation does it you don't care. And wine does have its own implementation, obviously.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #13 from Dave gcos7@yahoo.com --- Nope - don't know anything about it and never claimed I did. It just seems to me that SOMETHING in wine is intercepting this even with the replacement dll. Why? Because the developer says it runs fine in Windows XP on up. It obviously doesn't work in wine. So again it comes back to the message about the call to get the pallette - which I do know actually contains all kinds of information about the image - fails on type 3 not being implemented. This causes the connection error since nothing is returned about the image - it returns a null pointer.
I don't have access to a Windows Xp, Windows 7 or Windows 8 installation media to try to extract the dll from. Obviously Windwos 10, and perhaps earlier, uses their own mini-xp environment to run XP programs.
I downloaded the dll from ddl-files.com as that was where I was told a reliable image could be found. I am aware of the inherit dangers in downloadeing from unknown sources, but in this case I'm only trying to help someone else. I can remove everything wine when this is over.
I'm just looking for a way to solve this. I am not alone in this problem - it's both in the wine forums, ubuntu forums and on the net about people having this error about the connection - which I would bet is prefixed by the type 3 not implemented and thus null pointer error. A lot of these are games, some are other applications.
I would REALLY hate to do it, because I've seen the source and all the pieces that have to be found and included to build wine, bhat in desperation one could always load in the sources for wine and run a search on each one looking for OLEPicture - that onto itself might provide some information. But what about the developers of the wine dll? Seems to me they should be able to trace the error back.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #14 from Fabian Maurer dark.shadow4@web.de ---
It just seems to me that SOMETHING in wine is intercepting this even with the replacement dll
It should work when configured properly. It works for me, maybe we could find more people to test that - there seems to be something we do different.
So again it comes back to the message about the call to get the pallette - which I do know actually contains all kinds of information about the image - fails on type 3 not being implemented. This causes the connection error since nothing is returned about the image - it returns a null pointer.
Sounds likely, but someone needs to add that feature. As noted, I'm going to take a look at it when I have time, but it'll take a while.
I downloaded the dll from ddl-files.com as that was where I was told a reliable image could be found. I am aware of the inherit dangers in downloadeing from unknown sources, but in this case I'm only trying to help someone else. I can remove everything wine when this is over.
Still a danger, just pointing that out. Did you make sure it is 32bit and tried different versions? No idea what versions they uploaded there.
I am not alone in this problem - it's both in the wine forums, ubuntu forums and on the net about people having this error about the connection
I don't blame you, but I'm afraid there's not much more you could do unless you want to fix it yourself. We already have a pretty detailed error case thanks to you.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #15 from Dave gcos7@yahoo.com --- (In reply to Fabian Maurer from comment #14)
It just seems to me that SOMETHING in wine is intercepting this even with the replacement dll
It should work when configured properly. It works for me, maybe we could find more people to test that - there seems to be something we do different.
Does that mean you have IFS installed, get to the opening screen with the world map on it, click "Load and Continue" and it actually keeps going? If so, I'd really like to figure that out.
If it's calls to IPicture_get_hpa (I don't remember the exact call name) you have working with a pallette type of 3 I'd really like to figure that out too.
So again it comes back to the message about the call to get the pallette - which I do know actually contains all kinds of information about the image - fails on type 3 not being implemented. This causes the connection error since nothing is returned about the image - it returns a null pointer.
Sounds likely, but someone needs to add that feature. As noted, I'm going to take a look at it when I have time, but it'll take a while.
Thanks for the great help!! I wish I could do something to help out. From the early 1970's through mid-1996 I was a systems programmer on mainframes, minis when they came out and then on PC's when they came out. I've been away from it SO long I don't have a clue what I'm doing anymore.
I downloaded the dll from ddl-files.com as that was where I was told a reliable image could be found. I am aware of the inherit dangers in downloadeing from unknown sources, but in this case I'm only trying to help someone else. I can remove everything wine when this is over.
Still a danger, just pointing that out. Did you make sure it is 32bit and tried different versions? No idea what versions they uploaded there.
I am not alone in this problem - it's both in the wine forums, ubuntu forums and on the net about people having this error about the connection
I don't blame you, but I'm afraid there's not much more you could do unless you want to fix it yourself. We already have a pretty detailed error case thanks to you.
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #16 from Dave gcos7@yahoo.com --- I was looking today at the source for wine, and in particular at the oleaut32.dll in the dlls directory. I notice a log of C code in there apparently done by CodeWeavers. Once such piece of code is olepicture.c. In that code, in this function:
/************************************************************************ * OLEPictureImpl_get_hPal */ static HRESULT WINAPI OLEPictureImpl_get_hPal(IPicture *iface, OLE_HANDLE *phandle)
is the handling for the pictype. In this switch statement:
switch (This->desc.picType)
there is no code for pictype of 3 (from what i saw on the net for the description of the ipicture handling, a pictype of 3 means icon):
case PICTYPE_ICON:
As a result of this the pointer to the handle is returned as a null. So, there is nothing for the calls to findconnectionpoint will fail because of the null pointer.
So, not understanding at all how all of this fits into wine, is it save to say these .c files are used at build time for wine? If so, then overriding with oleaut32.dll wouldn't actually do anything would it?
I don't understand at all how run time libraries work (dll for windows, so files for linux?). From my old C experience, which is more than just a LITTLE bit rusty ;) I would have thought the .c files had to be included at compilation time.
Is this of any help or am I just shooting in the wind again? ;)
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #17 from Fabian Maurer dark.shadow4@web.de ---
As a result of this the pointer to the handle is returned as a null. So, there is nothing for the calls to findconnectionpoint will fail because of the null pointer.
Actually, that's not how it works. In face, I doubt the two things are even related. I don't want to go into too much detail here, but the endpoint stuff is for registering a callback to IPicture, so it can notify when it's finished. But the program requests a callback in the form of 33AD4ED2-6699-11CF-B70C-00AA0060D393 (IPictureBoxEvents) which wine doesn't know. It's a VB6 specific interface, and while I have no idea why oleaut32 would accept that, I'm gonna write some tests to check that behavior tomorrow.
So, not understanding at all how all of this fits into wine, is it save to say these .c files are used at build time for wine?
Sure, sources are compiled into a binary.
If so, then overriding with oleaut32.dll wouldn't actually do anything would it?
Uh, no, I don't see how this would follow. It's replacing the wine binary with the windows binary, sources don't matter for that.
I don't understand at all how run time libraries work (dll for windows, so files for linux?). From my old C experience, which is more than just a LITTLE bit rusty ;) I would have thought the .c files had to be included at compilation time.
Well, the sources are turned into a binary. But when you replace the binary, it should work.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #18 from Dave gcos7@yahoo.com --- Okay - thanks! I'll to refrain from trying to dig into things I don't know and leave it you experts! :) Thanks much for putting up with my dumb questions - the help is GREATLY appreciated!!
No hurry either. I know how old VB6 is, and I know you don't need to allocate much time into that, but thanks for whatever you can do.
Dave ;)
https://bugs.winehq.org/show_bug.cgi?id=45212
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #19 from Anastasius Focht focht@gmx.net --- Hello folks,
the console output/fixme's are harmless and expected.
I already mentioned it a couple of times, for example in: https://bugs.winehq.org/show_bug.cgi?id=14218#c16
Don't waste your time on that, your problem is elsewhere.
Regards
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #20 from Dave gcos7@yahoo.com --- (In reply to Anastasius Focht from comment #19)
Hello folks,
the console output/fixme's are harmless and expected.
I already mentioned it a couple of times, for example in: https://bugs.winehq.org/show_bug.cgi?id=14218#c16
Don't waste your time on that, your problem is elsewhere.
Regards
I don't mean to disagree with you but the program errors out immediately and shows that error message. The errors aren't just fixme warnings - it errors out. Maybe you mean something different from how I am interpreting it. You could also be WAY over my head on any of this. It definitely fails with the error and automation error message.
If you download and install IFs to a 32-bit wine prefix, add jet40, then run the program you'll first get a screen with a global map on it. When you click on "Load and Continue" you get the error.
As Fabian Maurer mentioned this is a VB6 program. I search again on the net and a lot of what I could find for this error are VB6 programs.
I don't understand any of this at all, but what Fabian says makes sense to me. If someone will just try the program you'll see the error - both on the programs screen and in the log.
https://bugs.winehq.org/show_bug.cgi?id=45212
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Getting IPicture errors - |VB6 program IFs closes with |not implemented, cannot |"Run-time error |connect |'-2147417848 (80010108)': | |Automation error"
--- Comment #21 from Fabian Maurer dark.shadow4@web.de ---
the console output/fixme's are harmless and expected.
Yes, you're right. It calls DispCallFunc, then there is a SIGSEV that is handled, and then DispCallFunc returns the 80010108 that the application shows.
I made a log with "WINEDEBUG=+relay,+ole,+typelib" and native jet40. It's 12MB(1.2GB uncompressed): http://www.mediafire.com/file/s8uig8ajjevxv4d/wine-log-IFs.7z Just grep for 80010108 to find the right lines.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #22 from Dave gcos7@yahoo.com --- Sorry I though otherwise. Seemed like they were related but I guess something in the background is returning an error to the program that really isn't the error?
My complete and total lack of understanding of any of this just keeps getting me frustrated.
Sorry I keep messing up and I promise I won't post anything now.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #23 from Fabian Maurer dark.shadow4@web.de --- My current status is: It calls DispCallFunc with an argument "C:\IFs\RUNFILES\IFS.MDB", it then crashes in dao360 and returns a generic error code. The crash comes because the program tries to write a '\0' into a string "[ESRI Countries]" - but this string happens to be in the .text segment and readonly.
Don't know how right that is, but that's what I found. I guess the string should be a copy, but is not.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #24 from Fabian Maurer dark.shadow4@web.de --- Created attachment 61480 --> https://bugs.winehq.org/attachment.cgi?id=61480 Hack that makes all dll segments writeable
Good news, I found a hack.
Somewhere inside dao360, it tries to load the database - and for that it uses a string "[ESRI Countries]" from inside the .text segment of IFsGUIprj.ocx. It replaces the last character of this string with '\0', and then ']' again multiple times, no idea why though. If you make the memory writeable, the program seems to work just fine.
See the attached hack/patch to test it yourself.
Maybe the .ocx should be loaded as writeable? Or something else is wrong. Will continue to investigate.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #25 from Dave gcos7@yahoo.com --- Is there any way I can use this in some way or this an internal thing?
Thank you!
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #26 from Fabian Maurer dark.shadow4@web.de --- If you can build wine from source, you can use this patch to fix the issue. But keep in mind that it's a dirty hack.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #27 from Dave gcos7@yahoo.com --- I've only built wine once from source as it was recommended for me for an earlier problem. Somehow I managed to not have any sound when I finished. However, for this problem, I may try it again to see if I can make it work. I'll have to look close at where your patch is going so I can be sure I change what needs to be changed.
Thanks for your continued work on this! On a side note, I'm guessing the .text not being writable is an internal thing? My limited experience with VB has shown that picture .text properties, etc., are writable. As for why the program is writing a null - I can see that as end of a string - but many times along with the bracket is pretty weird. The contact I've had from the developer is more the person who implements the program rather than knows the source. I may check to see if there is a way to get the source so I can try to see what they are doing. Of course I fully expect what you are talking about is something completely different that I don't know anything about.
I'll try the hack. It might take me quite a while as I have a very slow laptop. I did try configure but it said I'm trying to build wine for a 32-bit environment when I have a 64-bit system. I'm sure I'm doing something stupid and will figure out what I'm doing on that.
Thanks again!
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #28 from Dave gcos7@yahoo.com --- I didn't have any luck. The configure gave me an error message for a missing item that I just don't seem to be able to locate if.
I'll leave it up to you guys who know what you are doing.
https://bugs.winehq.org/show_bug.cgi?id=45212
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Component|oleaut32 |-unknown Status|NEW |RESOLVED
--- Comment #29 from Fabian Maurer dark.shadow4@web.de --- Interesting change of events, the program also fails to run on Windows XP, same issue as in Wine. Same crash at exactly the same position. It works with Windows7 though. Couldn't test IFs on win98 (what the jet40 installer targets) because it won't run there.
The reason it crashes is that the dao360.dll installed from winetricks jet40 is too old, it works after copying the dao360 from win7 over. The native oleaut32 was a red herring I'm afraid.
I'll resolve this as invalid.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #30 from Fabian Maurer dark.shadow4@web.de --- FWIW I reported it to winetricks in hope we can get a newer dao360: https://github.com/Winetricks/winetricks/issues/1001
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #31 from Dave gcos7@yahoo.com --- Ok, so I don't need the hack patch, just a newer version of dao360? I'll give that a try and see what happens.
THANKS for all the time and effort you have put in to this!!!!!!!!
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #32 from Fabian Maurer dark.shadow4@web.de --- Yeah, get a 32bit dao360.dll from win7 or so (mine is version 03.60.9756.0), and put it into drive_c/Program Files/Common Files/Microsoft Shared/DAO/ - overwriting the already existing dll created by "winetricks -q jet40" Certain dll download sites have them too, but as I said, that has an inherent risk.
If you don't mind, could you report back if it solved the problem for you, too?
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #33 from Dave gcos7@yahoo.com --- I sure will!! If it goes ok I'll also pass it along to the developer so they can tell me how to test the program as I know nothing about it and was trying to get this working for someone else on the forum,
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #34 from Dave gcos7@yahoo.com --- YES!! Got past that error and got to a map screen! Beyond that I have no idea what to do with the program. I'll pass this along to the developer and see if they can do more testing and let me know if there are more errors.
THANK YOU SO MUCH!!!!!!!!
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #35 from Fabian Maurer dark.shadow4@web.de --- You're welcome, that's what I'm here for :)
I also reported it to the OP in the forum thread.
Not sure if the developer is interest in running the program on wine though, but letting them know it works won't harm, I guess.
https://bugs.winehq.org/show_bug.cgi?id=45212
--- Comment #36 from Dave gcos7@yahoo.com --- The developer/installer person said they indeed wanted this working in wine but had never gotten to work, so I think they'll be very excited about this. I'm betting there are probably other missing pieces but until they actually try it out there is no way to know. I think they must have people who want this installed but are using linux so they never got it to work.
I have no clue how you traced everything back! many years ago now i could have done that on mainframes or minis but i have long forgotten that as well. Sometimes I wish I could get back into the type of tech support you are doing, then the rest of brain says I'm way too old for it now :) :)
Thank you SO much again!
https://bugs.winehq.org/show_bug.cgi?id=45212
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |nerv@dawncrow.de
--- Comment #37 from André H. nerv@dawncrow.de --- closing invalid
-
wine-bugs＠winehq.org