I'm working on a simulator that models very complex interactions between many objects, and I mean millions.
I've used XNA because of the useful things that it lets me do easily, especially with the rendering.
My problem is that I'm running into OutOfMemoryExceptions after only a few seconds of simulation. I quickly realized that my program is only running in 32-bit mode, so I only get a few GBs of my somewhat larger amount of RAM.
How can I run an XNA game in 64-bit mode?
XNA used to be 32-bit only. You can try to compile to 64-bit, but then you are going to have issues because there won't be any 64-bit XNA libraries to load up. Everything I have found trying to back this up has been comments reminding viewers to compile as x86.
To compile as x64: Right-Click on your solution and go to Configuration Manager. From there select x64 as your Active Solution platform. You may have to create it and then select all your projects as x64. You could also try building as Any CPU since you are on 64-bit Windows, it should automatically start up in 64-bit mode.
EDIT: I found one of my old VM's that had XNA 4 installed on it. It appears that there is not a way to force it to compile to 64-bit. Even when I try to create a new platform, it will only allow me to select x86.
This does not directly answer the question. I've already upvoted TyCobb's answer.
I've run into the same issue in the past.
Have you considered switching to SlimDX? It's a wrapper around DirectX and allows you to develop .Net applications using DirectX. According to the documentation:
SlimDX sports complete support for both 32 and 64 bit targets.
It might not be as user-friendly as XNA, but I think it could be a good option for you.
Related
I am new to c# . I am developing a C# application under windows 7 64 bit using visual studio 2015 professional. later when the application is ready I expect to install it in 64 bit or in 32 bit machines.
if I design the application under 64 bit I think it will not work under 32 bit, right? my question is: if I design it and then create setup file under 64 bit computer, what should I do later in order for my application to work under 32 bit windows machines?
Please help me. Thank you
if I design the application under 64 bit I think it will not work under 32 bit, right?
No. You can build an "Any CPU" assembly that will work in both. (You can also build a 32-bit assembly that will work in both, but on 64-bit it runs as a 32-bit app, which is rarely what you want).
my question is: if I design it and then create setup file under 64 bit computer, what should I do later in order for my application to work under 32 bit windows machines?
Test it in one. Selecting "Any CPU" is simple, but forgetting to do so is also simple, especially if you add another project for a library (an Any-CPU application with a 64-bit-only library is essentially 64-bit-only). Testing makes this very obvious, very soon.
If it's a managed application, generally it won't matter. The run-time will auto-magicly sort most problems simply by using Any CPU as target.
I've met 2 problems mostly:
developers who hard-code sizeof(int) to 4
managed applications with un-managed dependancies (like openssl libraries) - in this case you will need to have 2 different builds (one for 32 bit and one for 64 bit)
Your QAs should test your application on all target systems (even if by using virtual machines to do so).
Most .NET developers (I can't speak for C++ guys) use 64bit systems simply because we want performance and to use the newest stuff. All new CPUs support 64 bit for quite some time. It's no longer something exotic.
With .net it doesn't matters, just stick to "Any CPU" compilations and you should not have any problem.
Only exception is if you're using external libraries for an specific platform (unmanaged libraries or managed libraries specifically compiled for x64),
In the case of managed libraries you will need to compile twice, one for x86 and other for x64 with the correct libraries, on the unamnaged case you just need to declare the DllImports twice, one for each platform and use at runtime the correct ones.
It's a bit confusing to be honest...
... later when the application is ready I expect to install it in 64
bit or in 32 bit machines.
All 32-bit applications also work on 64-bit, because Intel/AMD made their AMD64 implementation backward compatible. In other words: regardless if you're using unmanaged or managed code, you can always run it on a 64-bit platform.
The other way around that's not the case, so:
if I design the application under 64 bit I think it will not work
under 32 bit, right?
Yes, correct.
Personally I don't bother anymore with x86 because everyone nowadays has a 64-bit capable processor.
It's usually best to compile to 'Any CPU'. The 'x86' and 'x64' targets are only there to enforce a certain platform. In practice everything is always compiler to .NET IL - which is JIT compiled by the runtime to native assembler.
The JIT uses the 'target flag' or the 'prefer 32-bit' (csproj properties) hint to determine which runtime should run the code. If
you have the 'x86' target or
'prefer 32-bit' (default) or
if you don't have a 64-bit system and don't have the 'prefer 32-bit' checked
it will use the x86 JIT compiler (and runtime). Otherwise it will use the x64 JIT compiler (and runtime).
There are some differences and subtleties that you change when you do this (that all have to do with native interop), but when you stick to normal C# code you shouldn't notice them.
Summary: Personally I seem to make it a habit of not being able to fit my application in 2 GB of RAM (I work what they now call 'big data'), so in those cases the best practice is to use the 'Any CPU' target and uncheck the 'prefer 32-bit'. That said, if you don't need the memory, it's probably better to leave it on as a safeguard.
my question is: if I design it and then create
setup file under 64 bit computer, what should I do later in order for
my application to work under 32 bit windows machines?
You might be surprised, but that's actually a totally different question. Setup systems (e.g. MSI) are highly dependent on the operating system. Most MSI's therefore use hacks to make it work on both platforms. Wix has some quite good documentation about this.
I have made a .Net win-forms application in C#, on a 32 bit OS (Windows 7).
It doesn't work on the deployed client-terminal/machine which has a 64 bit OS (Server 2008).
What should I do?
Thank you.
Go to the Build tab of the project's properties and make sure the platform target is set to x86. (This is just my first guess based on the vague information provided. The problem might be caused by something completely else, e.g. the terminal server environment as such.)
You should only change this setting if you need your application to address a large amount of memory or you definitely want to make sure it runs as a 64-bit process.
The AnyCPU setting can hardly be recommended as it may cause you all sorts of pain with respect to native dependencies (I'm not saying it should never be used, but it should be very well considered whether the additional overhead required for deployment and testing is worth the trouble).
Probably you have used some feature that is not available while running the app in x64. Change the build configuration to x86.
If it does work now, you have used some libraries (COM, ActiveX, Office 2007, WinAPI, ...) that does not like to be called from 64 bit.
If it works now, ask yourself: why do I want my app to run using x64 bit? What do I gain? Does it really need to use that much memory?
There is no problem with running a x86 bit app on a x64 bit platform.
If you are using ActiveX controls inside your application or anything else that is not portable to x64, you might have to change the build target to "x86".
If it's a genuine x86 application your x64 environment shouldn't have any problem running it. So make sure all your libraries and your own binary are x86 compatible and don't use x86 exclusive features like specific COM libraries.
You should ensure that you project is being built with the "Any CPU" platform.
The default is sometimes to build for "x86".
Check your build config. I think VS will default to building the app for x86 platforms if you develop in a 32-bit environment. Either change to x64 or AnyCPU, rebuild and try again.
.stompp
I've been a Windows user since forever, and now I need Linux to create an application using Mono. Which Linux distribution is best for me? I will use it in a virtual machine.
Mono is primarily written on and tested on openSUSE. The packages we release are for openSUSE. In fact, we release a VMWare Image of openSUSE with the new version of Mono all set up and ready to go:
http://www.go-mono.com/mono-downloads/download.html
Having said that, we have a great community of people who work to ensure Mono runs well and is packaged on all the major distributions, such as Fedora and Ubuntu.
No distribution is generally better than any other. Download the live CDs of the distributions from the net, run them in your VM and use the one you like best.
It's not like any distro is really "better" for Mono development than another, but since you are using a VM, I would look for one with low resource usage.
The easy answer is obviously OpenSuse for a quick easy and painless developer experience. However, if you don't need the latest and greatest mono bits and are setting up a webserver you might want to use a distribution that has a more enterprise philosophy (SLES, RHEL, Ubuntu LTS). Or if you like a minimalist distribution you may want to try gentoo for a kernel that does nothing but what you need.
Personally, I develop on OpenSuse to have the latest tooling, but target redhat because that is a brand that people I work with know and trust. It is not a technical reason, but a political one. What are your other VMs running? Mono even runs on Windows, Mac and Solaris.
Anything Gnome-based should be useful for you (since Gnome is moving to mono). Ubuntu has a lot of traction, a really excellent support base and Gnome support.
I would say that the easier to use and more complete (free) distros are Fedora, Debian and Ubuntu.
I have been a RedHat user since... forever. I switched to Fedora when that project started (it's simply the free, open version of RedHat). Some releases are flaky, some are just fine, but on average I have had much less critical problems than with other distros I have tried. Right now I am using Fedora 10, and since my mother has been able to use it, I guess they have made real progress in user interfaces and usability! ;)
I'd suggest that you download a premade VM of some flavor. As for which distro, if it's a client app, go with Ubuntu. If it's a server app, it doesn't matter, so go with Ubuntu. ;P
Here's a good premade VM that I've used for testing in the past: http://www.vmware.com/appliances/directory/95733
VirtualBox + any Ubuntu + mono/MonoDevelop = work perfectly to me out of box.
I am developing a WPF application where the 3D part is handled by DirectX 9 (a lot of 3d that did not run fast enough using WPF).
The problem is the application is released with "Any CPU" as configuration and when a user runs it on a 64 bit windows, the direcX part crashes (System.BadImageFormatException). Apparently the dlls included for the directX part is not usable on a 64 bit windows.
This has happened with some other 3:rd part dlls that we use in our application but this we have solved by changing the dlls in runtime to the ones built for x64 if the user are running on a 64 bit windows machine. Do any of you know where I can find DirectX 9 dlls for x64? If they exist at all.
The ones I need are:
Microsoft.DirectX.Direct3D
Microsoft.DirectX.Direct3DX
Microsoft.DirectX
If they do not exist, can the problem be solved in some other way? I cannot change the configuration to x86 because the application is released via ClickOnce and a change of configuration make ClickOnce stop working (the configuration is included in the ClickOnce key)
Let me add that the I am using a Winforms part hosted by the WPF application and that the winforms part is using the DirectX dlls I am asking about. This was a much better and faster way of presenting a lot of 3D meshes in WPF than to use WPF:s 3D. Unfortunately this problem occurred instead.
The DLL's you need are for Managed DirectX. Unfortunately Microsoft no longer supports Managed DirectX and it's successor, XNA does not support 64bit either.
SlimDX is an open source alternative to Managed DirectX, and it supports 64bit. The other option is to write the DirectX code in unmanaged C++.
You can set your WPF application to only run as a 32-bit app. Post your ClickOnce problem as another SO question. This is probably your best option.
Project Properties -> Build -> Platform Target -> x86
Does anyone know IF, WHEN or HOW I can get Memcached running on a Windows 64bit environment?
I'm setting up a new hosting solution and would much prefer to run a 64bit OS, and since it's an ASP.Net MVC solution with SQL Server DB, the OS is either going to be Windows Server 2003 or (hopefully!) 2008.
I know that this could spill over into a debate regarding 32bit vs 64bit on servers, but let's just say that my preference is 64bit and that I have some very good reasons.
So far, I've tried a number of options and found a bit of help related to getting this up on a 32bit machine (and succeeded I might add), but since the original Windows port is Win32 specific, this is hardly going to help when installing as a service on x64. It also has a dependency on the libevent for which I can only get a Win32 compiled version.
I suspect that simply loading all this up in C++ and hitting "compile" (for 64bit) wouldn't work, not least because of the intricate differences in 32 and 64bit architectures, but I'm wondering if anyone is working on getting this off the ground? Unfortunately, my expertise lie in managed code (C#) only, otherwise I would try and take this on myself, but I can't believe I'm the only guy out there trying to get memcached running on a 64 bit Windows server....am I?
Update
Yes I'm afraid I'm still looking for an answer to this - all my efforts (with my pathetic C++ skills) to make a stable build have failed - I've trashed one server and 3 VM's just trying it out so now I turn to the real experts.
Is anyone planning on porting this to 64bit? Or are you really suggesting that I use MS Velocity instead? I shudder at the thought.
Update:
#Lars - I do use Enyim actually - it's very good, but what you're referring to is a client, rather than the server part.
#DannySmurf - I've only been able to install it as a service on a 32 bit OS. 64 bit OS rejects the installation of this Win32 service. Of course yes, lots of Win32 code works seamlessly on x64 architecture, hence you can run 32bit apps (like Office for instance) or games on Vista/XP 64 etc, but this doesn't translate directly when it comes to services. I'm no expert, I suspect that it has to do with the syncs or eventing that services need to subscribe to, and I suspect that 64 and 32 don't play nicely. I'm happy to be corrected on any of this, but to answer your question - yes I have tried.
#OJ - thanks very much for the straight-forward response. I thought as much, but wasn't sure if anyone else had suggestions or had already gone down this route. Maybe when StackOverflow is LIVE, then more people will respond and let me know if this is something being looked into, and although I can try and compile it myself - I simply can't "trust" (with my C++ experience level) that it would provide "Enterprise Level" reliability in such a crucial component of large scalable solutions. I think it would need educated intervention rather than my unsanitised experimental approach before I could be confident. One little oversight on my part, could bring the site down. Oh well... till next time.
North Scale labs have released a build of memcached 1.4.4 for Windows x64:
http://blog.couchbase.com/memcached-windows-64-bit-pre-release-available
http://labs.northscale.com/memcached-packages/
UPDATE: they have recently released Memcached Server - still FREE but enhanced distro with clustering, web-based admin/stats UI etc. (I'm not related to them in any way) Check it out at http://northscale.com/products/memcached.html and download at: http://www.northscale.com/download.php?a=d
UPDATE 2: NorthScale Memcached is no longer available as a standalone download. Now they have made it part of their commercial No-SQL DB offering called Membase. It can be configured to run in Memcached-only mode (i.e. without persistence) and there's a 100% free version too. Check it out here: http://www.membase.org/downloads
UPDATE 3: MemBase has slept with CouchDB and produced a hybrid product offering, called CouchBase. They still do offer a free "Community" version at http://www.couchbase.com/download
Just so people know, the 32-bit and 64-bit version as build by the good people from membase/couchbase/whatever is still available the blog URL has changed though:
32-bit binary of memcached 1.4.4 as Windows-service:
http://blog.couchbase.com/memcached-144-windows-32-bit-binary-now-available
http://s3.amazonaws.com/downloads.northscale.com/memcached-win32-1.4.4-14.zip
64-bit binary of memcached 1.4.4 as Windows-service:
http://blog.couchbase.com/memcached-windows-64-bit-pre-release-available
http://s3.amazonaws.com/downloads.northscale.com/memcached-win64-1.4.4-14.zip
The 64-bit version does have the wrong uptime.
So maybe you want this binary of 1.4.2 instead:
http://www.urielkatz.com/archive/detail/memcached-64-bit-windows/
The 32-bit version as included with MemCacheDManager also suppors running on Windows 2000 (no IPv6):
http://allegiance.chi-town.com/MemCacheDManager.aspx
http://allegiance.chi-town.com/Download.aspx?dl=Releases/MemCacheDManager_1_0_3_0.msi&rurl=MemCacheDManager.aspx
To unpack the msi:
msiexec /a Releases_MemCacheDManager_1_0_3_0.msi /qb TARGETDIR=c:\memcached
Memcached 1.4.5 binary for win x64 can be found here: http://downloads.northscale.com/memcached-1.4.5-amd64.zip
Another option would be to install Couchbase Server 1.8.0 x64 from here: http://www.couchbase.com/download, the bundled memcached seems to be version 1.7.1.1 (sounds like an internal version, I can't tell which is the real one)
As for running memcached as a service, this tutorial might be enough:
http://www.richardnichols.net/2010/08/install-memcached-on-windows-server/
Up-to-date Binaries
NorthScale has really old versions (the newest is 1.4.5 which is from April 2010) but there's a guy who offers 64-bit Memcached binaries for Windows compiled using Cygwin (but they don't require it installed) in his GitHub repository github.com/nono303/memcached.
For example, the binaries of the most recently released version (as of writing this answer) 1.5.16 are here. There're both 32 and 64-bit versions.
Memcached as a Windows Service
If you want to install it as a Windows service, you can use for example the open-source Non-Sucking Service Manager:
nssm install memcached c:\path\to\memcached.exe
nssm start memcached
See the documentation for details.
I have an memcached-1.2.1 for win32 originally downloaded from here: http://jehiah.cz/projects/memcached-win32/ (but now for some reason it is a broken link).
This is how I managed to run memcached for Win32 on Windows Server 2008 R2, 64 bit.
memcached.exe -> properties -> Compatibility -> Run this program in compatibility mode for: Windows XP (SP 3).
Notice that the user Uriel Katz mention in this discussion that this method restricted to 2GB memory of use.
I personally feel that you'd have to recompile the application using a 64-bit compiler (obviously on a 64-bit machine) to get the most of Memcached on a 64-bit platform. This may not be an easy task depending on the code. If it was written with 64-bit portability in mind then it could be a simple recompile. If it hasn't, then you could well be up for quite a bit of patching before getting it to build.. and then you'd have to verify that you haven't broken anything!
I don't think you're overestimating the differences between 32 and 64-bit at all. A common mistake is to assume that the job is a simple recompile when in fact it isn't. There are more portability issues than most people realise. Just because the application builds and you end up with a binary, it doesn't mean that the binary is going to behave as it should. Especially when it may interact with other 32-bit code.
Having said that, it might be worth giving it a spin!
Good luck. Cheers!
#Lars: I recommend reading the question before attempting an answer.
#John Sibly & #DannySmurf: given the nature of Memcached and what it aims to achieve, surely you wouldn't want to run a 32-bit version on a 64-bit machine? If you had a 64-bit capable machine it would make sense to run a 64-bit version to make the most of the features of the hardware.
I was just searching for memcached on a 64bit Windows system and found this. So far there isn't any Win64 memcached version. But I just started the memcached.exe with the appropriate commands via cmd and it's just running fine. I'm using Windows Vista 64bit, don't know if there are any differences between Vista and the server versions.
Kindest regards
Fleshgrinder
The 32 bit version run on 64 bit via WOW64 but the process is still limited to 2GB,with a 64-bit version you can go beyond that to more than a single machine will have.
FYI, I couldn't get the 64 bit version (from here http://labs.northscale.com/memcached-packages/) to install as a service until I ran memcached as administrator.
I just went to the executable's properties, then the Compatibility tab, and checked "Run this program as an administrator" (There a ton of other ways to do this, but it seemed simplest)
Then I was finally able to successfully run: memcached -d install
Don't forget to start the service after it is installed too :)
You could always run multiple instances of 32-bit memcached processes on one box, allowing that machine to serve a total of > 2GB memcache space.
Are you sure that the 32-bit version doesn't just run on 64-bit Windows, without modification? Most things do.
Failing that, have you actually tried just compiling it for 64-bit? A brief scan of a few Google Groups etc where people asked this same question suggests that that may be exactly the solution to this. I think you're probably overestimating the difference between 32-bit and 64-bit Windows (at least as far as compiling a native application goes).