Category Archives: Mac

A simple validator for Mac App Store submissions

Leave a reply

I figured out I had to have an automated check prior to Mac App Store submission because I managed to miss some stuff a few times.

So here’s a beginning of a simple unofficial test suite for Mac App Store submissions: CheckRelease on BitBucket

It currently checks only if you have some external dependencies. I’ll try to write a validation for checking if you have added all the frameworks you depend on into the app, and I hope to extend it with some additional tests.

It’s under BSD license, and contributions are very welcome!

Also, hopefully, Apple will extend their own validator built into Application Loader and Xcode. Currently we have to wait a few days for rejections from the App Store team that are as trivial as “forgot to put in a framework” and “forgot to get rid of an external dependency” (or, at least, a reference to an external dependency that you actually don’t depend on, and that you never actually use).

Mac App Store rejection due to incorrect framework paths

Leave a reply

Apple’s very strict: you can reference frameworks in /System/Library/Frameworks and in your own app. That’s all fine, but there’s another unexpected obstacle. App can be self-contained (the library executable paths patched using install_name_tool) but the install path still references /Library/Frameworks. See “otool -L”; the first reference is a self-reference, and it looks like you can’t easily update it after the library is built. (Or I didn’t look hard enough). And yup, leaving that an absolute path referencing into /Library/Frameworks, that’s enough for rejection.

Untested theory is that updating “Dynamic Library Install Name” (LC_ID_DYLIB) is enough to fix this. I’ve set it to:

@executable_path/../Frameworks/$(EXECUTABLE_PATH)

in place of

$(DYLIB_INSTALL_NAME_BASE:standardizepath)/$(EXECUTABLE_PATH)

Simple multiuser chat for POSIX systems

Leave a reply

Here’s a little multiuser chat server written for various POSIX-compatible operating systems. Written and tested on Mac OS X 10.6, but it should work on your favorite Linux, too.

Placed in public domain, use it for whatever you want (since it’s so simple). 177 lines of pure C powah, dood.

Code follows after the break.
Continue reading →

Some tips on building fuse-python on Mac OS X

1 Reply

I can’t document everything from scratch since I don’t have a machine that’s “virgin” enough for me to document that. This machine has been touched by Fink, MacPorts, Rudix, and several hand-build packages; I’m not sure if MacFUSE installs the necessary stuff for pkg-config.

But, let’s presume you:
a) installed macfuse,
b) fetched pkg-config source code from freedesktop.org (I took 0.25)
c) built it and installed it (./configure, make, sudo make install)
d) switched to pristine Python 2.6 that Apple ships with Snow Leopard.

I’m also obviously using Snow Leopard, so no guarantees about other OS X versions.

Ok, and now come the tips…
Continue reading →

Running Windows XP from physical BootCamp partition on triple-boot Macbook

Leave a reply

Warning: Attempting to boot from physical partition may damage data on your disk, both inside the partition you’re trying to boot from and off of it. Consider yourself warned!

I’m apparently running a somewhat unusual setup for a Mac user: MacOS, Linux and Windows.
$ sudo fdisk /dev/rdisk0
Password:
Disk: /dev/rdisk0 geometry: 30401/255/63 [488397168 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639]
2: AF 1023 254 63 - 1023 254 63 [ 409640 - 322003488] HFS+
3: 83 1023 254 63 - 1023 254 63 [ 322675272 - 59155896] Linux files*
*4: 07 1023 254 63 - 1023 254 63 [ 382093312 - 106303488] HPFS/QNX/AUX

To create a VMDK to access the fourth physical partition, containing Windows, I use the following command:

$ sudo VBoxManage internalcommands createrawvmdk -filename BootCamp.vmdk -rawdisk /dev/disk0 -partitions 4
In VirtualBox I also have to turn on APIC IO and pick ICH6 as the HDD controller. Partition also must be unmounted before booting.

Attempting to boot this results in an error. Windows’ bootloader sees us as having a three-partition setup, which is blatantly incorrect. One can edit BOOT.INI and tell Windows to use partition (3) instead of partition (4).

