On Thursday, 12 December 2013 at 03:17:29 UTC, Malkierian wrote:
> On Tuesday, 10 December 2013 at 03:42:10 UTC, Malkierian wrote:
>> On Tuesday, 10 December 2013 at 02:05:12 UTC, Jeremy DeHaan wrote:
>>> On Monday, 9 December 2013 at 16:49:04 UTC, Malkierian wrote:
>>>> On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan wrote:
>>>>> On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote:
>>>>>> *sigh* No dice.  And I can't get GtkD to work either, because of entry point errors...
>>>>>
>>>>> I've gotten GtkD to work for me, though it has been a while. If I am able to find some time soon I will see if I can do some kind of example for you.
>>>>
>>>> Well, in the mean time, have you ever heard of this error before?
>>>>
>>>> "The procedure entry point gdk_frame_clock_begin_updating could not be located in the dynamic link library libgdk-3-0.dll.
>>>>
>>>> I've also gotten a similar error with some other entry point in libgdk_pixbuf-2.0-0.dll, but then I copied that file from the Gtk 3.6.4 release into my bin folder and it went away.  Copying the the libgdk-3-0.dll from the same release did nothing to fix this error.  This is getting ridiculous.
>>>
>>> I don't know if this is your problem exactly, but the Gtk+ installer on the GtkD website(http://gtkd.org/download.html) is for 3.8.1, so maybe something has been updated since then?
>>>
>>> You could also open an issue on GtkD's github repo(https://github.com/gtkd-developers/GtkD) if you continue to experience problems with it.
>>
>> LOL, that was the version I was replacing with the 3.6.4 stuff XD.  And I already made a post on their forum about it.
>
> So guess what?  I just recently was trying to troubleshoot GtkD, and in the process I removed the bin folders for the 64-bit versions of TortoiseGit and TortioseSVN from my PATH, and when I switch back over to my other source set (the one with the file chooser from here) suddenly the windows generic chooser works fine.  I had to remove those two bin folders from the path because, despite it being a 32-bit application, it was apparently loading (or trying to load) a specific driver from those folders that was messing everything up.
>
> So is this 32/64-bit crossover thing a bug in D, or is it just a phantom random weird thing that was happening with my setup?

Mixing 32 bit code with 64 bit libraries, or vice versa, is (from what I have read) not usually a good thing and is not specific to the D language. If your program found a dll with the same name for one it is looking for I think it just goes for it. I have no idea if Windows can or does try to verify how many bits a library has before it loads it.