Back to Questions
3.1k
views3
comments
64-bit (AnyCPU) FSI.exe
f#

fsi.exe appears

to be compiled to run as a 32 bit application under Windows. Using

corflags, it can be edited to run however the OS decides to start it,

and under Vista 64, that's in 64 bit mode. It even continues to work

properly as a Visual Studio (2005) plugin, executing in 64 bit mode

though VS itself is a 32 bit applicatin. F# code in general works just

fine on 64 bit systems, and it would make sense for FSI.EXE

to run that way, too, by default. In my case, I cannot play with code

which talks to Oracle databases because the drivers under the covers

are 64 bits and cannot be loaded into 32 bit processes.

When fsc creates executables, it does not mark them as 32-bit only, so I am curious why fsi would show up this way. Hopefully only an oversight?

.

If this workaround is still valid, how exactly do I do that? After I execute in cmd the following
C:\Program Files\Microsoft.NET\SDK\v2.0 64bit\Bin>corflags "C:\Program Files (x8
6)\FSharp-1.9.6.2\bin\fsi.exe" /Force /32BIT-
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.

corflags : warning CF011 : The specified file is strong name signed. Using /For
ce will invalidate the signature of this image and will require the assembly to
be resigned.

And open Visual Studio 2008 (on Vista64) and attempt at FSharp Interactive fsi.exe always crashes. What do I do wrong? I absolutely have to load native 64-bit dll, and it would be nice to do it interactively.
Igor

By on 12/22/2008 8:44 AM ()

I find the same problem under 1.9.6.2. Is there a chance of removing the unmanged dependency, or loading it dynamically? using fsi in 64 bit mode is a big deal. thanks!

By on 3/14/2009 4:19 PM ()

Thanks for reporting this.

FSI.EXE uses a small amount of unmanaged code (absilsuppc.dll) which we only ship as a Win32 binary. Hence it runs as a Win32 process.

In the past some people have just "fiddled with the flags" on the binary (using some simple Win32 binary manipulation tool) and changed it to a 64-bit binary without problem. This was because they wanted to load > 3GB of data. By all means feel free to try the same thing

Kind regards & thanks again

don

By on 7/11/2008 6:57 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper