--- In
psychtoolbox@yahoogroups.com, "IanA" <iandol@...> wrote:
>
> --- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@> wrote:
> > The 64-bit ptb's for Windows or OS/X are still far away, in case anybody wonders. Linux is by a large margin the most pleasant os for doing 64 bit ports, basically an almost painfree, straightforward endevaour. The other systems are quite the opposite, so Windows is probably still many months away and i wouldn't expect a 64 bit os/x version before the end of 2011 (optimistic guess).
>
> Would being able to build on a newer OS X install make a difference. I tried building Screen myself, but there were many warnings and errors, and I realise I don't have the same dylibs you have which appear to be dependencies. But I wondered if a 10.6 + XCode environment could make this easier? Or are the problems deeper than just building universal binaries...
No, the problems are as deep as they can get as far as a 64 bit port is the goal. I'll need to rewrite large parts of the OS/X specific code from scratch. Or find some other ways to avoid that, which is mostly my plan. Apple made sure that their 64 bit api's are as backwards incompatible as possible to their 32 bit api's, so they can force each developer to throw away large parts of well working code and learn a new programming language that nobody outside apple ever cared about in order to incompletely restore functionality by use of new api's nobody wanted. But hey, it's 64 bit and 64 bit is good and Apple thinks different than the rest of the slightly more sane software development world. And who would disagree? After all, os/x is the worlds most advanced operating system [according to Apple], so it must be good and Steve knows what's good for you.
This brain-damage is also the reason why it took Adobe forever to provide 64 bit apps for Mac and why MS-Office is still 32 bit only on Mac.
Things that won't work at all on 64 bit and need to be rewritten from scratch
* All setup/management code for windowed onscreen windows and anything that interacts with the desktop window manager.
* Everything related to mouse queries and handling.
* Everything Quicktime: Videocapture, video recording, movie creation and movie playback.
* Everything related to font handling and text rendering.
* All kinds of other more tiny bits. And all the stuff i'm not aware of yet.
Incidentally these are also the parts which took the most time of tinkering, debugging, testing and refinement to get right - the most painful bits to reimplement. All these subsystems, which matured sometimes over 10-20 years in Apple's operating systems and still contained many bugs have been replaced by relatively new and relatively immature technology.
I'll probably be able to bypass reimplementation of some of these bits by reusing api's and functionality that comes from Linux but has been ported to os/x. E.g., the Linux based font handling and text rendering has been ported and is implemented in the os/x ptb as an option. Quality and speed of the Linux text renderer are as good or better than the os/x renderer, but some of the more exotic parameters are ignored on the linux renderer, and text appearance will be slightly different. If you just want good looking text, no problem. If you are into very precise text rendering, your stimuli will be different between the 32 bit ptb and the 64 bit version.
The Quicktime engine i will likely scrap completely. The GStreamer framework from Linux works already very well on Linux and pretty ok on Windows for the tasks Quicktime did. I'll try to use that on os/x as well, so we get rid on these dependencies on Apple technology as much as possible.
The rest is unclear. In theory one could (ab)use/recycle the X-Windows window management code from Linux on OS/X as well, as OS/X has X-Windows system support. But Apple being the unpredictable company it is and Mathworks being Mathworks, who knows if X11 isn't the next thing they will remove because Steve changed his mind about what's good for you? Also their X-Windows layer is much less capable than the Linux counterpart.
The os/x port is a big undertaking with many known problems and probably also a couple of unknown problems. My conclusion is that in the future we shouldn't rely on a company that shows such unpredictable and unfriendly behaviour towards developers. Getting rid of as many os/x specific technology as possible is the plan, replacing it with cross-platform code as much as possible. I probably won't even start looking into this until "Lion" is released and i'll have much more time. I'm sure Apple will add some unpleasant and brain-damaged surprises to that system as well for a bit of extra entertainment.
On MS-Windows i don't expect such severe problems, just the usual pain of dependency hell that is associated with doing anything on that platform. Microsoft has many faults, but at least they know that it is important to not intentionally piss off their developers.
On Linux, the Linux specific part of porting was done in less than four hours: Reading through code to confirm it already does the right thing and fixing less than 10 lines of code. The rest is automagic, to cite Apple, "It just works(tm)".
All the rest of time (about two weekends of work) was spent checking and fixing our own operating system independent core code. This is now mostly done and doesn't need to be repeated for the other systems.
But thanks for asking, shared pain is only half the pain.
-mario