TweetFollow Us on Twitter

Porting Code to the BeOS

Volume Number: 13 (1997)
Issue Number: 1
Column Tag: Betech™

Porting Code to the BeOS

By Michael Rutman, independent consultant

A look at how developing for the BeOS differs from other platforms

The BeBox and the Macintosh Developer

I was curious what would happen if a BeBox was dropped on my desk and I was told, "This is the platform we want all our software running on - make it so." As a Macintosh developer, would this be the end of the world as I know it, or would it be a smooth transition as enjoyable as MacOS 8.0 was expected to be?

Despite my love for Macintosh, there is tons of free software for Unix and dos that I would love to port to Macintosh, but porting Unix software to Macintosh has always been difficult. Each time I tried it was very painful. The BeOS claim to support Unix software was intriguing, so I decided I would port some Unix code as well as Macintosh code to the BeOS.

I've had the BeBox for a week now, and I have had a good time with it. Playing with it has made me think a lot about the BeOS and how it would fit into a Macintosh developers' life. The Macintosh user experience, especially for developers, has always been important. This article describes my experiences setting up the BeBox, porting Unix code, and the steps I would need to take to port Macintosh code.

Getting Started

Be gave me a BeBox all ready to go. All I needed to do was plug it in and start porting code to it. However, setting it up proved to be an interesting experience. The BeBox has 24 ports on the back, not including the 3 on cards, and none of them are labeled. Normally, I can guess a port by the number of pins, but the BeBox supports every port I can think of, and some that I have never heard of before, and several of them look identical.

There is a nice diagram in the User Manual to identify each port; I recommend you make sure you never lose the User Manual. Once you have the diagram, hooking up the BeBox is just plug and play. In fact, the manual says that the BeBox will automatically detect such things as the mouse plugged into a port, and configures itself to use that port. Having once had to set up a Windows machine, I appreciate Be's effort at making it easy to set up their computer.

All of the BeOS preference applications are in one folder, and each preference is in a well named application. Contrast that with whenever I need to configure my Macintosh, I never seem to know exactly where to find the correct configuration panel. I didn't have that problem with the BeOS. On the other hand, I spent over an hour configuring the BeOS until things worked, and I am still having some problems with the Ethernet. It's never taken me that long to get any Macintosh configured, except when MacTCP was first released. Overall, configuring the BeOS was in some ways easier than configuring a Macintosh, in other ways more difficult.

Once I had everything set up and ready to go, the applications worked as I would expect. I was able to find several shortcuts by just trying things. The shortcuts I found were nicely done. If you are used to Macintosh shortcuts, then you won't be disappointed by the BeOS shortcuts. They implemented many of the Macintosh shortcuts, and the new shortcuts they have introduced make sense and work well. They did miss command-clicking a window title to get a path, but that was the only shortcut I regularly use that the BeOS did not implement.

I must say that the BeOS is not Macintosh, and I doubt it ever will be confused with Macintosh - but on its own merits, I must say that the BeOS is nice. I am using DR8, which, near as I can tell, is 2 releases away from 1.0. Having used NeXTSTEP at 0.8, and seen how much NeXT cleaned it up for 1.0, I expect future versions of the BeOS to be very nice, but it is as yet unfinished. There is very little that "doesn't work," and much of it works well. In many ways, it's an improvement over other GUI's that are already shipping, but not much of its UI is revolutionary.

About the Development Environment

Metrowerks, on their CodeWarrior 10 CD, provides tools to cross-compile Be applications on your Macintosh. You can even do remote debugging over the network. However, Metrowerks also ported their IDE to the BeOS, and the BeIDE is included with the BeOS.

You can also use the compiler from the command line. Make is supported, as is calling the compiler directly. You can edit your files under the BeOS using their low end graphical editor called Edit. After using Edit, though, I recommend using CodeWarrior.

The command line make uses mwcc and mwld. The mwld shipped with the BeOS is a demo limited to 64K applications. This limit prevents anything useful from being created, but the commercial linker from Metrowerks will work from the command line. You will have to copy a folder from your CodeWarrior CD to the BeBox and place the new linker in the correct place. If you unzip the folder from the root volume, it should install automatically in the correct place for you. I used ftp, but later versions of the BeOS, I'm told, will be able to read Macintosh CD-Roms.

If you have Metrowerks CodeWarrior 10, then you have the full Be development environment. However, Metrowerks will no longer be including the Be development kit on their CodeWarrior CD. You will have to buy it from Metrowerks for $299/year; currently discounted to $149 if you act now.

