[Mono-osx] Delphi Prism and all those Cocoa bridges

[Andrew Brehm]

Matt Emson wrote:
> 
> Andrew Brehm wrote:
> 
>>
>> The only downside is that using that method I won't have a single EXE
>> with
>> no DLL requirement that will run on both platforms (and look terrible on
>> the
>> Mac).
>>   
> This is a DOS mentality, unfortunately. Long gone are the days of 
> 2single exe". Even with Win32 pure development, the programmer relied on 
> underlying DLL's existing. This should never be an issue, but often was. 
> Windows didn't really address this issue properly - it made it easy to 
> continue with the practice of "hope the user installed the right version 
> of DLL X". From Win 2000 onwards, we've been pushed towards using 
> installers. Installers should create a subdirectory containing support 
> files that is completely opaque to the user of the system. Indeed in XP 
> onwards, users are discouraged from looking in the Program Files 
> directory by default (all users, even Administrator.) The contents of 
> that directory can contain whatever the developer wants - there's no set 
> rules. Indeed, iTunes, for example, contains a structure not unlike an 
> App Bundle to varying degrees (there was a version around 6 that was 
> almost identical, but the directory contents varies between major 
> revisions.) Visual Studio 2005 has a mess of folders, Delphi 5.0 used to 
> have a structure that split files between folders like {$InstallDir}\bin 
> and {$InstallDir}\lib. Putting the App bundle in to a directory and 
> creating a shortcut to the executable is not a crime. I don't see this 
> as an issue at all.
> 
> 

It's a Mac mentality these days. NeXT solved the problem with the bundles
concept. It's still a whole bunch of files, but it looks like one file and
can easily be copied (and installed by simply copying).

I don't know how Linux wants its programs to be delivered (installer? RPM?
?) but I guess the Windows installer should install, into the program files
directory a bundle.app containing everything needed to run the program on
Windows and Mac OS X, and create a shortcut for the program menu. The root
directory of the bundle should also contain a shortcut creator for Windows.

The Apple version should be distributed as a bundle.

This has the advantage of two versions for two platforms that both behave
completely native, but are still interchangeable. I can copy the installed
Windows version onto a Mac and it will be a bundle (because it is). And I
can copy the Mac version (or installed Windows version) to a Windows
computer's program files folder and run the shortcut creator and have a
working Windows version again.

Does anybody know how Linux should best be supported in this way?



Matt Emson wrote:
> 
> 
>> But I can add a fourth project if I want to support Linux and Gtk#.
>>   
> 
> I have an app I work on at work. Parts are legacy VB, parts are C#. I 
> have over 30 projects for various chunks of business logic and support 
> functionality. If using Visual Studio, embrace the project concept. It 
> really works well. One solution, many projects makes for a happy camper. 
> The fact you can then add project references - genius! Debugging is then 
> seamless between languages and projects.
> 
> 

Very good. I really like Visual Studio. It's perfect for amateurs like
myself.



Matt Emson wrote:
> 
> 
>> Cocoa lacks the regular expressions and portability but has the best
>> right-to-left script support. (But it wants me to understand memory
>> management, which is always a bad move for a programming language.)
>>   
> Objective-C 2.0 has garbage collection properly integrated, so that is 
> not entirely true. Having used the Compact Framework version of .Net on 
> memory constricted devices (Pocket PC) you do begin to hit a memory wall 
> after a while. There's a big trade-off to throwing away the explicit 
> memory management in a low memory situation. The programmer still has to 
> know how to force garbage collection to happen to free up memory, but 
> then has to rely on the Garbage collection to actually work properly and 
> quickly enough to not hang the system due to low memory.. It only takes 
> a bit of badly written/memory leaking code (*cough* Mobile SQL Server 
> *cough*) to throw the "cat amongst the pidgins" and cause radical and 
> sometimes overly elaborate memory clearing scheme to be necessary. It 
> sometimes makes you wonder if Garbage collection is all it is cracked up 
> to be. Indeed, even though I just mentioned Objective-C 2.0 allows auto 
> deletion in a much more effective way (proper Garbage collection), the 
> iPhone SDK does not seem to allow auto deletion to be used, which makes 
> a lot of sense and corresponds to what I've just said.
> 
> 

Objective-C 2.0 doesn't work on 10.4 and earlier, I think. (Or is it 1.3 and
earlier.) And I believe the iPhone doesn't support Objective-C 2.0 at all.

One advantage of using Objective-C is that the application can easily be
ported to the iPhone (if it makes sense for the program). But I hear Novell
have a solution for running .NET binaries on the iPhone hard-linked with
Mono using Windows Forms or Silverlight/Moonlight. So that advantage of
Objective-C's might not be relevant any more.

My experiences with the Compact Framework was limited to finding out that
Windows Mobile 5 supported .NET 1.1 and cannot be updated (at least on my HP
device) and that Visual Studio 2005 (the earliest I have and I refuse to
downgrade) supported .NET 2.0 and upwards. Hence I could never develop for
Windows Mobile and gave up. Apple seem to be a lot better with the software
update thing for mobile devices. The combination Xcode/iPhone works for me.

Thanks for all the input.

I'll be going with Delphi Prism. I am just waiting for Apple to release new
desktop machines because I need more than 3 GB of memory to use VMware
better. Plus I need more x86 hardware so I can play StarCraft 2!!! :-)

-- 
View this message in context: http://www.nabble.com/Delphi-Prism-and-all-those-Cocoa-bridges-tp22180106p22244195.html
Sent from the Mono - OSX mailing list archive at Nabble.com.