Web Browser Libraries incompatible with Win 7 x64?

So I've been re-setting up my development enviornment at the same time I've been working on a new project. I've got one in Win 7 x86 and one in Win 7 x64 (don't ask why). But I started working on the project in the x86 environment and the web browser plugins (both Agraham and Cableguy's) seem to work.

However, I've just moved my project into the x64 environment and now I'm getting an error description 'Request Failed' when it goes to hit the line where the 'New1' command is issued. I'm guessing this is an incompatibility with Win 7 x64?

Any chance for a fix?

Also - is there anyway we might see integrated support for another browser? like a way to tunnel a Firefox or Chrome session into b4p? I know other apps have done it (maybe not b4p apps) but I'm wondering if a similar method couldn't be employed.

WebBrowser is a .NET WebBrowser control so it shouldn't care what OS it is running under as long as the .NET Framework is available. I can't imagine what "Request" is "failing" as New1 is pretty trivial and it doesn't make any "Requests"! What are the exact details of the error and how is it being presented?

There's a slight clutching at straws possibility it might be the Data Execution Prevention setting - my boldening - but as the latest OS I have available is Vista 32-bit I have no way of testing.

OptIn
This setting is the default configuration for Windows XP, Vista and 7. In this mode, DEP is only enabled for limited Windows system applications and services. Applications are not forced by the Operating System to opt-in—applications that wish to opt in must explicitly submit a protection request.[11] The only exception however, are 64-bit application and services on Windows Vista x64: 64-bit applications and services that run in this mode are automatically protected in this mode unless they submit an explicit opt-out request.[12][13]

Click to expand...

The WebBrowser is not really a browser but is a .NET Windows Forms control using the underlying HTML parsing COM objects exposed by IE and in this case accessed by COM Interop from the .NET control. For an alternative you would need a specially written .NET Windows Forms control that somehow hosts the alternative browser HTML rendering engine.

Doh. I'm an idiot. I took another shortcut which caused the problem. When I built the x64 VM - I moved the files into a shared location.

network location = bad

That appears to be what was causing this error.