On linux the x64 build worked out of the box.
Windows x64 build does not compile. so i tried to fix the problems myself
Here is what i have found.
there is only one error in juce itself,but some problems in libvorbis and libflac ( concerning usage of assembler ocde for x86)
furthermore the vcproj files of jucedemo do not use $(PlatformName)
the juce rpoblem is just in \juce\build\win32\platform_specific_code\juce_win32_AudioCDReader.cpp in AudioCDBurner::burn UINT cookie;
must be UINT_PTR cookie;
the ogg vorbis fix is in os.h #if defined(_WIN32) && !defined(GNUC) && !defined(BORLANDC)
define VORBIS_FPU_CONTROL
must be #if defined(_WIN32) && defined(X86) && !defined(GNUC) && !defined(BORLANDC)
define VORBIS_FPU_CONTROL
the flac fixes are somewhat more, but easy to do. everywhere you get an compile error you have to change #ifdef _MSC_VER to #if defined _MSC_VER && defined(X86)
Thanks for the info! I’ll sort those out. Isn’t there a way of cross-compiling a 64-bit exe on 32-bit system…? I can’t seem to find a setting for this in MSVC…
Which mscv do you mean?
For vs2005 and vs 2008 it is possible, but you must have chosen to install it, i think.
the setting is easy then, just go to Build/Configuration Manager
select Active Solution Platform combobox and select New…
type of new platform choose x64 and let it base on Win32 as it is default.
by the way , the svn juce is not compilable with unicode character set. the mapi mail stuff does not work, because it is always LPSTR (never LPWSTR) but u use LPTSTR. and the other one i ve forgotton. but if you choose no win98 define to be 0 it goes way. actually i ask myself why juce::string uses unicode by default, but the win api (your vcproj setting) does not. this way all communiction with windows will make problems like files etc.
the treeview demo shows a nasty error dialog because it chooses my A: as drive to show. maybe you dont have a A: drive anymore so do not see this error.
ah yes, I knew it was there somewhere - I was looking for it under the project settings. Will have a go at compiling in 64-bit mode.
All the win32 calls are done dynamically using unicode, but compiled without it so it can use the ascii versions under win98 if it needs to. Will probably phase that stuff out soon.
BTW, the MAPI doesn’t seem to have a unicode equivalent - if you look at the structure in mapi.h, it’s only got a version with LPSTRs. And the MAPISendMail doesn’t have a wide-char variant like most other win32 functions. But it does work for me - what problems are you having?
yes mapi.h is only ansi. (that was what i meant by saying “the mapi mail stuff does not work, because it is always LPSTR”)
I didnt realize that your wa to unicode is using the W api functions. But actually you are not doing it everywhere. GetLogicalDriveStrings und GetVolumeInformation. and there i were debugging, to find the cause for the error box, which i found was because of the access to A:
I had set the unicode character setting in vcproj, which leads to the definion of _UNICODE and TCHAR becomes WCHAR. actually the use of TCHAR puzzles me a bit, this makes only sense if you use _UNICODE sometimes.
ah, I thought you were saying that I was using the ansi version instead of unicode. In what way is it failing for you?
Wouldn’t have thought that GetLogicalDriveStrings or GetVolumeInformation really need to be unicode, but I guess they could be. Will probably just leave them until I finally dump win98 compatibility and do the whole thing as unicode.
Ok when i compile as unicode with _UNICODE defined:
thsi line for example:
message.lpszSubject = (LPTSTR) (LPCTSTR) emailSubject;
becaomes
message.lpszSubject = (LPWSTR) (LPCWSTR) emailSubject;
which will not work because message.lpszSubject is always LPSTR.
there are some other lines near this.
another line is with the Http stuff.
buffers.lpcszHeader = (const char*) headers;
should be buffers.lpcszHeader = (LPCTSTR) headers;
because buffers.lpcszHeader is LPCWSTR with _UNICODE defined.
defining _UNICODE for unicode build is just the way it is
Why else would you use TCHAR in your code? this makes only sense if _UNICODE is to be used in some configuration.
