Petition for Delphi/Kylix on MacOS... 
Author Message
 Petition for Delphi/Kylix on MacOS...

Quote:

> If Borland can successfully be conviced to port Delphi/Kylix to Mac OS,
> then some thousands of source codes (some even from popular Windows
> applications) will be instantly available to be ported for the Mac with
> some mouse clicks and perhaps a few modifications of the source.

Or if Apple can successfully be convinced to build a Win32 subsystem into
Mac OS,
then some thousands of source codes (some even from popular Windows
applications)
will be instantly available to be ported for the Mac with some mouse clicks
and perhaps
a few modifications of the source.


Fri, 07 Oct 2005 23:07:41 GMT  
 Petition for Delphi/Kylix on MacOS...

Quote:

>> If Borland can successfully be conviced to port Delphi/Kylix to Mac OS,
>> then some thousands of source codes (some even from popular Windows
>> applications) will be instantly available to be ported for the Mac with
>> some mouse clicks and perhaps a few modifications of the source.

> Or if Apple can successfully be convinced to build a Win32 subsystem into
> Mac OS,
> then some thousands of source codes (some even from popular Windows
> applications)
> will be instantly available to be ported
> for the Mac with some mouse clicks and perhaps a few modifications of the
> source.

I think both statements (Delphi port will see Delphi apps run, and win32
subsystem will allow easy recompilation of existing windows app for Mac)
are totally unrealistic:

- A Delphi Mac OS X port would be CLX based anyway, and the majority of Delphi apps is
  still VCL based. I don't see many CLX apps.

- Delphi is moving in the direction of getting even more Microsoft specific with .NET.

- Both kind of code bases contain probably a quite a large deal of  x86/PC
  specific code. Both the win32 api and Delphi contain x86isms, Windowisms and PCisms.

Even if these problems didn't exist, look at the examples at hand. Linux has
both these things (Kylix and Wine), and while used, the large-scale use and migration
simply hasn't happened. Kylix is even free for non-commercial use.

Do you see Linux distributions come with a lot of Delphi or Kylix based
applications?

This is all wishful thinking, there is no silver bullet. There must really
be a large amount of software developpers for a platform (paid or not)
to get a large amount of software.



Sat, 08 Oct 2005 05:37:48 GMT  
 Petition for Delphi/Kylix on MacOS...

Quote:

> I think both statements (Delphi port will see Delphi apps run, and win32
> subsystem will allow easy recompilation of existing windows app for Mac)
> are totally unrealistic:

That was my point in making the statement "If Apple could be convinced to
build a Win32 subsystem into MacOS".

Quote:
> - A Delphi Mac OS X port would be CLX based anyway, and the majority of
Delphi apps is
>   still VCL based. I don't see many CLX apps.

You are right about CLX.  The VCL is totally dependent on the Win32 API.

Quote:
> - Delphi is moving in the direction of getting even more Microsoft

specific with .NET.

I've started some simple programming in .NET, both with C# and directly with
the IL assembly language.  Interestingly, this might actually be the bridge
between Delphi and the Mac operating systems.  There are some conditions
necessary for this to happen:
1)  Someone would have to implement a .NET Common Language Runtime for the
Mac OS.  Who should that someone be?  That will be the big question.  I've
heard the name ROTOR, but don't know if this is even related to Mac.
2)  If the .NET CLR is implemented for the Mac operating systems, it would
need to include additional assemblies that define Macintosh user interface
elements.  Currently, in the .NET Framework,  "System.Windows.Forms"
contains all the Windows GUI controls.  Apple would have to publish a
"System.Jaguar.Forms" assembly or something like that.
3)  The assembly containing all the Macintosh user interface elements would
have to be published and freely available to be installed into the .NET
Framework.

Quote:

> - Both kind of code bases contain probably a quite a large deal of  x86/PC
>   specific code. Both the win32 api and Delphi contain x86isms, Windowisms

and PCisms.

That's why I think 2) and 3) above are critical.  I'm used to developing
with Forms, Buttons, ListBoxes, etc., but the way I build a Windows
form-based application, does it directly translate to the way a Macintosh
application looks and behaves?  Likely not.  But if I have some .NET
components that are geared toward that approach, I can start to see some of
the subtle differences and know how to code accordingly.



Mon, 10 Oct 2005 20:33:05 GMT  
 Petition for Delphi/Kylix on MacOS...

Quote:

>> I think both statements (Delphi port will see Delphi apps run, and win32
>> subsystem will allow easy recompilation of existing windows app for Mac)
>> are totally unrealistic:

> That was my point in making the statement "If Apple could be convinced to
> build a Win32 subsystem into MacOS".

So that was what I meant. That that would matter much is unrealistic, due to the
PPC nature of the Mac, and x86 and PCisms in the code.

Quote:
> You are right about CLX.  The VCL is totally dependent on the Win32 API.

It is not really bad, but too bad for easy recompilation.

But I'm not sure about the CLX either. Does it contain QT/Win32 isms (qt has
a structure that somewhat resembles win32, what if I take a totally
different widget set?), PCisms, x86isms etc.

