The new Delphi 2010 RTTI

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Sven Barth-2
Am 09.01.2011 22:03, schrieb [hidden email]:

> 24.12.2010 17:31, Sven Barth пишет:
>>
>> Yeah... and only works on i386- and x86_64-linux.
>>
>> Runtime packages will come sooner or later, maybe not this year (ok...
>> that's hard to beat ^^) and maybe not next year. But when they come
>> they'll be implemented in a good cross platform way without such
>> hackish approaches like requiring Wine or some other big dependencies.
>>
>>
>
> I mentioned WINE only as as example of possibility to use native
> binaries from one platform in another. FPC should use own format of
> dynamic library and own dynamic linker code embedded into executable.
> This solution could be crossplaform.

No, FPC should rely on the operating system for dynamic linking. There
is no use in duplicating a functionality that is already there. One
"just" needs to spot all problems that might arise on different
platforms when using dynamic libraries (e.g. symbol resolution on
Windows vs. ELF based systems).

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
10.01.2011 12:05, Sven Barth пишет:
> No, FPC should rely on the operating system for dynamic linking. There
> is no use in duplicating a functionality that is already there. One
> "just" needs to spot all problems that might arise on different
> platforms when using dynamic libraries (e.g. symbol resolution on
> Windows vs. ELF based systems).
>
> Regards,
> Sven
>
If so, there must be an executable format supported by all FPC target
platforms natively. I don't know any such format. We have to duplicate
some OS functions to make things crossplatform.

Alex.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

michael.vancanneyt


On Mon, 10 Jan 2011, [hidden email] wrote:

> 10.01.2011 12:05, Sven Barth пишет:
>> No, FPC should rely on the operating system for dynamic linking. There is
>> no use in duplicating a functionality that is already there. One "just"
>> needs to spot all problems that might arise on different platforms when
>> using dynamic libraries (e.g. symbol resolution on Windows vs. ELF based
>> systems).
>>
>> Regards,
>> Sven
>>
> If so, there must be an executable format supported by all FPC target
> platforms natively. I don't know any such format. We have to duplicate some
> OS functions to make things crossplatform.
Why ?
There is no need for that; You can perfectly use the OS functionality.
All you need to do is add a layer on top which hides the OS specifics.
Borland could do it, so we can do it too.

The main problem is the Windows target where a library is more like a
self-contained exe. On Linux (and probably Mac OS), libraries already
work as packages are intended to work.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Matt Emson-2
In reply to this post by Alexander Shishkin
On 10/01/2011 09:26, [hidden email] wrote:
>
> If so, there must be an executable format supported by all FPC target
> platforms natively. I don't know any such format. We have to duplicate
> some OS functions to make things crossplatform.

I don't think that is what Sven meant. I think the executable format
would be that of the native platform. However, the interface to the
library (the exported symbols and such) would be a common interface that
abstracts away the specifics of the underlying OS Library loading routines.

M
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
In reply to this post by michael.vancanneyt
10.01.2011 12:50, [hidden email] пишет:

>
>
>
> Why ? There is no need for that; You can perfectly use the OS
> functionality.
> All you need to do is add a layer on top which hides the OS specifics.
> Borland could do it, so we can do it too.
>
> The main problem is the Windows target where a library is more like a
> self-contained exe. On Linux (and probably Mac OS), libraries already
> work as packages are intended to work.
>
> Michael.
>
Delphi package is standart DLL with PE file format - it is not portable
without things like Wine for example.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Sven Barth-2
In reply to this post by Matt Emson-2
Am 10.01.2011 10:58, schrieb Matt Emson:

> On 10/01/2011 09:26, [hidden email] wrote:
>>
>> If so, there must be an executable format supported by all FPC target
>> platforms natively. I don't know any such format. We have to duplicate
>> some OS functions to make things crossplatform.
>
> I don't think that is what Sven meant. I think the executable format
> would be that of the native platform. However, the interface to the
> library (the exported symbols and such) would be a common interface that
> abstracts away the specifics of the underlying OS Library loading routines.

Simply spoken, yes, that's what I meant.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
In reply to this post by Matt Emson-2
10.01.2011 12:58, Matt Emson пишет:

> On 10/01/2011 09:26, [hidden email] wrote:
>>
>> If so, there must be an executable format supported by all FPC target
>> platforms natively. I don't know any such format. We have to
>> duplicate some OS functions to make things crossplatform.
>
> I don't think that is what Sven meant. I think the executable format
> would be that of the native platform. However, the interface to the
> library (the exported symbols and such) would be a common interface
> that abstracts away the specifics of the underlying OS Library loading
> routines.
>
> M
>
But I want packages to be binary portable between OS (on target
processor architecture)
Alex

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Vincent Snijders-3
2011/1/10 [hidden email] <[hidden email]>:
>>
> But I want packages to be binary portable between OS (on target processor
> architecture)


I don't think that is feasible, unless you don't use any OS features.

Vincent
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

michael.vancanneyt


On Mon, 10 Jan 2011, Vincent Snijders wrote:

> 2011/1/10 [hidden email] <[hidden email]>:
>>>
>> But I want packages to be binary portable between OS (on target processor
>> architecture)
>
>
> I don't think that is feasible, unless you don't use any OS features.

Exactly.

Even just because FPC supports multiple CPUs; You can't use an i386 package on SPARC or ARM.

So you'll always have to recompile your package for all platforms that you want to support.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Sven Barth-2
In reply to this post by Alexander Shishkin
Am 10.01.2011 11:00, schrieb [hidden email]:

> 10.01.2011 12:50, [hidden email] пишет:
>>
>>
>>
>> Why ? There is no need for that; You can perfectly use the OS
>> functionality.
>> All you need to do is add a layer on top which hides the OS specifics.
>> Borland could do it, so we can do it too.
>>
>> The main problem is the Windows target where a library is more like a
>> self-contained exe. On Linux (and probably Mac OS), libraries already
>> work as packages are intended to work.
>>
>> Michael.
>>
> Delphi package is standart DLL with PE file format - it is not portable
> without things like Wine for example.

FPC packages won't use PE format on non Windows systems, but Mach-O on
Mac OS X and ELF on Linux.

The main point with packages is that a package is a libary that can be
loaded at runtime with some compiler magic. It is not important whether
this is called DLL or SO or what binary format that library consists of.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
In reply to this post by michael.vancanneyt
10.01.2011 13:05, [hidden email] пишет:

>
>
> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>
>> 2011/1/10 [hidden email] <[hidden email]>:
>>>>
>>> But I want packages to be binary portable between OS (on target
>>> processor
>>> architecture)
>>
>>
>> I don't think that is feasible, unless you don't use any OS features.
>
> Exactly.
>
> Even just because FPC supports multiple CPUs; You can't use an i386
> package on SPARC or ARM.
>
> So you'll always have to recompile your package for all platforms that
> you want to support.
>
>
But only for all processors, not for all existing combinations of
processor and OS.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

OS independent packages was Re: [fpc-pascal] The new Delphi 2010 RTTI

Florian Klämpfl
Am 10.01.2011 11:16, schrieb [hidden email]:

> 10.01.2011 13:05, [hidden email] пишет:
>>
>>
>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>
>>> 2011/1/10 [hidden email] <[hidden email]>:
>>>>>
>>>> But I want packages to be binary portable between OS (on target
>>>> processor
>>>> architecture)
>>>
>>>
>>> I don't think that is feasible, unless you don't use any OS features.
>>
>> Exactly.
>>
>> Even just because FPC supports multiple CPUs; You can't use an i386
>> package on SPARC or ARM.
>>
>> So you'll always have to recompile your package for all platforms that
>> you want to support.
>>
>>
> But only for all processors, not for all existing combinations of
> processor and OS.

The rtl package is OS specific anyways and as soon as you depend on the
rtl package (an fpc package will always depend on it), you need to build
your package for any FPC version, processor and OS combination.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: OS independent packages was Re: [fpc-pascal] The new Delphi 2010 RTTI

Alexander Shishkin
10.01.2011 13:19, Florian Klaempfl пишет:

> Am 10.01.2011 11:16, schrieb [hidden email]:
>> 10.01.2011 13:05, [hidden email] пишет:
>>>
>>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>>
>>>> 2011/1/10 [hidden email]<[hidden email]>:
>>>>> But I want packages to be binary portable between OS (on target
>>>>> processor
>>>>> architecture)
>>>>
>>>> I don't think that is feasible, unless you don't use any OS features.
>>> Exactly.
>>>
>>> Even just because FPC supports multiple CPUs; You can't use an i386
>>> package on SPARC or ARM.
>>>
>>> So you'll always have to recompile your package for all platforms that
>>> you want to support.
>>>
>>>
>> But only for all processors, not for all existing combinations of
>> processor and OS.
> The rtl package is OS specific anyways and as soon as you depend on the
> rtl package (an fpc package will always depend on it), you need to build
> your package for any FPC version, processor and OS combination.
>
I have a few drafts of another design
http://wiki.freepascal.org/User:AlexVinS/Packages

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

michael.vancanneyt
In reply to this post by Alexander Shishkin


On Mon, 10 Jan 2011, [hidden email] wrote:

> 10.01.2011 13:05, [hidden email] пишет:
>>
>>
>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>
>>> 2011/1/10 [hidden email] <[hidden email]>:
>>>>>
>>>> But I want packages to be binary portable between OS (on target processor
>>>> architecture)
>>>
>>>
>>> I don't think that is feasible, unless you don't use any OS features.
>>
>> Exactly.
>>
>> Even just because FPC supports multiple CPUs; You can't use an i386 package
>> on SPARC or ARM.
>>
>> So you'll always have to recompile your package for all platforms that you
>> want to support.
>>
>>
> But only for all processors, not for all existing combinations of processor
> and OS.
You should re-read Florian's email, and *fully* understand the consequences.

Your proposal requires that we emulate all OSes on all other OSes, because
the basic package (rtl or whatever it will be called) always depends on the
OS. There is no way around this.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
10.01.2011 13:50, [hidden email] пишет:

>
>
> On Mon, 10 Jan 2011, [hidden email] wrote:
>
>> 10.01.2011 13:05, [hidden email] пишет:
>>>
>>>
>>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>>
>>>> 2011/1/10 [hidden email] <[hidden email]>:
>>>>>>
>>>>> But I want packages to be binary portable between OS (on target
>>>>> processor
>>>>> architecture)
>>>>
>>>>
>>>> I don't think that is feasible, unless you don't use any OS features.
>>>
>>> Exactly.
>>>
>>> Even just because FPC supports multiple CPUs; You can't use an i386
>>> package on SPARC or ARM.
>>>
>>> So you'll always have to recompile your package for all platforms
>>> that you want to support.
>>>
>>>
>> But only for all processors, not for all existing combinations of
>> processor and OS.
>
> You should re-read Florian's email, and *fully* understand the
> consequences.
>
> Your proposal requires that we emulate all OSes on all other OSes,
> because
> the basic package (rtl or whatever it will be called) always depends
> on the OS. There is no way around this.
>
My solution, in short,  is that packages should have OS independent
interface to RTL built into executable visible to packages as RTL built
as c package (with is a bridge to real RTL).
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

michael.vancanneyt


On Mon, 10 Jan 2011, [hidden email] wrote:

> 10.01.2011 13:50, [hidden email] пишет:
>>
>>
>> On Mon, 10 Jan 2011, [hidden email] wrote:
>>
>>> 10.01.2011 13:05, [hidden email] пишет:
>>>>
>>>>
>>>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>>>
>>>>> 2011/1/10 [hidden email] <[hidden email]>:
>>>>>>>
>>>>>> But I want packages to be binary portable between OS (on target
>>>>>> processor
>>>>>> architecture)
>>>>>
>>>>>
>>>>> I don't think that is feasible, unless you don't use any OS features.
>>>>
>>>> Exactly.
>>>>
>>>> Even just because FPC supports multiple CPUs; You can't use an i386
>>>> package on SPARC or ARM.
>>>>
>>>> So you'll always have to recompile your package for all platforms that
>>>> you want to support.
>>>>
>>>>
>>> But only for all processors, not for all existing combinations of
>>> processor and OS.
>>
>> You should re-read Florian's email, and *fully* understand the
>> consequences.
>>
>> Your proposal requires that we emulate all OSes on all other OSes, because
>> the basic package (rtl or whatever it will be called) always depends on the
>> OS. There is no way around this.
>>
> My solution, in short,  is that packages should have OS independent interface
> to RTL built into executable visible to packages as RTL built as c package
> (with is a bridge to real RTL).
I understood that. Assuming you can make this interface (which I don't
believe), your solution is still not realistic:

And how will you make a package that uses a os-specific function OS independent ?
(for instance, a package with a control that uses a WinAPI call.)

So a package with the LCL is by definition impossible.

Like I said, your proposal requires that we emulate all OSes on all other OSes.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Cees Binkhorst
In reply to this post by michael.vancanneyt
To split some hairs ;)

