Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
OS X Operating Systems Businesses Programming Apple Technology

Brief Tutorial on Reverse Engineering Mac OS X 121

rjw57 writes "There is an article on OSNews I wrote about how the guy behind Desktop Manager goes about reverse engineering APIs from Mac OS X with a brand new example not revealed anywhere else. From the article: 'I am often asked in email how I uncovered the API calls I use in Desktop Manager which are, unfortunately, undocumented. This article aims to give a little insight into the techniques I use to reverse engineer Mac OS X in order to provide extra functionality to users and extra information to third-party developers. In this article all the utilities I use are a standard part of Mac OS X's developer tools which are freely available.'"
This discussion has been archived. No new comments can be posted.

Brief Tutorial on Reverse Engineering Mac OS X

Comments Filter:
  • Versus Expose? (Score:3, Insightful)

    by Anonymous Coward on Wednesday April 20, 2005 @06:36PM (#12297252)
    All credit to the author; it looks like quite a feat of reverse engineering and some genius coding has probably gone into it. Apologies for the subsequent inflammatory opinion.

    However, Apple have already come up with a perfect way of handling large groups of windows on one screen; it's called expose. I used to use virtual desktops on Linux, which was adequate, but when I got a Mac I settled in nicely with Expose; OS X has a near perfect user interface designed by actual HID experts. The only reason I can think of for using virtual desktops is if you're some kind of Linux zealot.
    (Don't mod me down just because you're an anti-Mac zealot mod ... try having a real discussion instead).
    • Re:Versus Expose? (Score:5, Interesting)

      by avalys ( 221114 ) on Wednesday April 20, 2005 @06:47PM (#12297377)
      If you're working with a lot of windows/applications, virtual desktops can act as a nice complement to Expose.

      I'm surprised Apple hasn't made it a built-in feature. They have fast user switching, but that's not the same thing.
      • If you're working with a lot of windows/applications, virtual desktops can act as a nice complement to Expose.

        I agree; Desktop Manager is a great piece of software - free, reliable, and amazingly small.

      • Re:Versus Expose? (Score:2, Informative)

        by Ucklak ( 755284 )
        I agree but from a management point of view, If you have that many apps open that Expose doesn't give you good idea of what you're working on, you're not efficient and most probably wasting productive time.

        As a user of Linux and Mac, I use both Virt Desktops and Expose (used to use VD on the Mac before 10.3). Not trying to be a flamer here but there is no way one person can be productive with 4x (or even 2x) what Expose handles.

        Expose is good for less than 15 windows on a standard desktop. Those with t
    • by AnEmbodiedMind ( 612071 ) on Wednesday April 20, 2005 @06:47PM (#12297379)
      I myself have found that by really learning how to manage windows the "apple way" I don't really feel the need to use virtual desktops much (I used to use DesktopManager).

      For me, this means using Hide (Command-H), Swich app (Alt-Tab), Focus on window (active) or next window (a custom key binding like Alt-Tab), and Expose.

      But that doesn't mean there isn't a place for virtual desktops.

      One thing that expose relies on is that the conceptual groupings of "All app windows" and "All of this apps windows" are all you need. The problem is if you have a large number of similar looking windows from different applications it can be difficult to manage even with Expose.

      Virtual desktops can give you custom Expose groups - which can narrow the search for a particular window. This can be useful if you are working on several complex tasks that use multiple windows from multiple apps (each task can get its own desktop), and also have a bunch of side apps - like your calendar, email, instant messenger etc.

      So Expose solves the window management problem to an extent, but it can be combined with virtual desktops when things become even more complex.
      • I am totaly with you. When I got my first Mac. The first thing I installed was DM. But it didn't work out. Nowadays I don't need Virtual Desktops anymore.
        As you said, when you use Exposee, Hide, etc. Then you are way more powerful.
        Especially F10 Esposee to show all windows of the current app, are the Virtual Desktop Killer for me. (at least at home)
      • by civilizedINTENSITY ( 45686 ) on Wednesday April 20, 2005 @11:06PM (#12299235)
        I like to dedicate a virtual desktop to each class I'm taking. That way when I want to work I just move to the desktop for that class, and everything I'm working on is open there. I save often, but never actually close a document until its turned in. I use yet another desktop for email, surfing, IRC, etc...
      • Same with me. I don't even use Exposé much, when I want to to get access to the desktop, I simply click on it while holding down OPTION, this'll hide the current application (I rarely have other windows than the current app displayed). It doesn't look as fancy as Expose(r), but it does the job and has done it since ye olde Mac days.

        When I switch apps I usually either do it via CMD+TAB (no hiding) or I click on the dock wile pressing OPTION that way the current app gets hidden. Keeps the screen clean.
    • Re:Versus Expose? (Score:5, Insightful)

      by Digital Pizza ( 855175 ) on Wednesday April 20, 2005 @07:35PM (#12297828)
      Ya know, virtual desktops and Expose aren't really in competition with each other. I'm sure a lot of people get good use out of both, simultaneously.

      I personally don't use multiple desktops, even in Linux, but would never, ever consider taking away that functionality (if I had the power to do so), knowing how useful it is to so many other people. For that reason, I think it'd be a great idea for Apple to add this feature to OSX.

      • I agree that Expose and virtual desktops can work well together. I think it also depends on the environment it's being used in.

        An example of this is at work, I need to have serveral different applications open, each having multiple windows. It works well when I separate them by virtual desktops and then use Expose when I need to find a certain window of that application when I'm on that desktop.

        However, at home, I am not running as many applications so Expose is sufficient enough to sort through the ope
    • Re:Versus Expose? (Score:5, Insightful)

      by burns210 ( 572621 ) <maburns@gmail.com> on Wednesday April 20, 2005 @07:38PM (#12297853) Homepage Journal
      They have done great, exception for the multiple times they break their own HID/HIG. iTunes, for example, and the whole brushed metal is basicly an excuse for making cool-looking apps. I like brushed metal, but apple has changed the HIG to morph around what they think looks best. There really should only be 1 window gui, aqua.

      Mail, in OS X, is even a third window gui(?), it isn't quite Aqua, and has noticable differences unlike any other application on OS X. Why? Who knows.

      Apple has done great, but they have clearly ignored their own UI rules for the sake of eye candy at times.
      • Re:Versus Expose? (Score:3, Insightful)

        by dr.badass ( 25287 )
        Apple has done great, but they have clearly ignored their own UI rules for the sake of eye candy at times.

        HIG stands for Human Interface Guidelines. If they were "rules" they would be stupid, because there are no absolute rules to design, and pretending there are leads to bad designs. Without such guidelines, you'd end up with even worse designs. Look at Open Source GUIs (if you must).

        Really, the HIG should be titled "Interface Design for People That Can't be Trusted to Design Decent Interfaces withou
        • Re:Versus Expose? (Score:3, Insightful)

          by argent ( 18001 )
          Without such guidelines, you'd end up with even worse designs.

          Worse than Metal Finder? It's hard to imagine how they could have done a worse job without risking people storming One Infinite Loop and burning Jobs in effigy.
      • I disagree with you on Mail.app. It's not unlike the earlier Finder iterations or Apple apps, and which a lot of developers copied. Customizable toolbars? A sliding side drawer? Lots of cocoa apps have both.

        • He is talking about the OS X Tiger version of mail.app. http://www.apple.com/macosx/features/mail/
          • The new look is mostly the new combined title bar/toolbar look that is available to apps in Tiger. No doubt it is covered by the Tiger HIG, but as Apple are yet to publish the document we don't know yet.
            • As far as I can tell, Apple changed the system to make it stop drawing the line between title bars and toolbar. Fine, whatever. What I hate about the new Mail.app though are the toolbar icons. They are ugggly. I'm not sure why Apple went with such strange, non-standard, and visually unappealing icons.
      • Re:Versus Expose? (Score:5, Informative)

        by 99BottlesOfBeerInMyF ( 813746 ) on Thursday April 21, 2005 @01:56PM (#12304178)

        iTunes, for example, and the whole brushed metal is basicly an excuse for making cool-looking apps. I like brushed metal, but apple has changed the HIG to morph around what they think looks best. There really should only be 1 window gui, aqua.

        Brushed metal was originally applied to windows that simulated real world devices. iTunes=stereo. DVD Player=TV+DVD player. Later on it was applied to most of the interface and I for one am very glad. It provides better contrast with window contents. Finder windows have a default white background as do many text style documents like PDFs, Word files, etc. Most editors and terminal windows are best with white text on a black background for maximum contrast with minimal eyestrain. This means about half my windows are primarily white and half are primarily black. Now what color is halfway between white and black, does not grab the eye, and does not clash with any other color? Gee that would be only one...gray. Add a little texture and you get the brushed metal look. Apple designers probably realized why people like the brushed metal, but most people just like it because it looks good. It looks good because it is pretty much the best color you can use from a UI design perspective.

      • Guys, it's worse than that: the "Pro" line of Apple Apps, eg Final Cut Pro, Shake, and Soundtrack, etc. have another gui theme (dark grey, and quite appealing, frankly). And GarageBand has an absolutely monstrous ui, totally unique.

        And yes, this is important. If this keeps up, it could get to be like Windows around here in no time.

      • Re:Versus Expose? (Score:3, Interesting)

        by for_usenet ( 550217 )
        I think the reason why Mail.app looks so different is proably because it is one of the truly cross platform mail apps. I remember reading somewhere that Mail.app is one of the few applications that can compile cleanly and with all functionality intact on both OS X and Linux running GNUStep. If that were the case, it might explain the different GUI, as they may have had to make some comprimises to make the application truly cross platform.
        • I think the reason why Mail.app looks so different is proably because it is one of the truly cross platform mail apps. I remember reading somewhere that Mail.app is one of the few applications that can compile cleanly and with all functionality intact on both OS X and Linux running GNUStep. If that were the case, it might explain the different GUI, as they may have had to make some comprimises to make the application truly cross platform.

          Apple Mail isn't open-source, and Mail 2 uses more custom widgetry a

    • Re:Versus Expose? (Score:5, Insightful)

      by drsmithy ( 35869 ) <drsmithy&gmail,com> on Wednesday April 20, 2005 @10:12PM (#12298914)
      However, Apple have already come up with a perfect way of handling large groups of windows on one screen; it's called expose.

      Expose is for switching between windows.

      Virtual desktops are for logically grouping/partitioning windows (more typically, whole applications). Virtual desktops are, basically, a poor man's multi monitor setup.

      The two solve different problems.

      • > Expose is for switching between windows.

        > Virtual desktops are for logically grouping/partitioning windows (more typically, whole applications).
        > Virtual desktops are, basically, a poor man's multi monitor setup.

        > The two solve different problems.

        But when you click on an application's icon in the Dock, it brings all the application's windows to the front. That's pretty much all the 'logical grouping' I need, and if I really need to see just that app, I can command-option-click the icon

        • Grouping windows by application solves a subset of the problem solved by virtual desktops.

          Lets say I'm developing three different projects at once. It would be really nice to show the editor, terminal, preview, etc. for each one quickly. In other words, I want three virtual desktops each with several open windows from a various applications.

          Virtual desktops have their place.
    • Re:Versus Expose? (Score:3, Interesting)

      by steeviant ( 677315 )
      The only reason I can think of for using virtual desktops is if you're some kind of Linux zealot.

      I've been trying to take this line of thinking to it's logical conclusion, but I can't figure it out...

      I always ignore the multiple desktop features and disable the pager in X11 window managers, does that make me a Mac zealot or a Windows zealot?

      Conversely, I know people who religiously use multiple desktops in Windows who won't touch Linux with a 10 ft pole. Are they still a Linux zealot?

      I'm so confused.
    • Re:Versus Expose? (Score:4, Insightful)

      by harlows_monkeys ( 106428 ) on Thursday April 21, 2005 @09:11AM (#12301735) Homepage
      However, Apple have already come up with a perfect way of handling large groups of windows on one screen; it's called expose. I used to use virtual desktops on Linux, which was adequate, but when I got a Mac I settled in nicely with Expose; OS X has a near perfect user interface designed by actual HID experts

      Wrong. Expose is nearly perfect for managing large groups of windows only in the case where you don't have multiple windows from an application being used in separate user tasks.

      For example, suppose you are working on some graphics for your web site. You have a browser window opened on your site for reference, and other browser windows on other sites. You have Photoshop opened with various images being edited, so you have a bunch of Photoshop windows. You've got a mail application opened reading an email thread discussing the web site design.

      Expose is perfect for managing your windows in that situation. All those windows belong to the same logical task ("update web graphics").

      Expose even stays almost perfect if we throw in another logical task, if it doesn't use any of the same apps. For example, if you have a couple terminal windows opened to servers you are remotely admining, things are still fine.

      However, when you get to multiple logical user tasks, with some apps being used for more than one of those, Expose becomes inadequate.

      Consider this situation: you are working on three separate things. For thing A, you are using two terminal windows (say to ssh to two separate servers you admin), one spreadsheet window, and two browser windows.

      For thing B, you are using one terminal window, two spreadsheet windows, and one word processor window.

      For thing C, you are using one spreadsheet window, two word processor windows, and two browser windows.

      Expose doesn't handle this very well at all. When used an all windows, it doesn't work well. Its "all windows" mode has windows from all three of your logical tasks, scattered all around, and it can be hard to tell which window is which (especially for terminals and spreadsheets).

      What you need here is a way to hide or minimize a group of windows based on the user task they are associated with. Apple provides no mechanism for that. They provide a way to hide all the windows of a given app, but in my examples above, each app has windows associated with more than one user task.

      What would be perfect would be Expose with multiple desktops. In my example above, you'd then do task A on one desktop, task B on another desktop, and task C on a third. On each desktop, you'd use Expose to manage the several windows that are on that desktop.

      Basically, Expose, minimizing, and hiding only provide three levels of organization: by individual window, by application, or everything. What's missing is a way to manage all the widows of whatever the user is working on at the moment.

      • (especially for terminals and spreadsheets).

        Well, typically the window title is listed when you mouse over the scaled version. You can set Terminal.app to set the window title to the currently running command including arguments.

        What would be perfect would be Expose with multiple desktops. In my example above, you'd then do task A on one desktop, task B on another desktop, and task C on a third. On each desktop, you'd use Expose to manage the several windows that are on that desktop.

        Nothing stopping y
    • Re:Versus Expose? (Score:4, Interesting)

      by nickos ( 91443 ) on Thursday April 21, 2005 @10:31AM (#12302320)
      "OS X has a near perfect user interface designed by actual HID experts"

      There's no such thing as a perfect user interface. Apple should give users as much flexibility as possible since everyone has different usage styles. There's an interesting article from a frustrated Mac user here [ex-parrot.com] (read the section titled "Switcher Stories").
    • Re:Versus Expose? (Score:3, Insightful)

      by Proteus ( 1926 )

      Expose is probably all one really needs, yes. However,,virtual desktops are nice for development. I find it very convenient to have several documentation and reference windows open on one desktop, the test environment on another, and the actual code view on a third.

      This means that it's much easier for me to quickly switch between, say, documentation and code view, while providing a cleaner workspace for each area. Is it necessity? No. It is, however, my taste. The OSX interface is very nice, and ver

    • Re:Versus Expose? (Score:3, Interesting)

      by GlassHeart ( 579618 )
      Apple have already come up with a perfect way of handling large groups of windows on one screen; it's called expose.

      Apple is composed of some very smart people, but Exposé is not at all the "perfect" way to handle large numbers of Windows. Having a second monitor - which MacOS supports very well - is usually better for users with no space or cost constraints.

    • I like Expose, but what I've been wondering is if there is a way to use expose or even the windowing options of indvidual programs to have all the windows for that one program tiled across the screen? What I mean by this is to tile the windows and keep them that way, not untiling everything when I click on a window.
    • You realize that posting as an AC will cause your post to be deleted when slashdot archives this story?

      So, if someone decides to have a "real discussion" with you, it will only show his side.

      Brilliant.
  • Huh? (Score:5, Funny)

    by RzUpAnmsCwrds ( 262647 ) on Wednesday April 20, 2005 @07:10PM (#12297593)
    So now we find out that Apple has used - and is using - undocumented API calls.

    Sounds like something Microsoft would pull.

    Oh, wait, this is Slashdot. I forgot.

    Well, then Apple's just trying to protect its intellectual property. No harm.
    • Re:Huh? (Score:5, Interesting)

      by the pickle ( 261584 ) on Wednesday April 20, 2005 @07:55PM (#12297985) Homepage
      Or, more likely, Apple hasn't seen fit to document the calls yet. Not to excuse their laziness, but it seems like Apple gets around to documenting things much less quickly than they used to. Frankly, I suspect that even after nearly five years of OS X, they're still playing a bit of catch-up with the documentation.

      p
      • Re:Huh? (Score:1, Informative)

        by Anonymous Coward
        Actually, Apple intentionally reserves APIs that are related to "user experience".

        I doubt they will ever get around to documenting functions related to to switching "workspaces"/desktops unless Apple themselves chooses to ship a desktop switcher. Another example is putting items into the Menu Bar.
        • Re:Huh? (Score:5, Interesting)

          by Trillan ( 597339 ) on Wednesday April 20, 2005 @09:35PM (#12298669) Homepage Journal

          Apple has two methods for putting items in the menu bar: The "right" way to do things, and the way that looks good to users.

          The wrong way to do things -- and the way Apple uses for their menulets -- reserved involves injecting code into SystemUIServer's running space. If one menulet crashes, all menulets crash under this model. It is not surprising they want to discourage this mechanism for end-developer use.

          Personally, I expect that sooner or later Apple will port the features of the "wrong" way to the right way, then upgrade thier menulets to use the documented API instead of the undocumented one. However, I expect there are much higher priorities.

          • Re:Huh? (Score:2, Informative)

            by Rosyna ( 80334 )
            Good point and all. But what's a menulet? Some word you just made up? They're called menu extras.

            Then again, these MAC things weird me out. I need to get a new Apple when MAC announces them.
      • Comment removed (Score:5, Informative)

        by account_deleted ( 4530225 ) on Thursday April 21, 2005 @06:33AM (#12301065)
        Comment removed based on user account deletion
    • So now we find out that Apple has used - and is using - undocumented API calls.

      Um, no Apple has no applications that use the virtual desktop APIs to compete unfairly with third party apps. In fact Apple has no competing application in this area at all, and two of the three applications that DO exist are open source.
    • Re:Huh? (Score:5, Insightful)

      by Midnight Thunder ( 17205 ) * on Thursday April 21, 2005 @04:04AM (#12300711) Homepage Journal
      Although I can't find a reference to the source, I believe Apple already explained the reason there are documented and undocumented APIs ( these are also known as public and private APIs) The reasoning is that any private APIs are not yet set in stone, so if you do use them you should not be surprised that your application breaks with the next point release. These APIs are undocumented, but not hidden. If you wish to create programs that are stable between releases, then you should only use public APIs. The choice is yours.

      Remember there is a difference between hidden APIs and undocumented APIs. Are all the APIs in Linux documented?
    • Re:Huh? (Score:1, Funny)

      by Anonymous Coward

      I thought the big stink with Microsoft was that many OS services had 2 APIs, one they gave to third party developers, and one they used internally. One of them was tuned to run slower than the other... I just can't seem to remember right now which was which.

      :^P

  • truss for MacOS X? (Score:4, Interesting)

    by mzs ( 595629 ) on Wednesday April 20, 2005 @08:46PM (#12298358)
    On Solaris there is a command truss that is the king of all truss-like commands. Unlike strace, ktrace, and BSD truss this tool can print a trace of all function calls made by an application as it runs (among many other useful things). Does anyone here know of an analogous tool for MacOS X? If not I wonder if an awk/perl script munging the output of nm to generate tracepoints for gdb where each trace point creates a new tracepoint at the instruction where the function call returns, prints out the funtion name and the contents of r2-r10 or so, then continues on or something like this would be something someone has already written.
    • by Anonymous Coward
      You can sort of hack together that functionality using two windows. ex:

      (first window) ktrace -f less.ktrace less foo.txt

      (second window) kdump -l -f less.ktrace

      Only thing is that you have to run the first one first - if you run kdump first, then start ktracing the comand, ktrace will respect kdump's read lock on the file, and you won't see anything. Which means that there's that little time at the start, during which you're not seeing "live" syscalls, but catching up to the backlog...
      • Right I know that but I was not after tracing syscalls but rather tracing function calls. Do a man truss on solaris sometime too see what I mean about all the features that are missing from ktrace.
    • I just looked and there are some tools in Developer -> Applications -> Performance Tools that may be what I would like to use. In particular Shark and Sampler look promising. I wish there was a simple command line program that worked similarly.
    • It sounds like you are describing 'ltrace'. I don't know if it has been ported to Mac OS X though.
  • by sootman ( 158191 ) on Wednesday April 20, 2005 @11:03PM (#12299222) Homepage Journal
    ...what I really want is to be able to hit (for example) control-alt-F1 and get a full-screen command line. Every so often I've got a lot of crap open and I just want nothing but a big, empty, command window.
  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Thursday April 21, 2005 @06:44AM (#12301103)
    Comment removed based on user account deletion
    • This is wonderful advice for people who are only going to play in the little sandbox O/S developers give them. I like those people. I think everyone should go be one of those people.

      Why? Because the people who actually understand systems, who are capable of reverse-engineering the O/S to get at the functionality they want, who write software that does new and amazing things... those people are my competition.

      And while I believe competition is good for innovation, I also understand that a LACK of competiti
      • Any company could walk in and plug a newsreader onto Outlook, and if they do it well I'll bet that company will make a boatload of cash.

        Why would anyone pay for a newsreader when Google Groups exists? I can't even imagine someone trying to set up a local NNTP server for anything.
        • Why would anyone pay for a newsreader when Google Groups exists?

          Um, because Google could arbitrarily change Google Groups at any moment and remove features that you depend on?

          Oh, wait, Doctor Evil, that already happened.

          (yes, it's their code, their hardware, they have a right to do it, the point is they can and do, and that's one good reason to do Usenet yourself instead of depending on the kindness of strangers)
      • Comment removed (Score:4, Insightful)

        by account_deleted ( 4530225 ) on Thursday April 21, 2005 @05:41PM (#12307216)
        Comment removed based on user account deletion
        • People who push the envelope aren't readily supported by public APIs, because those APIs leave a substantial margin to prevent inexperienced developers from falling over the edge. Innovators who set out to achieve the truly briliant are all the way at the edge, looking over and getting ready to jump.

          Everything's relative. If you don't think it's small, maybe you're just not all that big. There's a lot of room to play in the OS X sandbox at first, but anyone worth his salt is constantly growing -- and will
          • by Anonymous Coward
            Big talk from someone we've never heard of.

            The mac development community is small. We tend to notice who the major players are. You sir, are not one of those players.

            Please take your, "l337er than thou" attitude back to your high school computer lab. You'll impress your peers with that kind of talk, but to pull it off here you'd better start naming programs that shock and delight.

            "maybe your'e just not all that big" indeed. What trash. Sure, lots of cool programs are out that use undocumented APIs. But a
            • > The mac development community is small.
              > We tend to notice who the major players
              > are. You sir, are not one of those players.

              That's true. I'm a Windows guy. But the statement holds: if you're pushing the envelope, the documented API doesn't always reach where you need to go. I would expect it's the same for Macs; it used to be.
              • Oh. I see.

                So what you're doing it coming from a Windows perspective and trying to make intelligent and topical assertions about the mac development platform.

                This is a mistake. Disabuse yourself of such notions. They will get you nowhere. Apple has a very different policy towards its developers. They give as much power as they can do their developers, and the tools are so good that often applications do not need to go outside the standard APIs.

                You might not believe me, because of the perspective you br

                • > So what you're doing it coming
                  > from a Windows perspective and
                  > trying to make intelligent and
                  > topical assertions about the mac
                  > development platform.

                  Is this not a platform-independent question? Every O/S has undocumented APIs. They're undocumented for a reason, often because there are strange subtleties to their operation that are hard to understand. But they *exist* because someone needed to do something that they *couldn't* do under the documented API. Is the Mac somehow different? Why
                  • Is this not a platform-independent question?

                    No, because of how the companies handle it. MS will actively move to block you from using these APIs. I worked in a shop where I saw it done. They changed it on us by reversing the order of all parameters. That's adding insult to injury.

                    Every O/S has undocumented APIs.

                    Also untrue.

                    They're undocumented for a reason, often because there are strange subtleties to their operation that are hard to understand.

                    Or are not done yet. Or didn't make it into

                    • > They changed it on us by reversing
                      > the order of all parameters. That's
                      > adding insult to injury.

                      IIRC, I had this problem with VB routines: VB passed and handled parameters in the opposite order, so if a VB routine was rewritten in C++ (or vice-versa, if you were crazy) the parameter order would reverse. I also seem to recall Microsoft eventually bowed down to the de facto standard and changed VB to handle parameters in the same order as most other languages.

                      So I wouldn't attribute this to any
              • Comment removed based on user account deletion
          • Comment removed based on user account deletion
            • > The difference is, if he's sticking to
              > supported API, help is available.

              Why, yes, that WOULD be the difference between "supported" and "unsupported". Why didn't *I* think of that? It's so... obvious.

              > I see some truly brilliant work on a
              > daily basis, from developers who are
              > sticking to published API

              I'm not saying you can't be truly brilliant *unless* you use undocumented APIs; brilliance can be achieved with any tools you have. I'm just saying that *sometimes* the documented and suppo
          • Dud, if you're all raring to go out and start innovating all over Mac OS X, how about filling in some of the missing tools that can be done using supported APIs?
  • by solios ( 53048 ) on Thursday April 21, 2005 @12:27PM (#12303387) Homepage
    I needed more workspace, so I went multihead. Some apps lend themselves well to virts - web browsing, email, a pile of xterms... but when you're running something like photoshop and you need more "room to maneuver". adding extra heads is the way to go.

    I seem to be the only OS X user that neither uses no likes Expose much. Part of it's the fact that a few apps I use bind to F11-13, though my BIG gripe is that F14-F16 ARE NOT MAPPING OPTIONS. Why can't I put the shortcuts for Expose onto the three keys that I NEVER use for ANYTHING? :-(

    That aside, I've noticed that virts are something the "I used to use freenix but the desktop sucks so I switched" crowd complains about, as well as sloppy focus and the fact that portables have one button trackpads (something of an annoyance if you're using X11 applications). As a whole, the freenix imports seem to be so used to doing things Their Way that the mere notion of a UNIX not having $feature makes them positively apoplectic. :-|
    • Can't you map F14-F16 to mouse buttons 4, 5, and 6, and then just set expose to use those mouse buttons?
    • The best way to use Expose isn't with function keys but with buttons 3 and 4 on multibutton mice like Microsoft's. It really makes things a breeze. Especially drag and drop. I find the function keys much less fluid - sort of like using the keyboard equivalent for the second mouse button in OSX.
    • My girlfriend used to use Linux before she got an iBook for school, and the only thing she misses from Linux is virtual desktops. It was one of those things she just got used to using over the course of her Linux experiment.
    • Why can't I put the shortcuts for Expose onto the three keys that I NEVER use for ANYTHING? :-(

      What I want to know is why Apple hasn't put a general purpose input or hotkey manager in Preferences that would let you map any key combo to any hotkey-using application.

      Plus, every second keyboard these days has half a dozen extra "Multimedia" or "Internet" buttons. Why can't I map those to actions?
      • I'm with you on that. It can't be THAT hard for the OS to scan a keyboard, notice extra non-Standard (all the normal QUERTY bits that are SUPPOSED to be there) keys and offer them up for remapping.

        I have a Sun Ray USB board I'd LOVE to use with OS X - while it recognizes all of the keys that it should properly, there's the slight matter of the extra rows off to the left, the blank key, and other bits - there are keys on that board that the OS doesn't SEE that, if it was all HEY BUTTONS WHADDAYAWANNADOWITH
        • I'm with you on that. It can't be THAT hard for the OS to scan a keyboard, notice extra non-Standard (all the normal QUERTY bits that are SUPPOSED to be there) keys and offer them up for remapping.

          Well, the problem is that the extra keys on a USB keyboard aren't keys,they're system control endpoints. But, yes, there are standards for all of them and they all have descriptors that describe them. It should still be able to put up a list of system control buttons and let me assign events to them.

          And what I'
  • Undocumented because they are not "public" apis, and not guaranteed to be supported in the next release of OSX. As long as that part is clear, go ahead.

    But please, let's not complain about apple not documenting function calls.. apple is very clear about which APIs are official and supported.

"If it ain't broke, don't fix it." - Bert Lantz

Working...