Quote:
>> - Delphi is moving in the direction of getting even more Microsoft
> specific with .NET.

> I've started some simple programming in .NET, both with C# and directly with
> the IL assembly language.  Interestingly, this might actually be the bridge
> between Delphi and the Mac operating systems.  There are some conditions
> necessary for this to happen:

I doubt it. Unless a major vendor does this, it will either take too long,
or not happen at all.

Which is the problem with the .NET multi-platform credibility. Why isn't
there a large alliance in cooperation with Microsoft? We need Microsofts
cooperation so that they don't spoil their own system with all kinds of
Windows specific and x86 specific code.

.NET multi-platform was born dead.

Quote:
> 1)  Someone would have to implement a .NET Common Language Runtime for the
> Mac OS.  Who should that someone be?  That will be the big question.  I've
> heard the name ROTOR, but don't know if this is even related to Mac.

It is all academic stuff, suitable to do some educational demonstration stuff, worse
than the average open source multi platform widget set.

The problem is not the processor and baselevels. There are several
multi-architecture compilers and basic libraries.

The problem is everything on top, and CLR doesn't solve that, since the all that
extra stuff isn't avialable for CLR either. And CLR has the problem that you have
to get in bed with Microsoft.

(Microsoft's financial status allows them to confine .NET to some niche like
the more specialised parts of webprogramming if it doesn't make it as
desktop-and-general-purpose API and development system. At that point, all
those precious Open Source man years to target and cooperate with .NET go
down the drain)

Quote:
> 2)  If the .NET CLR is implemented for the Mac operating systems,

... you can make simple console programs for the Mac. Nothing more.

Quote:
> it would need to include additional assemblies that define Macintosh user
> interface elements.

Which means they only run on Mac, so nothing is gained. You can probably do that now
on the Mac using the normal Mac RAD development tools, which don't work with Windows either,
just like your CLR with mac assembly widgets.

IOW CLR doesn't earn you anything.

Quote:
>> - Both kind of code bases contain probably a quite a large deal of  x86/PC
>>   specific code. Both the win32 api and Delphi contain x86isms, Windowisms
> and PCisms.

> That's why I think 2) and 3) above are critical.  I'm used to developing
> with Forms, Buttons, ListBoxes, etc.,

That doesn't come with CLR. You'll have to anyway, just enhance the
development systems you have.

It would be probably much easier to enhance KDevelop or some Java IDE for the Mac.

CLR is starting from scratch, with the only benefit that small console apps will work
on Windows too. (which pretty much works for any language nowadays)

Quote:
> but the way I build a Windows form-based application

That has nothign to do with Windows. You want a RAD, which is just a program you write that
integrates with the compiler and the editor. No need for manyear porting etc of CLR. Just take
gcc, or better an free existing functional Mac development system as starting point.

, does it directly translate to the way a Macintosh application looks and

Quote:
> behaves?

Probahly not, but none will.

Quote:
> Likely not.  But if I have some .NET components that are geared toward
> that approach,

There are none. The only GUI stuff will be in Win32 only assemblies, and even if they were,
they are not free. Only the basic compiler and runtime are.

.NET is not evil, actually it is pretty thorough. However, without
Microsofts active support (or major partners that can stand up to it), multi platform potential
for non trivial apps is zero. At least if you want compability with Windows.

A multiplatform  application development system is more than a reasonably
clean basesystem. Everything must be developped with multi-platform issues
in mind, compiler, base libraries, tools, GUI libraries etc etc.

I've a strong feeling Micrsoft wants .NET to be architecture independant,
but not Windows independant.

- Architecture independant, so the avg application would become be less architecture dependant,
   which would decrease the platform dependance of Micrsofts most valued
   asset, but also burden sometimes: the inertia of the installed application base.
- Platform dependant: so that they don't cut their own revenue stream.
- And of course to provide an alternative to Java, of which they control vital parts.

IOW Microsoft is preparing for a architecture merge a la Apple's m68k->PPC
shift. That doesn't mean this is going to happen soon, it just wants to be
_able_ to do it in the next decade, with some easy migration path for
applications written from now to then.

---

That doesn't mean .NET can't be used for multiplatform solutions, but
everything, including the windows port would have to be developped on top of
the small, Microsoft provided subsystem. (and it is small, as a small team
at Ximian could duplicate it in months as Mono, and Mono is larger than Rotor)

So the benefit would simply be zero.



Mon, 10 Oct 2005 23:43:09 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Petition for Delphi/Kylix on MacOS...

2. Is Kylix Delphi for Linux?

3. Borland Pascal 8 Petition: FIRST RESULTS

4. Borland Pascal PETITION - PLEASE VOTE !

5. kylix - pascal compiler

6. Info on Kylix

7. Kylix starting problem

8. Q: Linux Kylix socket example?

9. Kylix newsgroup?

10. kylix & mysql

11. MSSQL from kylix

12. dbExpress + PostgreSQL (Kylix 2 + Linux)

 

 
Powered by phpBB® Forum Software