Windows

There are 4 entries in this Category.

How to install Windows 8.1 on a Mac

WindowsOnMac

Update: Microsoft now sells Windows 10 on USB keys, so even Mac users can install it easily if they order physical media. Also, I’ve heard (but have been unable to confirm) that Microsoft’s download version of Windows now can be obtained as an .ISO disk image again, which the Mac’s Disk Utility can extract onto a USB key.
 
I’m leaving this article up for people who somehow still end up with the .exe installer and are looking for a workaround.

It is not quite trivial to buy Windows as a download and get it onto your Mac. I’ve found a workaround, but it takes a lot of time, and requires you to download about 7GB of data via the internet.

Disclaimer: I do not guarantee that these steps will work. They worked for me in late June 2015, YMMV. Do not blame me if you buy a download version of Windows and then can’t install it. Also, be sure to make a backup of your entire hard disk/SSD before you do this. You will be resizing partitions and doing other things that could lead to accidental loss of data.

The Problem:

  • The microsoftstore.com Windows 8 download is a small .exe file containing a downloader application that needs an already-installed Windows to work.
  • Macs these days don’t have a DVD drive, so you’d need to buy/borrow one to be able to use install DVDs mailed to you.
  • Boot Camp Assistant assumes a physical DVD or an ISO disk image, it obviously can’t run the .exe under MacOS.
  • I was unable to get the .exe downloader to run under CrossOver on MacOS.

My workaround:

  • Download the trial of Windows 8.1 for Enterprise as an ISO image from Microsoft (need to create an MS account which you will also later need to buy the download)
  • Use Boot Camp Assistant to install that onto an empty USB stick that is at least 4GB (not just the Apple-specific drivers, check the option for the full install partition). The stick will be formatted using Windows’ old FAT32 format, which both Mac and Windows can read and write.
  • ~100GB (at least 60) is a good size for the Windows partition to add to your internal hard disk/SSD.
  • Boot Camp will now churn a while and copy the files from the ISO on your USB stick, and will also download the newest hardware drivers from Apple and make sure those get installed as well. Time for breakfast.
  • When Boot Camp Assistant reboots, hold down the option key and select the “EFI Boot” entry to make sure you don’t end up back in MacOS.
  • You will find yourself in the standard Windows installer now. Follow its directions. On Retina Macs, it will be at a tiny 1:1 resolution. Bring a magnifying glass.
  • When asked where to install the Boot Camp partition, find the one named “BOOTCAMP” and select it. Remember what else it says (e.g. “Disk 1 Partition 4”).
  • If the Windows installer complains about the partition not being formatted as NTFS, Click the “Format” button underneath the list, but don’t do any repartitioning with the Windows tools, you’d only disturb the fairy dust that Boot Camp Assistant has applied and break booting back into MacOS.
  • Select the reformatted disk (which has now lost its “Bootcamp” name) and click “Next” to start installing the trial.
  • Make lunch while pretty colorful screens rotate through and Windows is set up for you in the background.
  • Run through the Boot Camp installer that runs in Windows after the standard Windows installer has finished.
  • Once you have a working trial install of Windows, buy the download .exe from microsoftstore.com, if you haven’t already. Unless they say they don’t, installers include both old-style 32-bit versions and the 64-bit versions needed for Macs, don’t worry.
  • Run the .exe you just bought while you’re running the Enterprise Windows Trial to create a proper ISO with your purchased Windows 8.1 on it.
  • Back up that Windows.iso and its license key somewhere safe.
  • Copy the Windows.iso onto the USB stick so you can get at it from MacOS.
  • Note down the Windows license key somewhere, you’ll need to type it in in a moment.
  • Boot back into MacOS and run Boot Camp Assistant a second time to remove the trial partition. (BCA doesn’t let you run it again on an existing partition, so you’ll have to nuke and recreate)
  • Run Boot Camp Assistant a 3rd time, this time using the new ISO, not the trial, to get the desired full Windows install. Remember to hold down the Alt key at startup to select “EFI Boot” or you’ll just end up back in MacOS.
  • When the standard Windows installer comes up, you’ll need to enter your Windows license key this time. From then on, the install will be identical to the trial install.
  • Your Yak is shaven clean as a baby’s bum.

