| << May >> | ||||||
| S | M | T | W | T | F | S |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
64bit Adventures
11/6/2011
I've been playing around with 64bit builds of Scribe on windows. And it's been er... interesting to say the least.
I've been playing around with 64bit builds of Scribe on windows. And it's been er... interesting to say the least.
- By default the Visual Studio 2005 installed doesn't install the x64 compiler and libraries. Nice...
- When you do get that installed, and then create an x64
profile in your solution you get the option to copy the
settings from the 32bit profile. Which for the most part
works, but when you try and compile said x64 profile, you
discover this delightful error:
fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
Which in a nutshell means you are linking 64bit objects into a 32bit binary. However the standard response that people get on the forums is that you have to set your Linker- >Advanced->TargetMachine correctly. And you know what? Well it WAS set correctly to MachineX64. So what gives? Well if you click on Linker->CommandLine and look in "Additional Options" you'll see /MACHINE:I386. Sigh. - When running Windows7 64bit and you put additional 32bit DLL's in C:\Windows\System32 you'd think... that since there is a "32" in that folder name that is where they go. Well no... the 64bit DLL's go in System32 and the 32bit DLL's go in "System". Gaaaaahhhhh.
Visual Studio 2005 / Win9x support
31/5/2011
I'm officially migrating to Visual Studio 2005 as my main compiler on windows, from Visual C++ 6. So all the open source apps I've released will be getting VS2005 projects over the next few weeks. Also on top of that rather obvious change I will be deprecating support for Windows 98 and ME, slowly removing that support from Lgi and migrating to unicode as default across all my apps. I've been using Utf-8 and multi-byte charset for a long time, but now the default compile time option will be Unicode instead of Multi-byte characters.
I'll also be looking at building 64bit versions of my apps on Windows in the near future. Now that I need the address space but I would like all the libraries to support that if at some point I DO need it. Over the last week or so I've been switching on the VS2005 64-bit warnings and resolving most of them.
On the Mac I'm going to be using XCode 3.6.2 for a good while yet. I only recently settled on that as my standard compiler there, and did a lot of work getting the code to a point where it compiles without too many warnings. The Carbon backend is a worry though. I can't create new Carbon apps with that XCode so that sucks. Eventually I'll have to address that by porting the main Lgi core to Cocoa. But that would take a good while *sigh*
I'm officially migrating to Visual Studio 2005 as my main compiler on windows, from Visual C++ 6. So all the open source apps I've released will be getting VS2005 projects over the next few weeks. Also on top of that rather obvious change I will be deprecating support for Windows 98 and ME, slowly removing that support from Lgi and migrating to unicode as default across all my apps. I've been using Utf-8 and multi-byte charset for a long time, but now the default compile time option will be Unicode instead of Multi-byte characters.
I'll also be looking at building 64bit versions of my apps on Windows in the near future. Now that I need the address space but I would like all the libraries to support that if at some point I DO need it. Over the last week or so I've been switching on the VS2005 64-bit warnings and resolving most of them.
On the Mac I'm going to be using XCode 3.6.2 for a good while yet. I only recently settled on that as my standard compiler there, and did a lot of work getting the code to a point where it compiles without too many warnings. The Carbon backend is a worry though. I can't create new Carbon apps with that XCode so that sucks. Eventually I'll have to address that by porting the main Lgi core to Cocoa. But that would take a good while *sigh*
Tags: coding | (0) Comments | Add Comment