Level the OS's with an addition (or some additions) and program the
universal application on top of that.
This makes the application lighter AND portable.

Regards / Cees (who has no practical experience with
fpc-pascal/Lazarus/Freepascal i.e. a lurker)

On 01/10/2011 11:05 AM, [hidden email] wrote:

>
>
> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>
>> 2011/1/10 [hidden email] <[hidden email]>:
>>>>
>>> But I want packages to be binary portable between OS (on target
>>> processor
>>> architecture)
>>
>>
>> I don't think that is feasible, unless you don't use any OS features.
>
> Exactly.
>
> Even just because FPC supports multiple CPUs; You can't use an i386
> package on SPARC or ARM.
>
> So you'll always have to recompile your package for all platforms that
> you want to support.
>
> Michael.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Matt Emson-2
In reply to this post by michael.vancanneyt
On 10/01/2011 11:09, [hidden email] wrote:
>
> Like I said, your proposal requires that we emulate all OSes on all
> other OSes.

Or create a VM layer that levels the OS level differences - but again,
why do this? Creating such a VM is probably a magnitude of complexity
over just using the tools already available and requiring a
recompilation to target each platform.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Cees Binkhorst
In reply to this post by michael.vancanneyt


On 01/10/2011 12:09 PM, [hidden email] wrote:

>
>
> On Mon, 10 Jan 2011, [hidden email] wrote:
>
>> 10.01.2011 13:50, [hidden email] пишет:
>>>
>>>
>>> On Mon, 10 Jan 2011, [hidden email] wrote:
>>>
>>>> 10.01.2011 13:05, [hidden email] пишет:
>>>>>
>>>>>
>>>>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>>>>
>>>>>> 2011/1/10 [hidden email] <[hidden email]>:
>>>>>>>>
>>>>>>> But I want packages to be binary portable between OS (on target
>>>>>>> processor
>>>>>>> architecture)
>>>>>>
>>>>>>
>>>>>> I don't think that is feasible, unless you don't use any OS features.
>>>>>
>>>>> Exactly.
>>>>>
>>>>> Even just because FPC supports multiple CPUs; You can't use an i386
>>>>> package on SPARC or ARM.
>>>>>
>>>>> So you'll always have to recompile your package for all platforms
>>>>> that you want to support.
>>>>>
>>>>>
>>>> But only for all processors, not for all existing combinations of
>>>> processor and OS.
>>>
>>> You should re-read Florian's email, and *fully* understand the
>>> consequences.
>>>
>>> Your proposal requires that we emulate all OSes on all other OSes,
>>> because
>>> the basic package (rtl or whatever it will be called) always depends
>>> on the OS. There is no way around this.
>>>
>> My solution, in short,  is that packages should have OS independent
>> interface to RTL built into executable visible to packages as RTL
>> built as c package (with is a bridge to real RTL).
>
> I understood that. Assuming you can make this interface (which I don't
> believe), your solution is still not realistic:
>
> And how will you make a package that uses a os-specific function OS
> independent ? (for instance, a package with a control that uses a WinAPI
> call.)
>
> So a package with the LCL is by definition impossible.
>
> Like I said, your proposal requires that we emulate all OSes on all
> other OSes.

Looking from the top (the user), is that not what is done now?

All applications have the same user-interface for different OS's. So by
definition what is in-between is part application and part
'normalisation' of the OS.

Regards / Cees (who has no practical experience with
fpc-pascal/Lazarus/Freepascal i.e. a lurker)


>
> Michael.
>
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
In reply to this post by michael.vancanneyt
10.01.2011 14:09, [hidden email] пишет:
>
>
> I understood that. Assuming you can make this interface (which I don't
> believe), your solution is still not realistic:
>
> And how will you make a package that uses a os-specific function OS
> independent ? (for instance, a package with a control that uses a
> WinAPI call.)
>
Of course nohow. But this package is not portable by desing and could be
simply loaded, load needed OS libraries and execute.
> So a package with the LCL is by definition impossible.
>
LCL itself is by design crossplatform. And if component developers don't
use OS and widget set functions directly the are crossplatform to.
Widget sets (and any platform dependend code) should be isolated in
separate packages, LCL application load widget set package at startup
and use it. It is only impossible to switch widget sets at runtime.

So with packages Application can use ANY widget set.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123