Note: In theory, it should be possible to run the .exe under the trial to directly install Windows 8.1 on top of the trial instead of generating the ISO, but I didn’t want to risk it somehow generating a mix of the trial and purchased Windows installs, or eliminating the Boot Camp-supplied drivers & programs, so I decided to nuke the trial once I had the ISO and start fresh. Whatever you do, generate and back up the ISO so you don’t need to request another trial from MS when you inevitably want to reinstall Windows at a later time, even if you then use the .exe and not Boot Camp for the second installation.

Thanks:Thanks to Sören for pointing me at the Windows trial version that made this possible.

Microsoft supports UIKit

iPhoneOnWindows

This week’s Build conference held a big surprise: Microsoft announced that they’ve built a UIKit compatibility layer for their various flavours of Windows.

Now I’m mainly a Mac developer and only hear of Windows things from friends and colleagues at the moment (the last time I did Windows work was around Windows XP), but my impression so far was that MS was frantically searching for a new API.

I don’t remember all occurrences, but I remember them announcing Silverlight, and .NET with WPF, and Windows RT that only supported the new APIs, and all sorts of things to then cancel them again.

So my impression as an outsider is that new APIs weren’t trustworthy and MS would always fall back to supporting their old API main-line that they carry around for compatibility reasons anyway.

Announcing UIKit and Android support actually makes a lot of sense in that context:

Although it appears to acknowledge that Windows Phone really didn’t take off, it does solve the catch-22 that MS found themselves in: Lack of apps. In an ideal case, they’ll now get all iOS apps Apple sells, plus the ones Apple rejected for silly reasons, plus those Android apps that iOS users long for.

If this gambit pays off, MS could leap-frog Apple *and* Android.

It also increases trust among developers who are sticking to ancient API: iOS and Android are the only modern APIs that Microsoft could implement that developers would confidently develop against after all these false starts, because even if MS dropped support for them, they’d still have the entire iOS/Android ecosystem to deploy against. So coding against UIKit for Windows Phone is a reasonably safe investment.

Swift

Of course, the elephant in the room here is Apple’s recent move to Swift. Now, given that Apple’s frameworks still all seem to be Objective-C internally (even WatchKit), I don’t think MS have missed the train. They might even pick up some Swift critics that are jumping Apple’s ship by supporting Objective-C.

But Swift damages the long-term beauty of MS’s “just call native Windows API from Objective-C” story. They will have to bridge their API to Swift (like Apple does with some of their C-based API right now), instead of getting people to use more and more classic Windows API in their Cocoa apps until the code won’t run on iOS anymore.

Still, that’s a small aesthetic niggle. MS already have a code-generator back-end that they can plug any parser onto, and Swift doesn’t appear to be a particularly difficult language to parse. In any event, parsers are easier than good code generation. For MS to create a Swift compiler is a solved problem, and I’d be surprised if they weren’t already working on it.

Of course, if MS had known about Swift when they started their UIKit for Windows, would they still have written it in Objective-C? Or would they have just written it in Swift with a bridging header?

So given the situation MS have managed to get themselves into, this sounds like it might be a viable solution to survive and, maybe, even come back from again. Still, it is an acknowledgement of how MS has fallen, that they need to implement a competitor’s API on their platform.

All you need to know about the Mac keyboard

There are still many rumors and myths about the Macintosh, and particularly about the abilities of its keyboard. Since many of them come from outdated information from the 1990s, I thought I’d correct some of them and compile a comprehensive page of keyboard facts as they pertain to the Mac.

[Arrow keys on a Mac keyboard]

False Rumor 1: You can’t forward-delete on a Mac

Untrue. For the last 12 years, most Macs shipped with a forward delete key right in the same spot where PC keyboards have them. If you happen to have a small keyboard, like the new wireless keyboards, the compact wired keyboard or on a MacBook, that do not have that key, you can use the regular delete key (which deletes the key to the left of the cursor), and hold down the key labeled “fn” in the lower left to change it to delete the key to the right.

False Rumor 2: The Mac has no Home/End keys or Page Up/Page Down keys