If you know how to program in NeXTSTEP, the Be operating system will seem very familiar. Most of the people I met at Be were NeXTSTEP programmers at one time or another. There is a lot in Be's framework that other framework developers should look at. Again, I didn't see anything revolutionary over NeXTSTEP, but it's the first time I've seen a really good framework written in C++.

A Simple Port: Unix Code

The BeOS has a mini-Unix environment to make porting Unix code to the BeOS easier. The theory, according to Be, is that you only need to unpack the source code, cd to the directory, and type make. I thought this would be a quick, easy test of the development environment. I attempted to port tf, a mud client. Unfortunately, it needed a bit more of the Unix environment than Be provided. My problems seemed to be with the configuration script, though, not with the actual program. Here are the details.

tf uses a configuration script to determine on what kind of box it is being built. When attempting to run the configuration script, I had no output to the terminal window. After some exploration, I found that tf uses tee to log the session to a file as the user configures tf. Though for whatever reason, tee was only sending the session to the file, not to standard out. By removing all calls to tee, I got through my first hitch.

Once I removed tee, the configuration script choked because of Be's naming convention. All Unix boxes name their default compiler cc, and many Unix boxes have gcc installed. Be calls their compiler mwcc. I don't know of any software packages out there that expect to call a compiler mwcc. Rather than edit every makefile, I made copies of mwcc and mwld, and called them cc and ld.

Another minor problem I had with Be's naming convention is their use of bash for the standard /bin/sh. /bin/sh is normally standard bourne shell on every Unix box I've ever used. Instead, Be provides bash for /bin/sh. While bash is a nice shell, and it is mostly compatible with /bin/sh, it's not /bin/sh, and some configuration scripts will only work with /bin/sh.

The only serious problem was with how the configuration script works. The configuration script for tf works by changing to the Unix directory and running another script. Somewhere in the scripts, something had not recognized the directory had changed. This is a major problem for tf because it relies on changing directories and doing makes. If all the source is in the same file, then there should not be a problem, but most configuration scripts put sources in multiple directories, and changing directories must propagate. I was able to work around this problem by changing where the config scripts placed files.

Now that the make scripts were going, I ran into problems with the header files. in.h and inet.h are the standard headers for tcp programs, but Be uses net/socket.h instead. Usually, socket.h is found under sys, but Be put it under net. I edited the config script to use net/socket instead of in.h. I also had to edit one file to change the sys/socket.h to be net/socket.h. These things are minor, but they are just more stalls in getting started.

There were several standard library routines that tf could not find in the BeOS, but none of them were critical for tf. The configuration script was able to automatically turn off those features as needed. Unfortunately this is likely to be a problem for other programs. The missing library calls are getwd, hstrerror, srandom, strcmpi, stricmp. Be also put gethostbyname and connect in a different library.

After these changes, the configuration ran and started the compile. The first error hit in the compile was a doubly defined macro for bcopy. Because bcopy was used by every file, every compile failed. I couldn't figure out how to stop a runaway process; neither control-C, nor atl-. stopped the compile. Each file failed, and I had to sit there and watch each file fail. A minor edit of one header file corrected the doubly defined bcopy.

After much editing of the configuration script I was able to cd to the directory, type make and get a working Unix program. A bit more work than I was led to believe, but much less than porting any Unix code to Macintosh or Windows.

Porting Macintosh Code

If your application is already written in a C++ framework, then porting to the BeOS and their framework will not be very difficult; just don't expect to finish it overnight. If you have a legacy application with multiple event loops, and absolutely no code encapsulation, it would probably be easier to start from scratch than port your code.

First, you must split your application into 5 parts: setup, event loop, user interface, file I/O, and the back end. Throw out the first three, because Be does it their own way. Next, modify your code for Be's File I/O, and set up the back end so you can call it from C++. You are ready to start your port. If you have printing or networking in your application, then you also will have to redo them. Because the BeOS uses standard Unix networking calls, your network rewrite may be quite painful. At least you get to keep your back end.

Application Setup

A Be application is set up differently than a Macintosh application, but it's straight forward enough. Once you know how to do it, it's more or less the same each time. You must have an icon, a signature, launch information stored in the launch resource, and one short routine to instantiate and run your App object.

You can create your icon in Be's IconWorld. You also use IconWorld to edit your application's launch resources such as signature, launch exclusivity, background app, and argv-only settings. Unfortunately it only lets you edit the resources needed for launch.

