I am wondering what technologies are used by the new Mac OS AirDrop and if there is a way to use it on windows.
You know that AirDrop is a feature that will be introduced as part of Mac OS X Lion (version 10.7), right? That version of the OS is not even out yet, and it won't be until later this summer.
Furthermore, I assume that the handful of lucky developers who have a pre-release copy are under a strict non-disclosure agreement (this is Apple, and that's pretty standard policy in the industry anyway), which would keep them from giving any details about the feature in a public forum such as this one.
But, since I am not one of those lucky developers, I suppose I'm free to do a little speculating about how it might work. Presumably, it takes advantage of Apple's existing Bonjour network service discovery protocol (formerly known as Rendezvous) to locate other users nearby whose devices support AirDrop. The rest of the pieces have been part of Mac OS X for years, they just haven't been wrapped up in a fancy, easy to use interface (really, that's about all that software development is about nowadays). There's always been rich support for peer-to-peer networking, you've always been able to share files with other users, users have always had a public folder, etc. (This is UNIX we're talking about, after all.)
Will it work on Windows? Maybe. Apple has been surprisingly good in recent history about including its Windows brethren in on the fun—iTunes, Safari, MobileMe, etc. But it doesn't always happen right away. Rolling your own solution for Windows (or any other platform) would be pretty simple, but there's no guarantee that it will be compatible with Apple's.
Bonjour happens at layer 3, so it may be a small part of it.
The real question is how does AirDrop work at layer 2.
Airdrop was reverse-engineerd by the https://owlink.org/ folks. They implemented a free Python version called opendrop as well. The implementation is (unsurprisingly) quite hairy as you need to setup a special Wi-Fi link alongside some bluetooth voodoo, but it apparently works. Or at least it works better than whatever we had before, which was those few question around SE:
Implementing the AirDrop protocol
Is it possible to listen on the Airdrop protocol with my Ubuntu machine?
Related
I'm a Windows (native, not .NET) programmer and I'd like to port an application to the Mac.
Actually, I believe it will be more of a rewrite, as the original depends on many activex controls.
As I have never used a Mac in my entire life, I'll need some guidance. O:-)
a) What book(s) would you recommend to make the move from Win32 to Mac OS?
b) Is there anything similar to Delphi (RAD) for the Mac?
c) Can anyone recommend (or not) Lispworks (www.lispworks.com)?
d) Is there anything similar to the Windows market of 3rd party COM components (so I don't have to write everything)?
e) Anything else I should be aware of the Mac market?
f) Oh, BTW, what Mac should I buy? O:-) (must be a laptop)
Thanks in advance
I've taught Cocoa programming to several Windows-experienced programmers. You may find a previous post on the subject useful.
Cocoa is a very different way of thinking then MFC and its kin. You will do much, much better if you take the time to learn how Cocoa approaches things and adapt to its mindset rather than trying to find the quickest way to implement your current way of thinking in ObjC. It is possible to write MFC-style code for Mac, but you will always be fighting the framework if you do. I've seen a lot of Windows developers struggle with this.
The best book to learn Cocoa is Cocoa Programming for Mac OS X. Assuming you are a C++ developer with a solid OOP background, this is the book to start with. If you have limited Object Oriented background, then start with Programming Objective-C 2.0.
You would be amazed how fast Objective-C can be to code once you understand the patterns. It really can be stunning compared to C++ in my experience. There are more RAD-like systems like REALbasic, and you can develop Cocoa apps in Ruby now which can be a bit quicker. But there really is no substitute in the Mac market for ObjC. It's hard to make an app that works like a Mac app without using the Mac frameworks, and Mac users tend to be much fussier about such things than Windows users.
I have no background in LispWorks, but LISP seems a terrible language for developing the kind of rich UIs that Mac apps are known for. I like LISP (quite a lot actually), but Functional Programming's "no side effects" philosophy seems at odds with most rich UI goals (especially as the Mac UI becomes more and more animation-centric). If anything, Mac programming is moving towards Declarative rather than Functional programming (Core Animation and Grand Central Dispatch have a lot of Declarative concepts creeping in).
There is not as large a third-party component market as there is for Windows. Some of this is because Cocoa already provides such a rich set of components, which MFC does not, and because well-behaved Mac apps are expected to use those components so that you work like all other Mac apps. There is definitely little market for commercial components in the vein of RadControls for .NET (very nice toolkit, that one). But there are quite a few nice free components out there with flexible licenses (generally MIT-based). A few of my favorites:
Positive Spin Media's excellent tabbar control
OmniGroup's frameworks (though I never use them "as is;" they're better used as examples of how to do things)
Growl
Sparkle
RegexKit
CocoaDev's ObjectLibrary list of other stuff
As I mentioned before, Mac users are picky about their UI. Much, much more so than Windows users. They expect things to be polished, and they expect things to integrate with all the little things that make Macs nice. That means drag-and-drop, Spotlight, services, Applescript, Expose, QuickLook, integrated spelling check, etc. etc. It's very hard to do all these things right if you don't use the built-in frameworks. That's why I recommend new Mac developers start at the beginning and learn the frameworks.
For a Mac, if you have a bunch of hardware lying around (like keyboards and monitors), then a Mac Mini is a nice cheap box. iMacs are great if you want an all-in-one, and any MacBook is appropriate if you like portability. There is no Mac on the market today that is not a perfectly fine development box. Obviously if you do a lot of work, an 8-core Mac Pro makes compiling much faster, but I've done a lot of professional development on a 13" MacBook. If you want to get in as cheaply as possible, look for refurbished or used (I love my refurbished Mac Mini). Any Intel-based Mac is going to be fine for development, at least while you're getting started.
If you are familiar with C, you may want to learn Objective C since that is the Macs "native" programming language. It's also what you have to use to write iPhone applications. Cocoa is Apple's primary API that will have a lot of the tools you are looking for.
a) Read this thread for book recommendations: https://stackoverflow.com/questions/7571/cocoa-and-objective-c-resources
b) Apple makes Xcode for developing in. There are certainly better ones out there, but it's not bad.
d) Cocoa is Apple's main API, which provides "core" services like CFNetwork for networking. There is also core data, core audio, core animation, core image, core location,... Underneath it all, OSX is Unix, so you have access to many unix/linux libs.
e) The iPhone is a big part of the Mac market. The iPhone and OSX development environments are not that different, so you can learn both.
f) Any Mac is sufficient for most development. If you want a laptop, it's really a question of screen size and price. But I would recommend at least a 15 inch screen. You don't need to spend extra for a faster CPU, but you may want to get a larger hard drive.
If you've done your native Windows programming in C and/or C++, you may have an easier time migrating your application to C#/.Net, and then running it in Mac using Mono. At least some of the available third-party .Net components will run on Mono (see http://www.mono-project.com/Third_Party_Controls_Status).
I have no idea what Mac you should buy - I recommend getting one of the pretty ones.
a) ...
b) You could use Python coupled with wxPython and be cross platform. Python is included by default with Mac OS X.
c) ...
d) I'm sure there is, but I can't tell you more. If you use Python, you get tons of third party libraries for free.
e) They don't take kindly alien GUI guidelines:
Word 6.0, launched in 1993, is widely considered to be the worst version of Word ever for the Mac, as it was based on the same codebase as Word 6.0 for Windows. That meant that it looked and worked more like Windows software than a Macintosh program. Mac users were so up in arms that Microsoft actually released a Word 5.1 downgrade to unhappy Word 6.0 owners.
f) Mostly any iMac will be good enough for programming. Choose the one that you like the most and has lots of RAM.
e) Its a small market.
f) An iMac. Edit: since it says laptop - Macbook Pro 13 is a great deal.
Well, simple situation. I happen to be a software engineer who uses mostly Delphi and C# for software development. Delphi is great for desktop applications while C# is ideal combined with ASP.NET for web applications. However, I am considering to teach myself more about software development for the Mac. Xcode and Cocoa would be the environments to start with. Learning new languages is no problem for me!
However, before starting to write code on a Mac, I first need to buy one and they're reasonable expensive so buying one is a decision that will take me a few months before I know which one I need. So, to help me right now, I would like to know the possibilities that I have to learn more about Mac development without the need for a Mac!
For example, does OS X work in a VMWare environment? Are the development tools also available for Windows? Is there a clear API overview of the OS X libraries?
Or should I first buy a Mac, play with it for a few weeks and then decide on how to develop software for it? In other words, should I start spending now, or in a few months? :-)
Perhaps a macmini would be the best bet but failing that:
MacOSX in VMWare: http://wiki.osx86project.org/wiki/index.php/Vmware_how_to
Development tools for windows? I'd stick to XCode as it can compile multi-binary apps.
Here's the clearest overview I can think of: http://developer.apple.com/referencelibrary/MacOSX/index.html
Hope this helps!
Mac OS X works in a VMWare...
Unfortunately XCode works only on Mac OS...
There are versions of Max OS, which runs on x86 machines. You can avoid buying a Mac PC, but you have to pay for the OS and XCode...
EDIT: Xcode is free
You definitely want a Mac if you want to develop for the Mac. Even Java requires local testing.
That said, Macs are not very expensive and run Windows too.
If you want to learn and start programming before you have a Mac, I recommend either Java or .NET, specifically Delphi Prism.
See here my own first experiment with Delphi prism:
http://leaukiprog.blogspot.com/2009/07/delphi-prism-first-experiment.html
You can write a program for Windows, keep GUI code and other code separate and later replace the Winforms GUI with a native Cocoa GUI on the Mac.
I found that Pascal is a good language for accessing native APIs from .NET. Everything looks cleaner than with C#, I think.
The new version of Delphi Prism is coming out on the 25th, as far as I know.
You might also look into the GNUstep project. This will let you experience objective-c a little bit before you make the plunge, albeit with the GNU libs instead of cocoa.
Good Mac (or iPhone) software is an artisan product; it reflects the culture and tastes of Mac (or iPhone) users. Because the Mac is a premium platform, users tend to be more sensitive to the feel and polish of the apps. Thus to successfully program for the Mac/iPhone or even grok the Cocoa frameworks properly, you have to grok the Mac user experience. Although many coming from the Windows or other-UNIX world try to skip this step, they do so at their own peril.
So, as a Mac developer (who also writes for other UNIX OSes), my recommendation is buy a Mac and start using it, full time if you can. A Mac Mini is completely adequate for development and will set you back only a few hundered dollars, including the OS. Consider that on Windows, this is often less than the price of a full VS license. Everything else (Xcode, libraries, etc.) are free.
Once you have a Mac and begin to grok the feel of things, you'll discover that there are a number of development options. Besides the Cocoa frameworks--which can be used from Python (via the built-in PyObjC bridge), Ruby (via MacRuby or RubyCocoa)—-there are a number of other options. Qt from Nokia and Mono are viable. Often cross-platform apps written in Qt or Mono are disliked on the Mac because they don't feel "native" (see above), but really the problem is not the framework. If you get the Mac user experience you can write a very passable Mac app in a cross platform framework. You just have to intend to write a Mac app, not get a Windows app working on the Mac.
If you code in RealBasic or Lazarus, you can run and compile your apps for both Mac OS and Windows (and Linux in the case of Lazarus). RealBasic isn't that popular outside of the Mac Platform, and isn't free. Lazarus is still a little rough around the edges, but is basically a free version of Delphi.
Lazarus is working hard on a native COCOA port with the next major version of FPC (though that will probably be available only in 2011)
Macs use Objective C. The APIs are very useful and there are many tutorials online. You'll be using Xcode, the Mac equivalent to Windows' Visual Studio and Linux's Glade.
I love making cross-platform applications. In a few hours I can prototype an application in Mac and publish it online. Then it'll take a day or two to port to Windows.
A Mac looks expensive, but it's not if you look what you get for your money.
It is entierly up to you if you buy one or not. I guarantee you'll have a lot fun with it, next to programming. If you want a cheap Mac, just buy a Mac Mini for 500 dollars, which you can connect to the Display you already own.
I recommend doing this on Mac OS X rather than Windows, but again: it's up to you.
P.S. You can use VMWare, but I think it's slow if you have less then 4 GB RAM.
A Mac really isn't that expensive if you go down the second hand route, I was put off by the price of brand new Macbooks so I got a late 2007 model for £350 and added an extra gig of RAM to it.
Reasonably priced, less hassle for development as well!
If you want to have just a general feeling about ObjC and the object libraries, why not giving a try to GNUStep?
Take a look at it here:
http://wiki.gnustep.org/index.php/Main_Page
I'm looking at options to access DVB data on OS X. Initially I want to support the EyeTV DTT USB device, but in the long-run I'd like to support a number of popular devices. The problem I have is that there is no standard way of controlling such devices.
All the applications I know of that use them either hide the driver code within the application (for example EyeTV itself, all it's drivers are implemented totally in userspace and are not accessible to external apps), or they use the seemingly defunkt MMInputFamily driver (no source code availible any more, author gone walkabouts).
I've done some research and found that a number of the devices I want to support are supported within the Linux DVB project. Further research indicates that some years ago there was an attempt to abstract the linux implementation so that it could potentially be recompiled on other platforms. The idea being that efforts to support devices should be pooled and the best way to do that would be to make the current open source implementation work on multiple platforms: it seems in the end to have amounted to little however.
The idea of compiling linux drivers against other *nix type platforms has also been taken up elsewhere with some success. The approach the author took is detailed on the page I linked, it seems potentially viable on OS X as well.
At any rate, there seem to be a number of options, but no clear winner:
Find the source code for the MMInputFamily driver, try to get it working on OS X 10.6 and add support for the devices I require, referrencing the linux source code for pointers. Problem: the source code is nowhere to be found, nor is the author. Additionally it seems the author might perhaps have gone down another route had he fully appreciated the previous efforts to port the linux drivers to OS X.
Attempt to port the linux drivers to OS X in a manner similar to the FreeBSD project I linked. Problem: this is very low-level work and work in this layer is not recommended by Apple if it can be avoided.
Write a driver with OS X's IOKit: this is the preferred method for implementing drivers but I would have to do everything from scratch, clearly not a small job.
If I could I would really like to use the Linux source code, but I'm unsure if such a thing is really viable. Does anyone have any advice or ideas on the best way to proceed with this task?
I've been using MacBook Pro for a few months at home, and I was wondering if there's a good book or guide that can help me be a better programmer on Mac. Maybe Mac-equivalent of Beginning Linux Programming. Note I am not looking for resource on how to program Mac application, instead I am looking for more general guide of using Mac for general development environment.
As a background, I am a Windows programmer by day. I've also done some Linux and BSD over the years, esp in school, like socket programming, graphics, make install type stuff. At home, I'll be doing Java, Scala, PHP, etc. on Mac.
So far, I've been using Eclipse, QuickSilver, and TextMate. VMWare Fusion, XCode and NetBeans are set up, but I don't use them. A DVI KVM switch is hooked up to real keyboard, trackball, and monitor. Recently stayed up till late fighting with MacPorts, and figured out I needed x86_64. The most struggle I had was configuring PHP. I don't know why they don't ship with MySQL and GD library. I eventually figured it out Googling around, and built the extensions from source. I have a feeling that I didn't get the memo and didn't read some basic guide on how to become a programmer on Mac, like how the whole architecture works. How can a Windows programmer be sufficiently productive on Mac OS X?
Related: Setting up a Mac for programmers
Edit: The specific type of application I want to develop doesn't really matter in my opinion. It could be Java, Scala, PHP as I mentioned or Cocoa, C++, or whatever.
What I am looking for is specific book, resource, advice on how to be more effective programmer on Mac, preferably something beyond "install XYZ".
Having converted from Windows to Mac OS X about five years ago, I often find myself thinking the same thing. I just cannot be productive on Windows (as much, I can be productive) as I can on Mac OS X.
To be honest, there are lots of small differences between Mac OS X and Windows. I find the biggest reason for people thinking like this (at it normally only applies to gamers and developers) is that they are trying to use the Mac like a Windows machine. You need to learn to accept that you have to use the command key, not the control key, etc.
It sounds like you are using a Mac because you have to as opposed to because you want to. It really is a much better platform than Windows once you get used to it.
I think a lot of Windows programmers come to Mac and don't try to learn it properly because they are complacent thinking they know it all because they have "used Windows all their life". I guess once you discover Spotlight, Expose, Mac OS X Keyboard shortcuts, etc. You will find your self being MUCH more productive that you ever were on Windows.... and its actually a fun OS to use.
Checkout some of the best Mac applications you can get here and here. You can also do a search for "top 100 mac apps".
Also, I noticed you were trying to setup some kind of web server directly into Mac OS X. It does ship with one, but if you are going to add MySQL and some other extensions I wouldn't go the MacPorts route. Get VMWare Fusion or VirtualBox (open source) and run the server in a VM. Much cleaner. I have a subversion/trac FreeBSD VM that handles my local version control.
I would like to add that if you don't presently use Xcode, you should definitely learn it and use it asap. It's a much nicer IDE to use than Visual Studio and it will make your life much easier.
Don't forget you have probably spent years on Windows help sites, you're going to a small degree need to do that with the Mac. Whenever you have a problem about using the Mac, ask a question on ServerFault. We are all more than eager to help you out.
Good luck.
You seem to want an overview of how Mac OS X works at a system level, more than recomenations about tools and so forth. If that's the case, I'd start with the (very basic) Mac OS X System Architecture Guide from Apple, then move on to Getting Started with Mac OS X, which should give you enough of an overview to get started.
It's not clear from your question what you intend to actually make with your programming time, but if you decide to persue Cocoa/OS X development, I recommend Cocoa Programming for Mac OS X by Aaron Hillegass.
I have a similar situation like yours. I use Windows for development and about a year back purchased a MBP for home (as I shifted to an office). I find it really difficult to get any real work done on my MBP. Somehow am used to the Windows environment with dual screens. But let that not stop you. A couple of software which I suggest you should get are:
Transmit - Good ftp client
MAMP - Runs a webserver nearly out-of-the-box. Good for basic development
Quicksilver - Helps in quick finding of applications
Spaces along with gestures (Configure your gestures to move from one screen to another, I use three fingers glide. its amazing)
Entourage - for email
Terminal - for ssh (putty alternative) (included)
Dreamweaver/BBedit/Textmate (all pretty decent. but i love editplus on windows. not a fan of IDE)
I assume your question is not about learning COCOA and more about being more effective using a MAC. Well, the above tools might help you.
Unfortunately, your question isn't very clear as to what you really want.
If you're looking to write anything cross-platform, it can be very helpful to have a virtual machine for testing. When in Linux, I've always used VirtualBox, and it works on OS X as well.
Also, as for choice of IDE, a lot of it comes down to your preference. Eclipse is nice because there's a plugin for almost everything for it. My experience with TextMate is limited, but my local Ruby Users Group swears by it.
Finally, a suggestion for not just Mac, but any platform really. Learn your hotkeys, set up new ones for things you commonly do, and use them frequently. Not having to take your hands off the keyboard to click a mouse through a few menus can really improve productivity. It may take a little time for them to grow on you, but once they become second nature, you'll wonder how you lived without them.
Basically, you can apply all your Linux/UNIX knowledge that you already have to the Mac. If you use the Terminal (/Applications/Utilities/Terminal.app) you can run all your favorite UNIX commands. Mac has a special command called "open" which is equivalent to the Windows "start" command (used to launch programs and files). You can also use "open -a" to open an application by name (e.g. "open -a Finder").
You might want to reconsider Xcode. Xcode opens more quickly than Eclipse and provides very good syntax highlighting, brace matching, block indenting, and more. Xcode doesn't have to be used as an IDE, you can also use it as a code editor, just like you are currently using TextMate.
For code editing (and everything else), try Aquamacs (http://www.aquamacs.org). It's a Cocoa-native build of Emacs, and it's brilliant for any programming task.
My company is in the process of rewriting our software from scratch, and I'm the one who is going to be doing most of the work in rewriting the Mac client (The core of our software is Windows based, and the Mac client communicates with it through a webservice).
This isn't a real heavy app, mainly does some background work tracking stuff and a UI component for the user to enter information.
I'm trying to decide how hard I should argue for dropping support for 10.4 and going with pure 10.5+/Obj-C 2.0 code.
My main motivations for this are:
It would be easier to code, I could use all the features of Obj-C 2.0 such as synthesized properties and fast enumeration.
It would give me access to several classes, and methods in existing classes, that don't exist in 10.4 (Just in mocking up a UI I've come across NSPathControl and NSTreeNode, both of which I would otherwise be very happy to use.
Preparing for the conversion to 64 bit coming in Snow Leopard. It seems like most of the techniques for preparing for the move to 64 bit (NSInteger, etc) are only available in 10.5+, and it would not be possible to use these if writing for 10.4.
The downside would of course be that we'd no longer be supporting an operating system that was only a year out of date.
My boss is himself supportive of this move, but of course has our customers to consider and doesn't want to cause any more issues for them than are justified. The director of support would like to support 10.4. I suspect the other execs will be marginally against it at first, just due to the not being able to support some customers thing. Everybody would be open to persuasion by a good argument from either side.
I'm trying to talk to some of the support people and get an idea of how many of our customers are actually still using 10.4, but I don't have that data yet.
Some kind of hybrid solution might be possible, such as rewriting parts of the old client to use the new webservice, or writing the client in 10.5 and backporting it to 10.4 if enough people made a fuss, but quite frankly those sound like they're likely to be even more trouble than giving up the 10.5 features and writing the code in 10.4 to begin with.
So I guess my questions are as follows:
Given the information above, do you think making a case for the adoption of 10.5+ only is the right thing to do? Do you have any suggestions as to how this might be presented positively to the rest of the company?
I don't know as much about the coming 64 bit transition as I'd like. Does anybody have any good references on what will be different, and do you think that supporting only 10.5+ would make this transition easier for us?
If it were I doing the update, I would target 10.5, especially since 10.6 is just around the corner and 10.5 did come out with a lot of great, new things (especially Objective-c 2.0). However, I think you really need to answer this question based on what you think your target customer group will be using. If they are slow to adopt new technology, it may be that you have to support 10.4 or risk losing a portion of your customer base.
On the other hand, you can actually target 10.4 and write using the 10.5 SDK. That way you can take advantage of all the preparations for 64-bit added to the SDK. You just have to ensure that you don't use any classes or features of the frameworks that didn't exist in 10.4. You can also do weak linking to the 10.5 frameworks and programatically decide whether you can use a new feature or not (while this is a bit of extra work up front, you can easily phase 10.4 support out of your code in the future and take full advantage of 10.5 improvements for users that actually are running 10.5).
There are a lot of blogs and write-ups about doing the cross-platform stuff out on the web. The other thing to keep in mind is that if you do target 10.4 make sure you have a 10.4 machine available to do a lot of testing (especially if you compile from the 10.5 SDK to take advantage of the 64-bit ready features). Also check the docks for any feature you may want to use from the 10.5 SDK. Many features were actually available in 10.4 but undocumented and the new documentation usually states which features you can safely use when deploying to 10.4
Do you need 64-bit? Unless your application is very CPU-intensive, it won't make any difference.
Tiger can run 64-bit applications, but without GUI. If you need 64-bit, you can create 64-bit CLI executable that does heavy lifting and provide 32-bit font-end for it (using NSTask and NSPipe).
You can also have separate .nib files for Leopard and Tiger:
-(id)init
{
BOOL tiger = floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_4;
NSString nibname = (tiger ? #"WindowTiger" : #"WindowLeopard");
if (self = [super initWithWindowNibName:nibname])
…
You really need to find out what your customers are using, and the support person is probably best positioned to know, or the product manager. That said there's nothing wrong with making the technical arguments clear now even if 90%+ of your user base were pre-Leopard; that way the issues will be known (and hopefully understood) so you'll have more support as the environment does change.
I never wrote production code in Objective-C and its hard to keep up, but as far as i am aware NSInteger and friends are in 10.4, it's just that Cocoa isn't 64 bit in 10.4 whereas in 10.5 most of it is (so no more need for seperate 64bit worker process under a 32bit UI).
I don't know what your product is, or who your customers are, but from my experience, Mac users are early adopters (relatively speaking) I've never used an OS X version longer than two weeks before the next upgrade was out, and in my circle I am a late adopter. Ofcourse I'm not just a business Mac user and that may well make a big difference.
What makes 64bits a requirement in your code? There's not much of a reason to not compile a universal binary holding as many architectures as you wish you could have one binary run on G4, G5, IA32 and IA64 no problem, and have it be native on all of them. If you're just doing 64bits because you can there's no reason (that I can imagine) not to keep supporting 32bits, but if you want stuff like CoreAnimation you don't have much choice.
I don't think it's wrong to demand 10.5 for new development, but it wouldn't make much business sense to force a whole new OS on customers just to keep using your existing product. So if you can, stay compatible, maybe backport your new features/patches for a time. There is a good reason for forking in version control and this might be it.
edit-
Since I posted this I learned that I was wrong and NSInteger did not exist before 10.5. I think I assumed too much having used similar types (like NSDecimal) earlier.