Again, this is wrong. Most Mac keyboards have these keys where you’d expect them, the smaller keyboards have shortcuts to do the same thing. fn + Left arrow key is “Home”, fn + Right arrow key is “End”, fn + Up Arrow key is “Page Up”, fn + Down arrow key is “Page Down”.

However, note that the Home and End keys move the blinking text insertion mark on Windows, whereas on the Mac they only scroll what you see. The reason for this is that the Mac had shortcuts for doing this even before it had these keys: Press Command + Up arrow to move the insertion mark “Home” (i.e. to the start of the document), Command + Down arrow to move it to the end. This is quite convenient, because you can quickly check the start of your text, then continue typing and you’ll end up right where you were before.

An alternative for the Mac’s Page Up/Page Down keys is also Ctrl + Up arrow resp. Ctrl + Down arrow.

False Rumor 3: The Mac has no equivalent to Ctrl + Arrow key combinations

Wrong again. Alt + left arrow and Alt + right arrow go one word left/right. To go to the start/end of a line, which is Ctrl + Up arrow resp. Ctrl + Down arrow on Windows, you use Command + Left arrow and Command + Right arrow instead.

False Rumor 4: The Mac has no Function Keys

Most newer keyboards have these keys, however, they are on the same physical keys as the “media keys” like “Play”, “Pause”, “Volume up”, “Exposé” etc. To use them as function keys F1 through F19 (or F1 through F12 depending on what keyboard you have), you have to hold down the “fn” key while you press them.

Function keys are not very commonly used on the Mac, but if you find yourself using a program that uses them a lot and you don’t want to always hold down “fn”, there is a setting in the “Keyboard” pane of “System Preferences” where you can tell it to “Use all F1, F2 etc. keys as standard function keys” to change the behaviour. To change system sound volume, you then hold down the “Fn” key.

False Rumor 5: The Mac can’t be controlled with only a keyboard

It can. First, there are standard keyboard shortcuts displayed to the right of each menu item. They generally use the Command key instead of the Ctrl key that is common on Windows. Not all menu items have such shortcuts, so if you want to trigger another, you can type Ctrl + F2 to select the menu bar, and then use the arrow keys to navigate through the menu bar. To stop navigating the menu bar without selecting a menu item, press the “Esc” key. You can also type the beginning of a menu’s or menu item’s name to select it.

Similarly, you can use Ctrl + F3 to select the dock and navigate it using the arrow keys, Ctrl + F4 to rotate through all the windows on screen (Or Cmd + ~ to rotate through the windows of only the current application), Ctrl + F5 to show and select the toolbar of a window (the area right below the window title that contains a bunch of icons and buttons, or in Safari the text field for the address) and navigate it using the tab key, Ctrl + F8 to select the system-wide menus at the right end of the menu bar (Bluetooth, AirPort, Time Machine, Battery, Fast User Switching).

To switch between applications, use Command + Tab, which works pretty much like Windows’s Alt + Tab shortcut.

False Rumor 6: You can’t type special characters like © on the Mac

Wrong. It’s easier than on Windows, even. Where on Windows you have to type Alt Gr. + a 4-digit number, on the Mac you use either Alt key and just type any character. Type Alt-G to get the © character, for instance. Note that you can get more characters by holding down the shift key in addition to Alt. For example, you can get the Spanish Opening question mark character by typing Alt + Shift + ?. Most common international characters can be typed that way.

Just note that, depending on what language your keyboard is in, these shortcuts may be slightly different.

False Rumor 7: You can’t use a PC keyboard on a Mac

Of course you can. Any standard USB keyboard for Windows or Linux will work on a Mac. There are just a few tiny differences to watch out for:

  • The “Windows” or “Penguin” keys are mapped to the Mac’s Command key (“Apple key”)
  • The Alt and Alt Gr. keys are both mapped to the Mac’s Alt key (“Option key”).
  • The Physical location of the Windows and Alt keys on a PC keyboard are reversed from that of the Command and Alt key on a Mac keyboard. So if you switch between Macs with Mac keyboards and Macs with PC keyboards a lot, you’re in for a bit of pain, unless you go into the “Keyboard” pane of “System Preferences” and click the “Modifier Keys” option, where you can tell it to pretend Alt was Command and Command was Alt. But then the labels on the keys will be wrong, of course.
  • The other keys will behave like those on a Mac keyboard. So if you have e.g. a German PC keyboard, where the @-sign is printed on the “Q” key, because it’s produced by pressing Alt Gr. + Q on a PC, that’s wrong, because on German Mac keyboards you type Alt + L to get the @-sign.

