Re: Cross platform - an interim proposal

On 2007-06-18, David Ninnes <david_ninnes@xxxxxxxxxxx> wrote:
Hi Marco,
This is why I suggested shared libraries only, that way any linking to
static libs shouldn't be necessary?

Shared libraries are also Mach-O. Generatingshared libs is generally harder
than static linking, so that doesn't save anything.

And you want to be able to use anything OS related (as simple as simple file
IO) from that shared lib, don't you?
Not necessarily, I was thinking a compatability layer external to the
shared library for OS access. Here's a simple example, say you've got an
algorithm to blur a bitmap in delphi. Ignore the inconvenient fact of
different rgba ordering for the purposes of example.

Your routine's input is a chunk of memory, you do something to the
memory and send it back out. On windows I could put that routine in a
dll, the input would be a memory pointer, I could call that DLL from any
app and it wouldn't matter what the calling language was.

Yes. And you want to base a product raison d'etre on that? Throw some dosh at the
crosskylix guys, and they can probably create some kylix postprocessor for
that :-)

Note that you can't even allocate a byte of memory in it, or use an
automated type (string, dyn array) since that involves memory management
which is OS connectivity.

I suppose what I'm considering is a simple pascal compiler that can
output a shared library in much the way a C compiler would.

Well, there is the problem. Compilers don't output shared libraries. Linkers
do. And it is not that different from producing an exe. And a shared library
for every binary format is different. And Darwin has an unique binary
format.

With the exe you have to satisfy some boundery conditions and link to the
startup code, but with the DLL you stress the binary format way more (think
PIC, indirection tables, relocation etc)

It seems you don't like Free Pascal, but even if you don't use it, it can be
a good thing to study and play with to get a feel for how things work.

I think this would be a necessary first step in creating any cross
compiler. Layered on top of that is Delphi object management, then the
VCL and all the OS dependent code.

That is already *HUGE*. You first app will typically be a hello world. But
as soon as you start to use libraries, you will have to take the earlier
named hurdles like callling conventions and binary format.

And then you need to port the RTL, then the VCL. Recent bad news there,
Apple seems to be deprecating Carbon, which is a natural fit for the VCL.
This means you also might need Objective C connectivity.

For anything that has a dependancy (shared lib or exe), static or shared,
you need the libraries on target. At least straight up. If the linker can
avoid this, it doesn't do it default.

So in the example above, you'd compile your .dll or .so or whatever the
mac calls them and copy them to the Mac, when your mac app runs the run
time linker resolves the symbols (ld from memory on Unix systems).

ld.so or ld-elf.so if there are multiple supported. ld is the normal linker.

But to my knowledge the unix linking process resolving is not on name. This
requires libraries on the linking host. (the place where you create the
lib).

At least that is the standard practice. Afaik ELF does support this, but
this is not commonly done (probably it would blow up *nix distributions only
unnecessary)

It's a register convention, registers that contain floating point values are
skipped, alignment requirements, small records passed in registers.

Please readup before you dismiss it so easily.

I wasn't dismissing it, I realise it's a hard thing to do, but it's also
well defined.

Yes. But in practice you run into all kinds of freak problems. Also with
language constructs C/ABI don't support. (like e.g. sets)

Whereaas the cross compatible ideal of a VCL that runs on a
Mac and Windows is very hard.

Yes. That is even harder of course.

What I'm thinking is, is it possible to get this small chunk of a cross
compatible solution in a fairly small time frame, later we can get the
full solution, but realistically that is a number of years away.

The problem is that both stages require a directed effort from the core
compiler group (is this a separate group at Borland?), usually the hardest
to get hold of.

It is not some byproduct of e.g. a research or a productsupport department.

Here's my idea of how it would work. You have a Mac running parallels
with windows, in the parallels session Delphi is running, You compile
your delphi library. On the Mac session it has a mapping to the same
file system that you've just created your library on, you run your Mac
app and develop away with your Delphi library. I'm not sure how
debugging would work - it's outside my experience, perhaps someone else
has an idea.

How easier you want it, the more complex the result is. Debugging is even
harder. (since that would mean you would have to have two debuggers in the
IDE, one that understands the Mac format, and one that does PE).

Also what you want is very vague.

In developing a cross platform VCL you'd need something like this
anyway.

Yes. But keep in mind the next question for that is "what API will you use",
since the likely candidate on OS X seems to have been deprecated for 64-bit use this
week.

The questions are
1) could anyone else use something like this (apart from me)
2) how long would it take, a few man months?

If you reuse stuff, without debugging, it can be fast. But you need a die
hard compiler devel that has read the subject.

I believe Jonas did the basic port in a few days (over newyear), a minimal RTL
based on the C runtime was already created a bit earlier by me. To hello world
level, but he had the whole compiler running a few days later.

Problems in the calling conventions and debug persisted for over a year
though.

Crosscompiling came a bit later when the target stabilised. It is hard to
quantify that in time, since I first crosscompiled to easier targets,
and because the project was in frantic development before the 2.0 release.

But after I got the relevant crosslinkers fleshed out, I guess it was a
matter of a few free weekend hobbying.