[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(4)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Microsoft Windows XP Professional " /noexecute=optin /fastdetect

multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional on partition 3"
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional on partition 3 - fast" /noexecute=optin /fastdetect
This results in a blue screen of death.

Creating a VMDK with VMware Fusion, then using its [name]-pt.vmdk file results in a successful boot. First clue is that VMware Fusion created a 32256 byte file, while VirtualBox created a 512 byte file. Googling reveals that 32256 is the size of the MBR. Hence, it could be that VMware simply copied 32256 bytes, as opposed to 512 bytes that VirtualBox took!

$ sudo dd bs=1 count=32256 if=/dev/disk0s4 of=BootCamp-pt-dd.vmdk
32256+0 records in
32256+0 records out
32256 bytes transferred in 0.203430 secs (158561 bytes/sec)
$ cmp -l BootCamp-pt-dd.vmdk BootCamp-pt-vmware.vmdk
451 356 55
467 257 55
483 203 55

So that isn’t the case, but the differences are much smaller than they could be.

So, brave souls, anyone have any idea what the differences might be? Using non-free VMware Fusion to be able to boot physical partition, when all that separates us from success is measly three bytes, is so… undignified.

Grab my .vmdk files; “old” is VirtualBox-generated file, “vmware” is VMware generated file (that works on my setup), and “dd” is file copied with DD.

BootCamp-pt-old BootCamp-pt-vmware BootCamp-pt-dd

Ah-ha! Further examination (at 1:46 CET 🙂 ) revealed that those three bytes, at correct offsets 1C2, 1D2 and 1E2 are partition type identifiers, and were all changed to 2D. That’s the only difference from the dd-captured data! This means perhaps even 512-byte bootsector change would suffice. But that’s a subject for another post. Have fun — try fixing your [name]-pt.vmdk file with a hex editor and post results in comments 🙂

*sigh* must … go … sleep … (2:13 CET)

These lines of code create a working BootCamp VMDK for me, when I have four partitions on my physical hard drive. Playing with physical partitions is dangerous — consider yourself warned before you run these. And of course, running both dd and fdisk on physical partitions is always dangerous; luckily we run fdisk on a file here, but still…

sudo VBoxManage internalcommands createrawvmdk -filename BootCamp.vmdk -rawdisk /dev/disk0 -partitions 4
sudo dd bs=1 count=32256 if=/dev/disk0 of=BootCamp-pt.vmdk # 32256 == mbr size
sudo chown `whoami` BootCamp*
sudo

echo "setpid 1
2d
setpid 2
2d
setpid 3
2d
write" | fdisk -e BootCamp-pt.vmdk

Additionally you need to set /dev/disk0s4 to be writable to your user (which means you’ll probably make it writable to everyone). Since this is even more dangerous, and a horrible, horrible security practice, I won’t put down the command to do this; easiest way to do it has something to do with changing mode to 777 to the mentioned file.

(Note! As of July 22nd, while playing with setting up booting of physical Ubuntu 12.04, I got the equivalent of BootCamp-pt.vmdk that was 37376 bytes long. Changing the dd command accordingly did not help with the problems I was having, but it didn’t seem to harm either.)

Once again: All in this section applies to having four partitions! All in this section can be dangerous!

Single Xcode project for iOS and Mac OS X

6 Replies

In Xcode 3.2.4, it’s trivial to create same project for iOS and Mac OS X. Just add a new target into your existing project; if your project is for OS X, then create a new Cocoa Touch Application target. If your project is for iPhone, obviously, craete a new Cocoa Application target. Then do a Get Info on your new target, and choose the appropriate Base SDK. For simplicity, let’s presume you’re adding an OS X target to an iPhone project.

However, after doing this, you’ll quite probably find that despite the choice of Base SDK in your target (you used Get Info on it, didn’t you?), Xcode has locked the target SDK onto whatever your project originally used. That is, now you’ll find it locked onto iPhone, despite switching to the OS X target using the Overview dropdown (in the top left of your Xcode project).

So how do you actually switched the now-locked SDK? Quite simple. Hold the option key while clicking in the Overview box. Instead of only two-entries device list (if you have an iPhone target selected), and then Active Configuration, Active Target, Active Executable and Active Architecture, by holding the option key while clicking on Overview you’ll also find the Active SDKs list. By switching it to the appropriate OS, you’ll be able to compile the application.

Of course, now comes the hard part: actually porting the code to the new platform.
E49PEQSG669E

[This is syndicated content. Read my blog at http://blog.vucica.net/ – please also leave comments there ]