False Rumor 8: The Mac doesn’t have Num Lock/Insert mode

This rumor has it backwards. The Mac is always in Num Lock mode, there are no arrow keys on the numeric keypad of keyboards that have a numeric keypad (although a few old Mac laptops had a Num Lock feature that let you use some of the regular keys to simulate a numeric keypad).

Similarly, the Mac is always in insert mode, and most applications do not have the “overwrite” mode. But then again, you can just select a word and start typing to overwrite it, so it’s not as if overwrite mode was still necessary these days.

False Rumor 9: You always have to use the mouse to select text

Just like the PC, you can hold down the Shift key while using the arrow keys to select text. You can even combine the arrow key shortcuts mentioned above with the shift key: Shift + Alt + Left arrow will select the word to the left of the text insertion mark.

False Rumor 10: MacOS doesn’t support standard Unix text editing shortcuts

Actually, most Emacs keyboard shortcuts like Ctrl + K, Ctrl + A or Ctrl + E work just fine in standard Mac text editing fields.

False Rumor 11: The keys on a Mac keyboard are completely wrong compared to a PC keyboard. Y and Z are swapped etc…

Most keyboards (whether Mac or PC) are essentially just a bunch of buttons nailed to a piece of wood. They’re nearly the same all over the world. The only difference between the English keyboard sold in the UK and the German keyboard sold in Germany is the printing on the key caps. Hence, your computer has no way to distinguish those two keyboards. When you first start up your new computer, it asks you what language you would like, and then it assumes that’s what your keyboard is.

So, if you plug in a new keyboard and it has keys with different printing on them, the computer doesn’t know. Keyboards differ significantly between languages: On a US keyboard, to get the German “Ü” character, you have to type Alt + U to get the two little dots, and then type a U to get the combined character. On a German keyboard, there is one key that gives you an “Ü”. And Czech and French keyboards have so many special characters on them, that even the number keys have been moved. To get a number, you have to hold down the shift key.

Now, if you attach a US keyboard to a Mac that has been set up in French and you type the key labeled “1”, you’ll get some weird accented character, because the computer thinks the printing on the keyboard also reflects French convention. To fix this, Go to the “Language & Text” pane of “System Preferences” and there choose the “Input Source” tab. Select the language of your keyboard in the list, and deselect any other languages.

Have any other keyboard myths to share? Are you a Windows switcher who has found (or is looking for) a Mac equivalent to a common Windows shortcut?

Porting to the Macintosh

It comes up a lot on the mailing lists, so I thought I’d write a little piece on the best approach to port an application from another platform (like Windows or a Linux) to the Macintosh. I won’t go into much detail, but outline the general way and the most common pitfalls.

Do not use Carbon or Cocoa-Java

Apple has, for historical and political reasons, provided several different programming APIs. One of them is Carbon, which is a C-based API that many cross-platform developers want to use because it’s more like MFC and other frameworks they already know. At this year’s Worldwide Developers’ Conference (WWDC) a long-running fight inside Apple finally came to a close, and Apple effectively announced they were killing Carbon. There is still some old documentation up on Apple’s developer web site that says otherwise, but don’t let that fool you.

If you are just getting started programming the Mac, use Cocoa to write your end-user application with a graphical user interface. A few of Carbon’s prettiest cherries have been “rescued”, but look for a Cocoa solution first. In particular, any GUI code written in Carbon (control manager, HIToolbox) is not a good investment of your time at this point.

There are also a number of bridges that allow you to use Cocoa with other languages. They’re a great technology, but most of them are fairly new, and you will face issues. Also, since they map Cocoa/Objective C concepts to another language, there will always be something lost in the translation. You will have to know how Objective C does things to understand these oddities. So why not go for Objective C in the first place, where Apple spends its main effort? All the documentation is for Objective C, too.