To my knowledge I'm the only person in the world that has ever crosscompiled
Delphi code from Windows to OS X (powerpc still). (the whole project
codebase including the GUI IDE, Lazarus to be exact). So yes, that can be
done.

Of course we didn't make the linkers ourselves, but used Darwin's or GNU's.

3) is it feasible, I suspect the answer is yes

Feasability technically was never the issue. If FPC can do it in their spare
time, I might hope that the fulltimers of Borland are capable enough :-)

But the devil is in the details. Is it worthwhile financially (specially
given the Kylix failure)? Can it be supported?

Don't underestimate the latter. Delphi users typically want very smooth
products, and all these raw-implementation of the concept work is dwarfed by
the effort to make it all run smooth, configurable etc.

The problem is not if the technical department can do it, but if they can
make time from more profitable projects, and if the end result can be
polished enough.

You yourself already hinted that your expectations are the same, since you
dismissed FPC. IOW you want the full monty, not some skeleton product.

4) is it possible to marshall delphi objects to objective C objects -
this is a nice to have and could probably come later.

Not directly. Objective C object mode l ise way more runtime (runtime adding of methods,
method calls are done via a central dispatch iirc).

The mac team is currently investigating some simple language extensions to
make this easier, mostly mimiced from Object Modula2 proposals.

Most apps that I see are Carbon apps that originate on classic Mac. Adobe,
Netscape/Mozilla, Office. I don't know about OpenOffice, it might use the
Java COCOA bridge, but it is certainly not crafted in XCode. The same for
the LaTeX editor LyX that I use (--framework Carbon)
From my brief reading, it seems the OS components are a little richer
on the Mac than the windows components?

Not that I know. The visual makeup (rendering) looks a bit more modern, but
afaik Windows has way more and more compelx widgets. Plain applications have
the same look and feel as plain Windows apps. Only the blob shaped and the
ones provided by the OS vendor are more elaborate (compare Media Player and
Office 2007' ribbon on Windows).

So unless you really want to focus on the makeup, I think the different UI
conventions are way more important:
- only one menu bar
- lot more drag and drop use.
- keyboard handling is different.

etc.

Well, and that is also the problem with Mac development. The usergroup
usually uses a small set of applications (iLife) that come with the machine,
and there hardly is a business group requesting custom software.

But there is a market for consumer apps, and the rumor is that Mac users
are more used to paying for apps than windows users, not sure how true
that is.

Yes. The ones that do buy apps yes. But keep in mind most of the Apple users
DONT BUY APPS. They use the set that comes with the Mac.

Don't take my word for it. There must be figures for Mac software purchases.
Try to estimate what the market is worth minus the big players (Office and
Adobe mostly, maybe also factor out games)

I do know for a fact that the software shelf in a Mac store only contains
Apple software, games and Adobe/MS. Few independant vendors......

Also the academic market is a big Mac user in my experience and
they are prepared to pay for the right app, also these apps are very
specialist and suit Delphi style development.

I heard that the academia use a bit more Mac's in the US yes. However not
this side of the pond.

One big advantage this approach would have, would be that delphi
developers and CG would have more time to learn the oddities of the Mac
OS and so when it comes time to build the VCL solution, they would be a
lot better placed to build it.

You can say that about _ANY_ port. That doesn't mean it is worth the trouble
for CG.

I realise that this isn't a rolls royce solution, more a VW bug held
together with duct tape, but I think it would get a cross platform
solution going in a comparativeley small amount of time

Then use FPC. It is already there.

Also, undoubtedly a third party library market would grow around this,
if only out of necessity.

I doubt it. The Delphi component market is already in decline (how many big
newcomers do you see annually?). If the VCL would be compatible enough, you'd see
the Kylix effect that a few big component vendors would port to it.

But Kylix was a fuller product than what you are suggesting. (like .e.g the
component vendors would have to be able to debug)

Does that sound feasible? Can anyone else use it?

Honestly? (despite the negative feelings): I don't know. Before Kylix I
would have said automatically yes, but now I'm not so sure anymore.

.

Relevant Pages

  • Re: What is more efficient (*.a or *.so) libraries?
    ... I used these libraries to create CGI ... running 5 different apps (all using the ... there is even further benefit: shared libraries on AIX are ... executions of the same app using a given shared library ...
    (comp.unix.aix)
  • Re: comments on OCaml?
    ... > apps that go into it. ... > foot with the way shared libraries have become the de facto standard way ... the Microsoft went through with shared libraries. ... Paradise Green Technical Services: ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Gnat says libraries are not supported.
    ... generate any shared libraries. ... Funny that you say - the Mac OS X 4.3 says the same. ... gprbuild is quite capable of building shared libraries on Mac ... OS X with both GCC 4.3.3 and GNAT GPL 2009. ...
    (comp.lang.ada)
  • Re: libraries in /usr/lib64
    ... lib it is. ... for shared libraries etc? ... and rpm says there are dependencies on two missing libraries: ... Try installing the 32-bit libraries or 64-bit apps. ...
    (linux.redhat)
  • Re: OSX may be even more complicated the Linux.
    ... But is an application on OSX a single file? ... In UNIX, apps get ... The Mac was was odd. ... up more disk space (and RAM, since shared libraries aren't really ...
    (comp.sys.mac.advocacy)