I'm an experienced Linux programmer, familiar with POSIX, stdio.h and so on, but totally new to Mac programming. This week I'm attempting to get a piece of source code written by someone else a few years ago to work on 64-bit Snow Leopard. It's a Photoshop plugin originally for CS3, now to be made to work with CS5. (Don't ask me about CS4.) This plugin is built at the command line with a handwritten makefile using gcc.
The main roadblock today is the compiler complaining about several undeclared functions: FSRead, FSWrite, SetFPos, GetFPos, and more, all having to do with files. I'm pretty sure I have the right paths, options etc.
After two days grepping headers, googling, and trying to cheap hacks, I am stuck. Where are these functions defined? Are they standard Mac OS X library functions, or Photoshop SDK functions? Some google results suggest these functions are obsolete, "deprecated" but I guess by now truly gone. If that's the case, what should I be using instead?
After two days grepping headers, googling, and trying to cheap hacks, I am stuck. Where are these functions defined? Are they standard Mac OS X library functions, or Photoshop SDK functions?
They are old Carbon APIs. You can use the Carbon framework, however Carbon is not ported to 64-bit systems. As Photoshop is 64bit, this simply won't work.
I'm not familiar with how Photoshop plugins are handled, but if you are looking for a direct replacement you would look at Core Foundation, a C API. In reality, you can also use the POSIX APIs. If Photoshop uses Cocoa and Objective-C, you can use the Foundation and AppKit family of APIs.
Related
I have a piece of old Mac OS X code that I'm to recompile for the modern version of the OS. The code uses functions like GetIntlResource or SysBeep and the compiler complains that they have been deprecated long ago (in Apple years, apparently). I'd be happy to replace the calls with something more modern, but I cannot find any docs on these functions. (I expect the docs to say something like “deprecated, use FooBar instead.”) Same for functions like CreateWindowFromNib and such; these are worse than deprecated, they are not even there. Searching developer.apple.com or Google produces no useful results.
Is there a way to find documentation on old Apple APIs to understand at least what they were doing?
Update: Found what they call a legacy library; not searchable (e.g. you cannot search by a function name), but it's better than nothing.
Update 2: The thing was originally compiled for Mac OS X v10.4, I think. If I configure the build to target that version, it works fine without any warnings. Naturally, a 64-bit build is not possible, but that is expected. I guess it's OK to close this question, since I found the cold storage myself.
The particular calls you mention date from before OS X. At that time, the core of Mac programming documentation was the Inside Macintosh series of books. These are available in the "retired documents library" that you linked, however the search bar there seems to skip over them.
Try using Google queries like "Inside Macintosh" SysBeep. It's not foolproof, but you can find the given APIs here:
SysBeep in Inside Macintosh: Macintosh Toolbox Essentials
GetIntlResource in Inside Macintosh: Text
Essentials serves as a sort of in-depth overview and refers to other books… these were written before the Internet took off. The library of books is pretty much self-contained, but it only captures a snapshot of the mid-1990's. I don't suppose that a rehashed version for OS X 10.4 survives, if it ever existed. I only recall them publishing lists of pre-OS X routines that were blessed for forward compatibility.
I have found plenty of articles and how-tos online about making plugins for Photoshop on a Mac. Trouble is, many are old, apply only to CS1/2/3/4, or refer to tools or APIs that (it appears) are obsolete. Some articles say you must use CodeWarrior, but it seems this no longer even exists in the Mac programming realm.
Today, in 2011, making plugins only for CS5 and only on a Mac running Snow Leopard, what is the proper toolchain and what libraries/APIs/frameworks should I be using?
I've gotten the impression that Carbon (whatever exactly that is) is old and to be avoided, but it's not clear if that's true for plugins. I am not clear as to whether I should use Cocoa (whatever that is) or not. I do think I will need Core Foundation (whatever...) Is there a choice about 64 vs. 32 bit or is CS5 purely 64 bit and that's that? (I prefer 64 bit, of course.) I do have the Photoshop CS5 SDK, and Photoshop CS5 itself installed.
Can XCode can be used as an IDE? I'll hand-code a makefile and compile at the command line, if that's easier or the only way possible. If XCode can be used, which project template to use? What is this "Mach-O" I read about, and how does that apply to PS plugins?
It's especially confusing since I'm a total noob at Mac programming of any kind, though many years experienced on Linux and other platforms.
Mission accomplished! (Months ago.. I just realized I had this question sitting here.)
Cocoa is useful for GUI settings windows and other things - it's a huge gob of stuff - but I ended up using it only for the "About" popup window for my plugin.
Completely forget about Carbon for the combination of CS5 or later, OSX 10.6 or later, and 64 bit. Apparently parts of Carbon had been made 64 bit in the past, but should be ignored now.
XCode is a fine editor. Start with a "dylib" project using C. C++ and Obj-C source files can be added without any fuss. There's no way getting around just needing to use XCode for some simple toy projects to gain familiarity with how it organizes things and builds apps and libraries. This is the only real "tool" needed; the rest is APIs - header files and libraries (or "frameworks" in the Apple world). While toying with XCode, get to know what a "bundle" is - a folder containing the executable and other files needed by the app.
Paths need to be set up to the Photoshop CS5 API, there being two or three specific directories to be listed. You may need to copy certain common source files out of the Photoshop example plugins directory, and there was a bit of trouble with a file named MachOMacrezXcode.h about which see What is the meaning of exit code 3 from Rez?
Unfortunately there were no truly useful examples of well-written plugins for CS5 on 64-bit. A combination of the Dissolve example, the SimpleFormat file read/write plugin, browsing source for plugins at http://www.telegraphics.com.au/sw/product/FilterFoundry and asking questions on the Adobe Photoshop SDK forum.
Pay no attention to the clumsy process of using some "Plugin Suite" for obtaining memory. It's like Microsoft's old 16-bit Windows API where you needed "memory handles" and thick malarky that is now several times obsolete. These days, good ol' malloc/free or new/delete are fine.
With all the arrowhead wounds I now have in my back, maybe I should write a book or something...
I want to learn Ocaml or Haskell and I want to do it by writing a simple game. Apparently, there's one small problem: nobody cares about Windows and I want to do it on Windows, natively.
Haskell has Cabal, which has SDL, but it doesn't build due to a trivial problem with no workarounds (order of parameters passed to gcc). Ocaml doesn't even have that, it's all in source packages, be it GLCaml or OcamlSDL or whatever.
Is there a place where I can get a working SDL for Haskell or Ocaml on Windows without fighting with a dozen versions of compilers?
The Haskell Platform comes with a binding to OpenGL which should work out of the box on Windows.
Concerning the SDL package on hackage, you can use cabal unpack SDL to get the source code and fix things yourself. To install the package with your changes, run cabal install in the unpacked directory. In any case, drop a line to the maintainer, I'm sure he'll help out.
It's not related to SDL, but you've mentioned OpenGL. There is LablGL binding for OpenGL in OCaml which works out of the box. Wiki example (http://en.wikipedia.org/wiki/Objective_Caml#Triangle_.28graphics.29) compiles and works just fine.
The best instructions I've found for getting SDL to work in windows with a the most recent Haskell platform can be found at this blog. I followed everything step-by-step and it worked perfectly, despite some configure error messages.
It isn't SDL but GLFW works on Windows with Haskell through Cabal.
My article High-fidelity graphics with OpenGL 2 (25th Feb 2008) explained how the GLCaml bindings can be used to write OpenGL-based applications in OCaml that use vertex and fragment shaders (a phong shader is given as an example). There are 9 articles in the OCaml Journal on OpenGL, albeit mostly using the older LablGL library for OpenGL 1.1.
I tried and failed to get OpenGL working from Haskell under Linux in 2007. The Haskell Platform may have changed that but I have neither had time to try it yet myself nor ever heard of anyone using it for this.
However, both OCaml and Haskell must rely upon fragile low-level bindings to OpenGL because they are standalone languages and nobody has ever managed to get any significant commercial software using them to work. As you're on Windows, F#+XNA is a far more logical choice because XNA is tried and tested and F# has a safe high-level interface to it. A Google fight gives you a good idea of what a pioneer you'll be: +haskell +opengl gives 437 hits on Google and +ocaml +opengl gives only 347 hits.
I am on a Mac with Snow Leopard (10.6.3). I hear that the assembly language I work with has to be valid with the chipset that you use. I am completely new to this I have a basic background in C and Objective-C programming and an almost strong background in PHP. I have always wanted to see what assembly is all about.
The tutorial I'll be looking at is by VTC [link].
What I want to know is: are the tutorials that I'm about to do compatible with the assembly version on the Mac that I have?
I am completely new to this language although I do recall studying some of it way, way back in the day. I do have Xcode and what I'm wondering is what kind of document would I open in Xcode to work with assembly and does the Mac have a built in hex editor (when it comes time to needing it)?
The assembly language you use is not dependent on your OS but rather your CPU's instruction set. Judging by your Mac version, I'd say you are using an Intel processor - so you would want to learn x86 or amd64 assembly.
A good way to pick up assembly is to get yourself an embedded device to play with.
TI has some nice, inexpensive devkits to play with. I've poked around with the Chronos kit ($50) which has digital watch with a programmable MSP430 microcontroller with a wireless link to your computer. It's pretty sweet.
Update: I forgot to mention the Arduino. It's a pretty nifty open platform with tons of interesting peripherals and projects online.
An assembly language is instruction architecture specific. Chips are an instantiation of an instruction architecture.
In my opinion, you are best served by getting TextWrangler and directly compiling with gcc.
The file extension you are looking for is .s.
Assembly, for any processor, will be more or less the same in concept. However, the complexity varies between processors. From what I see in your site, you'd be doing x86 assembler, (x86 being the instruction set all consumer-line Intel processors use, which recent Macs and all PCs use) which can turn out to be fairly complex, but not overwhelming if you learn by steps.
XCode works with plain text files, I believe. Hex Fiend for your hex editing needs, if you come across them.
Do keep in mind, Assembly is extremely low-level. No ifs, whiles, or in fact any control loop save for "do operation and GOTO if results in (not) zero/equal" (unless your assembler provides them as syntactic sugar, which kind of beats the purpose, in my opinion). PHP knowledge will be at most tangentially useful. You C knowledge should serve you well, though.
The linked tutorials look like they use NASM, which is included with Macs. However, system calls are usually different on different platforms (they're very different between Mac and Linux), and without seeing the tutorials, it's hard to know whether they'll target different platforms (I'd guess not, though). A better bet might be to install SPIM and to learn MIPS assembly, which is more straightforward than x86 anyways.
We are selling an image processing application (about 120k lines of code) developed with wxWidgets. We planned everything to be as most cross platform as possible in case the porting from Windows to other OS was needed. And in fact we are going to realiza a version for Mac.
We haven't tested wxWidgest on Mac yet, but we haven't read very good things about it.
In general, do you think is it worth to port from wxWidgets to QT? Do you believe it will be an hard and long job?
Is QT for Mac much better than wxWidgets implementation?
Is QT much more productive that wxWidgets?
I would like to add that we would'n like to keep code bases for gui, so the choice is just wxWidgets vs QT.
Test your application on Mac, and then decide. If there are only a few wrinkles to iron out, why put in all that extra work to switch toolkits?
It will be a long hard job. Without knowing more about your application and situation, it is hard to say whether making the switch is worth the effort. I do know that I would rather work on a Qt app than a wx app.
I have a friend who recently switched a significant wx application to Qt, and he is quite happy with the change. Mac support is one of his (boss's) important features, but I think wx's support for Mac was adequate, if not stellar.
My experience has been that Qt is definitely more productive than wx.
It is worth noting that wxWidgets on the Mac is transitioning to Cocoa. This should be done for wxWidgets 3.0, but is testable with the development release wxWidgets 2.9 now. Is Qt Cocoa or Carbon based?
We have an application that runs under Windows and the Mac, built using wxWidgets. The application performs very well on both platforms.
I recommend switching over to Qt. wxWidgets is a GUI toolkit, whereas Qt is an application framework with much, much more features.
I can't say anything about their mac implementations, but i can clearly say that i am far more productive using Qt. When i was using wxWidgets, i was a student and then when i got a job, i started using Qt.
wxWidgets gave me a feeling of incompleteness, but as i said, this may be caused by the fact that i was an inexperienced student but nonetheless, i think Qt is way better.
Until you have investigated more and have a good reason(s) to switch toolkits, then absolutely not.
We are using wxWidgets for Linux & the like, Mac, and Windows. It's a great toolkit and certainly much more than just a GUI.
Like dtw and NuSkooler, we are using wxWidgets on Mac (carbon/cocoa), Linux (32/64), Windows (32/64) and all works fine. In wx, we use gui, filesystem, threads, html libs.
+1 for Qt
I have used both wxWidgets and Qt extensively on different projects for the Windows platform writing C++ applications.
Having used both and compared the two after, I would absolutely use Qt over wxWidgets. You need to consider (as some of the others have pointed out) if the re-factoring effort is is something you have time for and are willing to do.
Also consider the cost -- this may not matter in your situation, but unlike wxWidgets, the Qt Library is not free for commercial use. I have spoken to TrollTech at length and read through their licensing agreement to verify this; you definitely have to pay unless you GPL your application.
Regarding licensing see:
http://qt.nokia.com/about/licensing/frequently-asked-questions
"Will you continue to offer Qt under a
commercial license?"
"Yes, absolutely. Our commercial
licensing will continue."
"Why would I want to buy a commercial
license? What is the difference?"
"The commercial Qt license includes
email support, access to upgrades and
allows you to develop fully closed
source software. The LGPL carries some
restrictions regarding the ability for
users to relink libraries and other
restrictions that may impose
architectural requirements that some
organizations might not be comfortable
with."
Qt is definitely worth the money though, even if you are not doing cross-platform development. It has a lot more and better documentation. Qt and wxWidgets are not perfect... The fact that they are bloated and provide APIs for networking, data structures, and database handling is not necessarily a good thing. Sometimes sticking with the STL or Boost libraries (if you're coding in C++) is a much better solution.
Good luck.
-bn
+1 for wxWidgets. A big project of mine used wxWidgets and found it a nice framework to use, and an easy enough framework to get your head around to modify if you need to (to support Mac specific features).
Try it: you could be 80% there when you first generate the binary.