I am curious to know if an Adobe Air, when deployed a .air file is actually 32 bit or 64 bit.
I understand that any native version would be one or the other.
I think its neither because .air is just a package containing an swf?
The Adobe docs do not answer this.
You're right, it is not containing runtime, OS will be using either 32bit or 64bit runtime, depending on which is installed on system. Note that it is not applicable to bult apps in .exe, .apk, .ipa or if you use native extensions
Related
If I run this command:
file /System/Library/Frameworks/GameKit.framework/GameKit
I get:
/System/Library/Frameworks/GameKit.framework/GameKit: Mach-O 64-bit
dynamically linked shared library x86_64
Which equates to my iMac (a brand new one) is missing the x86 version of GameKit. So my x86 Mac application (it is a C# Xamarin.Mac app) crashes when referencing GameKit.
Does anyone know if this is going to be an ongoing issue for future Macs? Or is it an Apple bug that this is missing on my machine?
Everything points to Apple deprecating 32-bit (architecture i386) code at some point. This is because they took advantage of switch from 32-bit to 64-bit code to add features to the Objective-C runtime, making 64-bit runtime more featureful.
I have no confirmation for this, but judging from how PowerPC transition was handled, and how 64-bit code deprecates loads of ancient technologies, this is probably not far off.
Although I do have 32-bit GameKit on my machine, it would not surprise me at all if a future release of OS X might contain no 32-bit code. And since all Macs that contain GameKit must be able to run 64-bit code (a requirement for Mountain Lion), the best advice I can give is to add a 64-bit version of the app. I have no idea if MonoMac supports 64-bit code, but that's the direction you should go to.
I suspect an OS update (such as the upcoming 10.8.3) might install a version of GameKit that happens to contain 32-bit code. Or it might remove 32-bit code for the rest of us. But I would absolutely not count on Apple maintaining or adding new features to 32-bit code, precisely because many features that they like (such as ARC or synthesizing ivars) can't be supported by the so-called 32-bit Objective-C runtime without breaking binary compatibility.
Hi!
I have an old plugin (as binary, dll), used by my application. It was build for WM2003. And now it crashes the app, if loaded on Windows Mobile 6.1 (WM5 works fine, WM6 too).
The source code is not available and it's no more supported by developer. So I can't rebuild it for WM6.1.
Is it possible to patch or convert the binary to allow it to work on WM6.1 ? If so, how can I do this ?
Thank you.
Edit: I've found, that the problem is in PE loader, which acts not the same on WM6.1 (comparing with WM6 and earlier).
Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.
This problem is rare, but some information can be found.
The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.
I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...
And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).
I don't like this workaround, so I try to find some binary patcher. And found it :)
It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.
I've noticed that all betas for Dropbox are released simultaneously for Windows, Mac and Linux. How do they do that? Anyone knows which platform they're using? I'm aware that there are many native -very impressive, actually- functions in each of the platform clients, but they seem to release critical bug fixes efortlessly for all platforms.
So any idea of which GUI platform they're using?
The Linux version includes files such as wx._windows_.so, libwx_gtk2*.so, etc. (I haven't checked the others), so I suspect Dropbox uses wxWidgets.
Qt is a popular cross-platform application and GUI framework with native look-and-feel.
I don't know what Dropbox uses for all its supported platforms, but it looks like its linux client uses at least Gtk: Dropbox linux System Requirements.
I'm doing a little app that I want to distribute in different platforms, at least the 3 major ones.
Is it possible to use only Windows has the host OS to compile the binaries for Linux, Mac OS X and other supported platforms without resorting to virtual machines?
Or should I ask around in some community to help me compile on, well OS X, actually, since I can virtualize a Linux machine quite easy?
It is possible to compile from one plateform to another, it is called cross-compilation. You will find extensive informations at http://www.stack.nl/~marcov/buildfaq.pdf
The buildfaq above contains sample cross-compilation :
from Windows to Linux,
from FreeBSD to AMD64 Linux
The FPC download page contains :
the i386-win32 to x86_64-win64 cross-compiler
the i386-win32 to arm-wince cross-compiler
The FPC mailing lists are at http://www.freepascal.org/maillist.var
You will find more informations about FPC at http://www.freepascal.org/moreinfo.var
(I'm the author of the buildfaq document above)
There are some limitations. You can't target x86 from powerpc, because powerpc misses an "extended" type. But in generally it works.
I have generated a complete Lazarus for OS X on Windows.
I would virtualize Linux, as even if you can cross-compile, it means you're not testing the binaries on their native platforms. OS X is a trickier problem.
It is not possible to compile from one platform to another. We have a Mac and use FPC quite often. If you need some help with compiling on a mac, drop me a message.
I know that MAC OS X 10.5 comes with Apache installed but I would like to install the latest Apache without touching the OS Defaults incase it causes problems in the future with other udpates. So I have used the details located at: http://diymacserver.com/installing-apache/compiling-apache-on-leopard/ But I'm unsure how to make this the 64 Bit version of Apache as it seems to still install the 32 bit version.
Any help is appreciated
Cheers
Add this to your ~/.bash_profile which means that your architecture is 64-bit ant you’d like to compile Universal binaries.
export CFLAGS="-arch x86_64"
This page claims that a flag for gcc (maix64) should do the trick. Give it a whirl, and if you need any more help, post back here.
Be aware that you may run into issues with your apache modules. If they are compiled in 32-bit mode, then you will not be able to load them into a 64-bit apache.
I had this issue with mod_python, took a bit of thinking to figure out this was the reason.
Don't export CFLAGS from your .bash_profile or any other dot file. Your home directory could live on for decades, the system you're currently using is transient.
There's a guide on Apple's web site, Porting UNIX/Linux Applications to Mac OS X, that talks specifically about how to make autoconf and make and other similar build systems fit into the Mac OS X Universal Binary scheme. If you're going to build cross-Unix applications on Mac OS X, you need to read and understand this guide.
That said, I strongly question why you want to build Apache 64-bit. Just because Leopard can run 64-bit software doesn't mean you want all software on your system to be 64-bit. (It's not Linux.) In fact, virtually none of the software that ships with Leopard runs 64-bit by default, and most of the applications included with Leopard only ship 32-bit.
Unless you have a pressing need to run Apache 64-bit, I wouldn't bother trying to build it that way.
If you would have read a bit further on the same site there is some information on compiling Apache in 64 bits mode!
http://diymacserver.com/2008/10/04/update-on-64-bits-compilation/