On Tue, 21 May 2002 15:05:51 +0200 (MET DST), Doodle wrote:
>> But for this requred classes and sysutils modules. Classes uses sysutils.
>> For sysutils requred pmhelp. But pmhelp uses apphandle function wich
>> defined in system unit. But fpc system unit doesn't contain this or equal
>> function :( This is problem number one. Second problem is exceptions. My
>> current hack is incorrect (in bsedos.pas). SysException must be rewrited
>> as child of fpc root exception class.
>And you will find a lot more problems with different implementation of
>exceptions under FPC and Sibyl.
No. SysException class not presented in FPC and SysException is base exception class
for Sibyl. If implement SysException on top of fpc base exception class then no
problems and good integration.
>Then, there are problems with the basic Object type. Sibyl has different
>implementation and methods, which are used by the Sibyl GUI too (in the
>object inspector window).
Methods less or more same. Implementation can have (and have) different implementation.
>That's the main reason why I thought that I should better port the full
>sibyl sources (system.pas and others) to FPC than change the FPC sources
>for Sibyl.
Rewrite System unit? Why? System units is same (except some nonstandard functions).
And rewrite system unit not good idea.
>[...]
>> All work must be based on at least fpc system unit.
>Err... Sorry, it might be a stupid question, but why? :)
Because this allows use same runtime. Why work with same thing? Lets fpc team work
with rtl. Why remake this work?
>> I know about future problems with sibyl applications. Some rework will be
>> required for migration to OpenSibyl (At least for application wich uses
>> imports, APIENTRY, CSTRING, C style comments (/*) and some other things).
>Yep.
Translate, pls.
>> PS: I'm not sure, but we can have problems with 16-bit function calls for
>> console apps.
>That needs thunking, that is, IMHO, implemented in the Sibyl sources.
>(One more pro for using them instead of the FPC RTL..;)) )
In EMX thunking implemented in emxwrap.dll. I don't want change compiler and linker.
Trying to be fully Sibyl Compatible is bad idea. I don't want change compiler and
native rtl.
There are two major preferences of native rtl instead of porting sibyl.
1) Duplicate work. System, Dos, Crt and some other units less or more same. Why
reimplement same things?
2) Same compiler, same linker, same rtl make our live easy.
After porting of pm* and bse* units to fpc we can, first of all, have common os/2 api
as for sibyl as for fpc. This allows don't devide applications to "fpc applications"
and
"sibyl applications".
If classes library will be on top of fpc classes then this allow us use fpc units
without problems (for example, xml/xhtml parser).
Do you want port each unit, developed for fcl to spcc? I don't want.
I prefer do work on this basis:
1) use native fpc rtl (system, dos, crt, sysutils)
2) use sibyl os2 api (os2def, bse*, pm*)
3) use native fcl as base for spcc (classes)
4) use spcc as base for svde
This allows use _any_ fpc units and programs without any problems. And port SVDE
without big problems.
5) Add to spcc all methods and properities from delphi vcl (this is allow use delphi
apps based on vcl)
6) May be add Odin32 API (this is allow use delphi apps based on win32 api)
When 2) will be done, we can contibute os2 api definetion to fpc/2 team.
Of couse, I don't work with fpc sysutils and classes now. But after success
compilation of SVDE on top of fpc I will work with spcc on top of fcl.
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