Don’t even try to use the Cocoa-Java bridge. Apple has already made clear it will see no more development.

You can use C++ with Cocoa

Many people think they will have to rewrite their application in Objective C to make it use Cocoa. That’s not true. Apple has taken great care to make it possible to mix Objective C and C++ in a project. The key here is the “Objective C++ compiler”, which is part of Xcode. You will still have to write the Mac-specific parts in Objective C, but the rest of your application can stay in C++ and can be easily shared with your Windows or Linux developers.

Don’t be afraid of Objective C, Objective C is essentially C: It has a few simple extensions to the language, which are quickly learned. These extensions may seem like a fancy way of duplicating C++ just for the heck of it, but actually, they’re completely different. Objective C essentially is a very elegant and simple way of wrapping the features of COM or CORBA, Qt’s preprocessor, and many other neat things that are done separately on many other platforms. Moreover, the Cocoa frameworks have been designed with Objective C’s particular strengths and weaknesses in mind. Porting Cocoa to C++ would result in such an ugly mess of nested template code you wouldn’t want to do it.

There is no MFC on the Mac

If you’ve never before ported an application to another platform (and I don’t count Windows CE as a different platform than desktop Win32), don’t think you can just look at each function and map it to “the Mac equivalent”. Each platform has been designed at a different time, and thus incorporated the currently accepted programming practices. To create a usable application, you will have to do things the way they are intended to be done on a particular platform. For the Mac, this means making sure your application is split up into a model-, a view- and a controller-layer, according to the MVC design pattern. This is not a Mac-ism: It is a standard design pattern listed in the GOF book, and commonly accepted as the best way to structure a cross-platform application.

If you find that something seems impossibly hard to do in Cocoa, chances are that you’re doing something that you’re either not supposed to be doing, or that you are supposed to be doing in a completely different way. The benefit of this is that you will find yourself being boosted by the framework in ways you didn’t think possible, instead of finding yourself fighting it every step of the way.

Cross-platform frameworks

There are frameworks that have been designed to sit on top of a platform’s native frameworks and hide away the details, for example Qt, Quaqua or wxWidgets. In short: If you aren’t porting a game, where all user interface is custom and you’re full screen without a menu bar anyway, don’t do it. Most of these frameworks don’t really behave like Mac users expect them to. Menus look subtly wrong, don’t scroll and don’t indicate overflows correctly. Keyboard shortcuts don’t work as expected. Pushbuttons are used with the wrong style, disabled icons look black-and-white instead of faded out…

The long story: There are ways to make them work, but in the end, you can’t really share much code regarding UI behaviour, so you might as well go fully native on each platform. Most cross-platform toolkits get the look and the basic behaviour right, but at some point fall into an uncanny valley where they frustrate Mac users. However, of course you can wrap the Mac’s drawing APIs to share code for some of your custom views and displays.

Resources for Mac programmers

I already mentioned Apple’s developer web site above, which contains a lot of resources. In particular, you can find documentation, sample code etc. there. A lot of this stuff gets automatically installed on your Mac when you install the Xcode tools (in /Developer/Examples you’ll get a lot of the sample code, though not all of it, and the documentation can be found in Xcode’s Help menu, and it will automatically download the newest version periodically).

There is a whole section on porting from other platforms on Appe’s developer web site. Just keep in mind that anything suggesting Carbon is probably outdated.

Apple also runs a bunch of mailing lists for developers. These are mainly a place to meet other developers, and are not an official support channel. Nonetheless, make sure you post on the right list: Many people post Cocoa questions on the Objective-C mailing list, which is mainly about the language itself and the language standard, and rarely the one you want to post on as a Mac developer.

Finally, if you find issues, use Apple’s bug reporter, also known as RADAR. You need a free “ADC Online” account, but that’s just so you don’t have to enter your info twice. You can use the same account in Apple’s store and iTunes, BTW. Do not post your bug reports to the mailing lists. You can ask if someone has found a workaround, but the mailing lists aren’t an official bug report channel, and unless you bother filing a bug, Apple will just think you’re venting and it’s not important enough, and will focus on the bugs somebody actually filed and thus indicated they matter to them.