On Macintosh, each application is supposed to have a unique signature. On the BeOS, every application must have a unique signature, or you may be unable to launch the application. Be will be happy to give you one through email each time you need one.

The BeOS centers everything around windows, and multiple instances of the same application are a lot like multiple windows in one application. Be allows the application developer to set a launch preference for one of the following:

  • Launch each time it is clicked.
  • Launch only once per copy of the application.
  • Launch only once no matter how many copies there are.

The BeOS uses the signature to tell if two copies of an application are the same. Hence, it is very important that you do not duplicate signatures.

A typical main routine is pretty straightforward.

Listing 1: main.c

#include "MyApplication.h"

main()
int InstallDesktop()
{
 new MyApplication(‘abcd');
    // other initialization goes here
 be_app->Run();
 delete be_app;
}

The signature in this routine is ignored if the application has it in a resource. It's just there in case that resource is missing.

Event Loop

Be handles events by passing BMessage objects to BLooper objects, which in turn pass the BMessage object to a BHandler. The BApplication object and BWindow objects are subclasses of BLooper, and handle most of your system messages for you. For most of the items in your Macintosh event loop, you can just throw out your event handling code, since the BeOS framework handles the entire thing for you. In the rare case where you want to do something special, there are filters you can place on the BLoopers.

You override the BLoopers MessageReceived method to handle menu commands and button clicks. The easiest way to do this is to subclass BWindow, which is a subclass of BLooper that receives all the UI messages. The code in this BLooper looks a lot like a Macintosh event loop, but instead of dealing with low level events and turning them into concepts, the BeOS sends you messages that could have come from anywhere. For example, on Macintosh, you might have an Apple event and a menu command that do the same thing. The Apple event processing, however, would have to figure out what was going on, then call the appropriate routine. Likewise, the menu command would call MenuSelect, then determine which routine it's referring to, then calls the appropriate routine. On the BeOS, much like most frameworks, all that is handled for you, and you only have to look for a message of a particular type. No matter how the event was generated, it always appears as the same message by the time you see it.

Each message can have additional data inserted into it. In the sample code used in Listing 2, we pull the target out of our button's message. When the button was set up, the target could be placed into the button with an AddObject call. You can not only add objects, but any data type, as well as multiple data types. Adding multiple data items of the same name and type will create an array of those items, so a button could have multiple targets.

Listing 2: MessageReceived

MyWindow::MessageReceived(BMessage *message)
{
 switch(message->what)
 {
 case MYBUTTON:
 MyTarget *target = (MyTarget *)message->FindObject("target");
 target->DoIt();
 break;
 case MYMENU:
 DoFunkyMenuCall();
 break;
 default:
 BWindow::MessageReceived(message);
 break;
 }
}

Building a User Interface

First, the BeOS UI is as different from the Macintosh as is Windows, but in its own way. A Be application expects to be a window, and each window acts like its own application. Unlike a Macintosh application, which has a no document state, Be applications are usually only the one visible window. If you want a second window, the BeOS treats it like a second application. Each window gets its own menu bar, its own thread for execution, its own event BLooper, everything. Furthermore, BeOS messaging makes little distinction between communicating between two threads of one application, or two applications. To fully appreciate this, I brought up the Save As panel and then continued editing my document. The Save panel happily went into the background while I finished editing my document, then came to the foreground when I clicked it so I could save the changed document.

Each window and dialog you have for your Macintosh will have to be redesigned to look good on the BeOS. Be applications can have two menus, one pull-down menu in the upper left corner, and one optional menu bar in the window. Unfortunately, I could not find any interface builder application, such as Constructor, for the BeOS. All the sample source code from Metrowerks builds the user interface on the fly. I feel this is a major setback for developing on the BeOS, but I would expect it to be remedied soon by either Be or a third party developer.

The pull down menu in the upper left has default values for About This Application and Quit Application, but you will probably want to add some of your menu items to this menu. Other menu items generally belong in a menu bar for the window, and those must be hand coded. Listing 3 provides an example.

Listing 3: BuildMenuBar

MyWindow::BuildMenuBar(BRect winRect)
{
 BRect barRect;
 barRect = winRect;
 barRect.bottom = barRect.top + MENUBARHEIGHT;
 menuBar = new BMenuBar(barRect, "menu bar");
 myMenu = new BMenu("MyMenu", B_ITEMS_IN_COLUMN);
 myMenuItem = new BMenuItem("MyItem", new BMessage(MYMENU));
 myMenu->AddItem(myMenuItem);

    // The rest of your menus and menu items would continue on

}

Like the menus, buttons and other user interface objects have to be hand coded. If you have a really old application, you might already have the hand coded UI, but if you have used Constructor, you are almost starting from scratch. If you have become used to using any interface builder at all, then you are really going to be missing it.

Most of the standard UI elements are objects, so creating them is easy, but placing and modifying them is a code change. Localizing for international applications may require a lot of work. I would have preferred to load strings from a resource of the main application, but I did not find an easy way to do this. All the sample code hard coded all strings.

All of the typical UI objects you would expect are included in the BeOS. Unfortunately, all of them require hand coding, such as the Menu code in Listing 3. All of the code is almost identical, and it is screaming out for the use of templates. If not templates, I would have to at least use #defines to create macros for building the UI.

Setting up macros for each of the UI elements would not be that much work. Setting up the menus would be as simple as

#define NewMenu(name) new BMenu((name), B_ITEMS_IN_COLUMN); 
#define NewMenuItem(menuItem, name, menu, message) \ 
{\
 menuItem = new BMenuItem((name), new BMessage((message)));\
 menu->AddItem((menuItem)); \
}

Then the Menu code would shorten to

MyWindow::BuildMenuBar(BRect winRect)
{
 BRect barRect;
 barRect = winRect;
 barRect.bottom = barRect.top + MENUBARHEIGHT; 
 menuBar = new BMenuBar(barRect, "menu bar"); 
 myMenu = NewMenu("MyMenu");
 NewMenuItem(myMenuItem, "MyItem", myMenu, MYMENU); 

    // The rest of your menus and menu items would continue on 

}

Creating buttons is almost identical to creating the menus. The main difference I found was the ability to set a target so your main window does not have to handle the button messages. Once again, I would create templates or macros before creating any buttons. Likewise, the other user interface items have to be hand coded, and each has its own parameters, but each one is very similar to the menus I've already described.

File I/O

The BeOS uses a database to store its files. I was quite excited about this until I found out that it is not a very powerful database. Each entry in the database is tagged for querying, and finding a file on the hard drive is extremely fast, but you cannot do any searches on contents of files.

Even limited to table entries, there is a lot that can be done, and the BeOS applications that take advantage of it are very powerful. For example, the BeOS dumps all of the email it receives into individual files in the database, and any application can search for email based on the email messages' attributes. Unfortunately, you cannot search for an email message based on the contents of the email message.

When porting a Macintosh application, you probably won't be able to take advantage of the BeOS database, but you should not be hindered by it either. The BeOS has a BFile and BResourceFile object, and despite not being identical to a Macintosh FSSpec, they are close enough. The hardest part you will encounter will probably be the non-modality of the Save File Panel. Many Macintosh applications assume the document cannot change when the save panel is up. On the BeOS, there is no rule against it. The opening, reading, and writing of files should be very easy to convert.

Back End

Hopefully, this is the meat of your application. The BeOS uses Metrowerks C++ compiler. If you already use Metrowerks, you shouldn't have much trouble porting the rest of your code to the BeOS. If you have already been using good object oriented techniques, then you should not have any problem putting a new UI on your back end.

Be careful about reentrancy. A significant amount of Macintosh code is not reentrant, and it's a bit of extra work to make BeOS code non-reentrant. If your code is non-reentrant, you may have some real problems here. You might be best off making the back end an exclusive launch server with no front end, and have a multi-launch front end that messages the server. As the BeOS makes no difference between a UI messaging itself and a UI messaging another application, you can easily make a non-reentrant server to be the back end to your UI.

Conclusions

If a BeOS was dumped on my desk, which one was, and I was told to port some existing code to it, which I did, I would not be upset, which I am not. It's not a Macintosh, and the user experience of the BeOS is not the same, but it does stand on its own.

Porting Unix code could, and should, be a bit easier, but it's not difficult - I can forgive a lot because the BeOS is still a prerelease. I would expect Be to fix any problems they come across over the next several months.

Porting Macintosh code, on the other hand, is a major undertaking. However, porting Macintosh code to Windows is an even larger commitment - so, relatively speaking, it is not that difficult. If you are using PowerPlant or some other framework, you can expect your port to be a large project, but most of your back end should easily transfer. On the other hand, if your code is a legacy application written before the invention of C++, then you are in for a world of hurt.

The BeOS has a lot of potential, and I look forward to seeing it develop. It is a young system. Many parts of it sound very nice, and have the potential to develop into very useful features on all computer programming environments. Just as features of NeXTSTEP's development environment have migrated to other platforms, the BeOS is definitely worth getting just to see the new ideas they have put into their computer.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

OS X Server 4.1.3 - For OS X 10.10 Yosem...
Designed for OS X and iOS devices, OS X Server makes it easy to share files, schedule meetings, synchronize contacts, develop software, host your own website, publish wikis, configure Mac, iPhone,... Read more
pwSafe 4.1 - Secure password management...
pwSafe provides simple and secure password management across devices and computers. pwSafe uses iCloud to keep your password databases backed-up and synced between Macs and iOS devices. It is... Read more
Kodi 15.0.rc1 - Powerful media center to...
Kodi (was XBMC) is an award-winning free and open-source (GPL) software media player and entertainment hub that can be installed on Linux, OS X, Windows, iOS, and Android, featuring a 10-foot user... Read more
Coda 2.5.11 - One-window Web development...
Coda is a powerful Web editor that puts everything in one place. An editor. Terminal. CSS. Files. With Coda 2, we went beyond expectations. With loads of new, much-requested features, a few surprises... Read more
Bookends 12.5.7 - Reference management a...
Bookends is a full-featured bibliography/reference and information-management system for students and professionals. Access the power of Bookends directly from Mellel, Nisus Writer Pro, or MS Word (... Read more
Maya 2016 - Professional 3D modeling and...
Maya is an award-winning software and powerful, integrated 3D modeling, animation, visual effects, and rendering solution. Because Maya is based on an open architecture, all your work can be scripted... Read more
RapidWeaver 6.2.3 - Create template-base...
RapidWeaver is a next-generation Web design application to help you easily create professional-looking Web sites in minutes. No knowledge of complex code is required, RapidWeaver will take care of... Read more
MacFamilyTree 7.5.2 - Create and explore...
MacFamilyTree gives genealogy a facelift: it's modern, interactive, incredibly fast, and easy to use. We're convinced that generations of chroniclers would have loved to trade in their genealogy... Read more
Paragraphs 1.0.1 - Writing tool just for...
Paragraphs is an app just for writers. It was built for one thing and one thing only: writing. It gives you everything you need to create brilliant prose and does away with the rest. Everything in... Read more
BlueStacks App Player 0.9.21 - Run Andro...
BlueStacks App Player lets you run your Android apps fast and fullscreen on your Mac. Version 0.9.21: Note: Now requires OS X 10.8 or later running on a 64-bit Intel processor. Initial stable... Read more

Rage of Bahamut is Giving Almost All of...
The App Store isn't what it used to be back in 2012, so it's not unexpected to see some games changing their structures with the times. Now we can add Rage of Bahamut to that list with the recent announcement that the game is severely cutting back... | Read more »
Adventures of Pip (Games)
Adventures of Pip 1.0 Device: iOS iPhone Category: Games Price: $4.99, Version: 1.0 (iTunes) Description: ** ONE WEEK ONLY — 66% OFF! *** “Adventures of Pip is a delightful little platformer full of charm, challenge and impeccable... | Read more »
Divide By Sheep - Tips, Tricks, and Stre...
Who would have thought splitting up sheep could be so involved? Anyone who’s played Divide by Sheep, that’s who! While we’re not about to give you complete solutions to everything (because that’s just cheating), we will happily give you some... | Read more »
NaturalMotion and Zynga Have Started Tea...
An official sequel to 2012's CSR Racing is officially on the way, with Zynga and NaturalMotion releasing a short teaser trailer to get everyone excited. Well, as excited as one can get from a trailer with no gameplay footage, anyway. [Read more] | Read more »
Grab a Friend and Pick up Overkill 3, Be...
Overkill 3 is a pretty enjoyable third-person shooter that was sort of begging for some online multiplayer. Fortunately the begging can stop, because its newest update has added an online co-op mode. [Read more] | Read more »
Scanner Pro's Newest Update Adds Au...
Scanner Pro is one of the most popular document scanning apps on iOS, thanks in no small part to its near-constant updates, I'm sure. Now we're up to update number six, and it adds some pretty handy new features. [Read more] | Read more »
Heroki (Games)
Heroki 1.0 Device: iOS Universal Category: Games Price: $7.99, Version: 1.0 (iTunes) Description: CLEAR THE SKIES FOR A NEW HERO!The peaceful sky village of Levantia is in danger! The dastardly Dr. N. Forchin and his accomplice,... | Read more »
Wars of the Roses (Games)
Wars of the Roses 1.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0 (iTunes) Description: | Read more »
TapMon Battle (Games)
TapMon Battle 1.0 Device: iOS Universal Category: Games Price: $.99, Version: 1.0 (iTunes) Description: It's time to battle!Tap! Tap! Tap! Try tap a egg to hatch a Tapmon!Do a battle with another tapmons using your hatched tapmons! *... | Read more »
Alchemic Dungeons (Games)
Alchemic Dungeons 1.0 Device: iOS Universal Category: Games Price: $.99, Version: 1.0 (iTunes) Description: ### Release Event! ### 2.99$->0.99$ for limited time! ### Roguelike Role Playing Game! ### Alchemic Dungeons is roguelike... | Read more »

Price Scanner via MacPrices.net

Seagate Backup Plus Drives Feature 200GB of C...
Seagate Technology plc has announced that its Backup Plus family of external storage offerings will now include 200GB of OneDrive cloud storage, a major added value, and the addition of Lyve’s photo... Read more
Canon PIXMA MG3620 Wireless Inkjet All-in-One...
Canon U.S.A., Inc. has announced the PIXMA MG3620 Wireless (1) Inkjet All-in-One (AIO) printer for high-quality photo and document printing. Built with convenience in mind for the everyday home user... Read more
July 4th Holiday Weekend 13-inch MacBook Pro...
Save up to $150 on the purchase of a new 2015 13″ Retina MacBook Pro at the following resellers this weekend. Shipping is free with each model: 2.7GHz/128GB MSRP $1299 2.7GHz/... Read more
27-inch 3.5GHz 5K iMac on sale for $2149, sav...
Best Buy has the 27″ 3.5GHz 5K iMac on sale for $2149.99. Choose free shipping or free local store pickup (if available). Sale price for online orders only, in-store prices may vary. Their price is $... Read more
Apple now offering refurbished 2015 11-inch...
The Apple Store is now offering Apple Certified Refurbished 2015 11″ MacBook Airs as well as 13″ MacBook Airs (the latest models), available for up to $180 off the cost of new models. An Apple one-... Read more
15-inch 2.5GHz Retina MacBook Pro on sale for...
Amazon.com has the 15″ 2.5GHz Retina MacBook Pro on sale for $2274 including free shipping. Their price is $225 off MSRP, and it’s the lowest price available for this model. Read more
Finally Safe To Upgrade To Yosemite’?
The reason I’ve held back from upgrading my MacBook Air from OS X 10.9 Mavericks to 10.10 Yosemite for nearly a year isn’t just procrastination. Among other bugs reported, there have been persistent... Read more
Logo Pop Free Vector Logo Design App For OS X...
128bit Technologies has released of Logo Pop Free 1.2 for Mac OS X, a vector based, full-fledged, logo design app available exclusively on the Mac App Store for the agreeable price of absolutely free... Read more
21-inch 1.4GHz iMac on sale for $999, save $1...
B&H Photo has new 21″ 1.4GHz iMac on sale for $999 including free shipping plus NY sales tax only. Their price is $100 off MSRP. Best Buy has the 21″ 1.4GHz iMac on sale for $999.99 on their... Read more
16GB iPad mini 3 on sale for $339, save $60
B&H Photo has the 16GB iPad mini 3 WiFi on sale for $339 including free shipping plus NY tax only. Their price is $60 off MSRP. Read more

Jobs Board

Mobile Payments Counsel, *Apple* Pay (digit...
**Job Summary** Apple is looking for an atto ey to join Apple 's Legal Department to support Apple Pay. **Key Qualifications** 4+ years of relevant experience Read more
*Apple* Solutions Consultant - Retail Sales...
**Job Summary** The ASC is an Apple employee who serves as the Apple business manager and influencer in a hyper-business critical Reseller's store which delivers Read more
Partner Marketing Manager, Merchant- *Apple*...
**Job Summary** The Apple Pay partner marketing team is looking for a marketing manager to develop and drive US marketing programs with our merchant partners. The right Read more
*Apple* Solutions Consultant - Retail Sales...
**Job Summary** As an Apple Solutions Consultant (ASC) you are the link between our customers and our products. Your role is to drive the Apple business in a retail Read more
Program Manger, WW *Apple* Direct Fulfillme...
**Job Summary** We are seeking a business analyst to work within our Worldwide Apple Direct Fulfillment Operations team. This role will work closely with related program Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.