Re: Porting windows app to OS X and it's extremely huge as a result
Re: Porting windows app to OS X and it's extremely huge as a result
- Subject: Re: Porting windows app to OS X and it's extremely huge as a result
- From: Platon Fomichev <email@hidden>
- Date: Sat, 24 May 2008 17:21:17 +0400
Dear Sherm
The application gets downloaded to the user each time, so that's why
I am so troubled. Mac binaries will be split into all possible
architectures and small helper tool will download the executable for
each architecture. Yes, here the size and d/l speed is that
important. Believe me Mac users are no different to Windows when it
comes to waiting time.
However the topic here is a bit more wide - generally I even want
this to be moved to some specific Apple GCC discussion place (if
there is one). Why don't we have working and good optimization which
exists on many modern Unixes with GCC 4.x - (-fzero-initialized-in-
bss/-fnozero-initialized-in-bss).
Best regards,
Stauff__
On May 24, 2008, at 17:11 PM, Sherm Pendley wrote:
On Sat, May 24, 2008 at 6:50 AM, Platon Fomichev
<email@hidden> wrote:
I am porting a huge Windows application to OS X - I have to keep
lots of code intact and this is a requirement - as a parallel I am
also doing Linux port. The resulting binary is extremely big and
can't be compared to either Win32 and Linux.
You're right, it *can't* be compared to either, so we can stop
right here.
Mac binaries are normally built for *two* architectures, PPC and
Intel. With the introduction of Leopard and its 64-bit support,
we're even beginning to see them built for 32- and 64-bit versions
of each. So, even assuming that a given app compiles to the same
size binary for Windows on Intel 32-bit and Mac OS X on Intel 32-
bit, the Mac binary is still going to be from 2-4 times bigger
overall because it also has binaries for other architectures.
This is really bad for customers as size is a critical priority.
You'll find it's not so critical for Mac users, if it does actually
turn out to be the result of multiple architecture support. We're
in the midst of two rapid hardware shifts, from PPC to Intel, and
from 32 to 64 bit on both, so *everybody's* binaries are bigger,
not just yours. We're used to this by now, and we won't blame you
for it. :-)
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden