Board index » kylix » ANN: Universal Object Pascal Library (UOPL)

2004-11-05 11:06:04 PM
kylix2
ANN: Universal Object Pascal Library (UOPL)
sourceforge.net/projects/uopl/
The goal of the project is to develop a cross product
(initial Delphi and Free Pascal / Lazarus) development
library. This will allow the developer to choose between
the standard libraries (VCL and LCL) and use the UOPL in its
place. Programs will seamlessly move between the two
products allowing you to compile for W32, AMD64, Linux and
Mac OS X. In addition, major improvements will be added to
the library including full UNICODE support. The project is
currently looking for interested developers. We are in need
of programmers with a strong background in UNICODE,
variants, and the GTK+ library.
Please contact me if you are interested in joining the project.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

On 2004-11-05, Thomas Miller < XXXX@XXXXX.COM >wrote:
broad in their statements. (to your credit, you don't mention C# and JVM)
However what I miss is even a very skimpy description on how you want to
tackle the obvious problems (VCL being Windows centric, message passig based and
copyrighted, LCL being slightly GTK biassed, and methodproc based, FPC and Kylix
having totally different Unix runtime units etc).
Moreover, why do you need to program GTK+ btw, if you base on higher level toolkits
as VCL and LCL?
 

Thomas Miller schrieb:
Thanks!
 

{smallsort}

Marco van de Voort wrote:
Until the compiler and IDE are opened up, then Kylix is a
dead end solution. But lets not argue about that. None of
us have a crystal ball.
The Lazarus project has already rewritten most of the core
VCL as open source. So there is no copyright issue if we
start with their code.
The Linux version is based mostly on GTK (as Kylix is based
mostly on QT). GTK doesn't have a licensing issue for using
it on commercial projects / products (that QT has).
Delphi and Chrome are the future for managed code. IMO,
Free Pascal and Lazarus are the future of native code.
The problem is that I need to (and want to) live in both
worlds for the next 5 years (at least). The biggest problem
is a consistent library. This is what this project is all
about. Taking the idea of CLX and making it work with
Delphi and Lazarus (any one here want native 64bit, win32,
Linux, and Mac support?).
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

We will be using a similar model to Lazarus using include
files. I haven't had time to dig down deep yet, but is
seems that the structure could be cleaned up a bit.
So for instance
/Source
/uopl
class.pas //Only ifdefs with includes
/includes
ClassDelphiWin.inc
ClassFPLWin.inc // Free Pascal Lazarus
ClassLinuxGTK.Inc
ClassMacGTK.Inc
ClassMacCarbon.Inc
This is something we will discuss immediately as well as
where to start the fork in the object hierarchy (TObject,
TPersistant, or somewhere in between).
We don't want to replace what is there, but have an
alternative. Every object will be named TuoplXXXXX or
TuoplClass.
If you want to be in on the discussion, join the list
sourceforge.net/mail/
I plan on starting things up on Wednesday.
theo wrote:
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

On 2004-11-08, Thomas Miller < XXXX@XXXXX.COM >wrote:
way stronger.
added value? And are you really sure the things you quickly summon up
(like VCL on one side, and LCL on the other) aren't mutually exclusive?
That's why I reacted. Your proposal was so very vague. You want to
make something platform independant based on something that is
already pretty platform independant (like the LCL)
is done for GTK2, and if there is enough manpower, Aqua and QT could also be
tackled.
libs deployed with the OS.
smaller this time. If I'm forced to go .NET it might not be Wirthian.
Moreover Java still holds the high-ground.
Chrome will never get enough userbase, at least not the next half decade,
Delphi.NET will drop VCL.NET sooner or later.
generate money in the legacy market for a few years. However I don't except
much new major development on win32, except some syntactic sugar leftovers
from .NET syntax wise (like for-each in D2005).
However I'm already thinking so since 1997, and can remember Lazarus
conception.
and really start going. Typically one major iteration is needed to get the
direction right and all noses in the right direction.
I don't think it is doable to reach significant higher levels of compability
by putting a layer over LCL on one side, and CLX on the other.
I think much more interoperability can be achieved more effectively by:
1) improving Lazarus and FPC, directly.
2) helping former delphi only projects to become more open to FPC/Lazarus.
(and then I mean actually helping, not just mailing)
3) doing header conversions, preferably working on both.
 

"Qt Commercial Licensing
Use the Qt Commercial License to:
Build commercial software.
Build software whose source code you wish to keep private.
Two qualities of the Qt Commercial License should be emphasized:
It is a development license.
You must purchase a Qt Commercial License from Trolltech or from any of its authorized
resellers before you start developing.
For desktop applications, there are no royalties, runtime licenses, or other additional
costs."
Doing commercial applications requires you to have a development license.
will again and again get "VCL" as a response. Borland isn't deaf, they must
have noticed that.
Free Pascal still is the same as it was 5 years ago - a few guys who find
it cool to play with compiler technology, and who start doing tons of
different things instead of finishing something.
If I recall correctly TThread was announced for FreePascal aproximately 4
years ago now. As far as I can see, it's still not working.
If development speed stays the same, FreePascal will take another few
years to get on par with the current Kylix compiler. And no, it does not
impress me that you can build "Hello World" on Win64. I don't sell
"Hello World" kind of programs ;)
Simon
 

On 2004-11-08, Simon Kissel < XXXX@XXXXX.COM >wrote:
.. This is completely different from the Qt Commercial Editions which cannot be distributed at all.
Which is why made the point about Qt installed with the OS.
I don't distribute Qt. I just access it from the host OS.
And GPL allows this. If Trolltech doesn't, afaik the above statement (open source version being under
GPL) is not valid.
its demoes. VCL.NET is a migration technology.
However I do have some hopes a significant number of developers will remain on win32
for quite a while. A poll at the same launch showed that 4 (4!) of the +/- 120 people
present used D8 or .NET in general. And one of those 4 was dr Bob, who gave a presentation
for Borland.
that, being in the same kind of business yourself.
FPC 1.9.x is a massive progression.
indeed not implemented.
FPC is pretty much getting close to modern Delphi on a base system level.
There are a lot skeletons in the cupboard (two major ones, packages and C++
linking), and several smaller ones (dispinterfaces, implements style
delegation, a lot of variant stuff barely tested and its RTL parts
incomplete)
On the other hand, we have 5 working architectures, and aspire to have them
roughly on the same level this year, or early next at the 2.0 release.
even in ten years. But depending on your business and application kind, it
is already better than Kylix. Mainly with regards to application deployment,
platforms. nativeness etc.
I'm strongly starting to suspect you haven't seen the 1.9.x series yet. Then you are
right. 1.0.x series is in freeze since december 1999, which nearly perfectly matches
your 5 years of nothingness.
Neither do I, which is why I desperately need 64-bit memory support (I have a statstical
system that needs data in memory at work. I'm not 100% sure it will grow beyond the 3 GB border
yet, but it is getting closer and closer).
P.s. Doing advocacy for Cross-Kylix is fun and ok, but please remain reasonable.
 

Marco van de Voort wrote:
support Delphi directly. I need to live in both worlds for
some time. I need a library that allows me to do that.
I am not the only one that needs that.
be a major development point.
but maybe someone here can tell us all their impressions.
it is king currently. I don't have any clue or opinion on
which one will win the war there.
the foreseeable future. Not much to get e{*word*277}d about.
LCL was to be universal, I would join it. But in its
mandate, LCL is there to support Free Pascal and Lazarus,
and I don't see that changing.
trying to make it compatible with LCL. The project is to
make the library load as a VCL in Delphi and load as an LCL
in Lazarus and maintain as much compatibility as possible
between the too. Just like CLX was suppose to do between
Delphi and Kylix. In addition, with all the source
available, we can expand the library at will. Something
Borland has not done with the VCL and you can't do without
access to private members. You can do a lot, but not everything.
that help the 100's of Delphi programmers that see Lazarus
as a real opportunity, but can't drop Delphi and need to
work in Lazarus when it makes sense, but mainly stay with
Delphi until Lazaus in more mature?
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Simon Kissel wrote:
was not good. I don't see them giving it away either. So
Kylix will be nice for a while longer and has some legs left
with the FreeCLX project, but in the end, it is a dead end.
If I had anything in CLX already, then I would probably
join, but I don't, so I see LCL as a better long term bet.
at $ 7480, that is more then I am willing to pay.
much when moving over, it isn't worth time. With this new
UOPL, they won't be loosing anything!!! Worst case is that
we will end up with a better VCL then what comes standard
with Delphi. You can then buy the Pro version to get
Enterprise type capability.
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

On 2004-11-08, Thomas Miller < XXXX@XXXXX.COM >wrote:
for a while. However depending on application and deployment requirements
FPC will be there.
It's not FPC against Kylix or Delphi against FPC. It is the delphi continuum,
keep libs general, and choose tools based on task.
Delphi things running that I can't get running with FPC for some reason.
(less often heard, but Kylix C++ support is sometimes something to be
desired, specially if you are on a schedule)
Once could try to wrap LCL widgets like LCL wraps the GTK widgets, however
then starting from straight GTK might be more doable.
Also, one can't probably get more compatible to Kylix without getting into
the problems that makes Kylix apps so hard to deploy on an avg Unix distro.
The rich emulation has its advantages, but also puts much higher requirements
on the libs.
doing similar things in LCL.
much better then they used to. The difference is fading.
percents off its back.
that the unification is doable in finite time, before the last one turns of the
light in the Kylix camp.
Because when Kylix is dying, it will be harder and harder to get manpower. All people
want your product because it will breath a few more years of life into their aging apps,
but not help.
That is the problem of doing commercial product spinoffs. 99% of the users
are so spoiled, you can't get them to do much. The few cluefull are on a timetable,
and to them any large project costs more time than it yields.
I think there is much more to be gained to abandon the holy grail approach,
and focus on the codebases that can be easily shared, and let the last few
percents incompatible.
the same for both platforms. Their whole internal archs are shaped to implement that
interface.
However your one would have VCL on the win32 side, and LCL on the *nix side.
The compability on both sides would have to go pretty deep, or 3rd party
products wouldn't work. In my opinion that is not possible, at least not practically
in the finite time left.
a future spinoff of CLX, continued crosskylix work etc, with near instant
return on invested time, instead of waiting for years for the toolkits
to develop and become usable and hoping for a perfect conversion.
cross. CrossKylix will also benefit from joint efforts on headers and
getting generic Delphi code Kylix runnable together with e.g. future versions
of CLX.
Even in ideal circumstances, I don't expect your project to top even only Lazarus
in the coming 2-3 years.
 

I know this information isn't on the website yet, but this decision has been long
done. I'm a commercial developer, I wouldn't invest my time into a project if
I'm not allowed to use the result afterwards ;)
by not releasing your application under an open source license, you must purchase
an appropriate number of commercial licenses from Trolltech. By purchasing commercial
licenses, you are no longer obliged to publish your source code.
If you wish to use a Qt Open Source Edition, you must contribute all your source code
to the open source community in accordance with the GPL or the QPL's license terms."
These are very clear and definitive license terms.
I agree that linking to LGPL libs would be legal, but without a development license
you are not allowed to DEVELOP using QT.
Or in other words: Yes, it's of course possible to ignore their clear license times
and use Warez. But don't expect anyone joining you then.
People want the VCL. That's why many of them stay with Borlands products.
This includes me, for the matter.
it from the "can I build my business applications on that?", the answer is a clear
and definitive no. It's a slowly progressing hobby project with limited resources.
Borland hasn't updated the Kylix compiler for years now, and FPC still is nowhere
near it.
somewhere, but we never really tested it". When I last checked a few months ago,
it was still completely non-working and crashing immediately. And if you search for
TThread at the mailing list archive, you'll still only find "is this supposed
to be working??" kind of messages. Also if you look at the effort to port
Indy to FreePascal, last time I checked it was suspended because the Thread-
stuff doesn't work.
I doubt after 4 years anything has changed during the last few weeks.
You simply don't need TThread for "Hello world", and that's why nobody cares.
business case for "Hello world" on Amiga. It's a cool hack, but that's it.
be small, non-multithreaded CGI applications that don't do anything. But run
on lots of platforms including Amiga ;)
there has not been a new release since then. I didn't check the snapshots, though.
Point is:
- These are the Borland newsgroups, not the FPC ones.
- I don't believe FPC is anywhere near being a usefull replacement for Kylix.
- I'm expressing this opinion.
No CrossKylix in that ;)
Also, I would LOVE it if FPC would be a viable alternative. The reason I did CrossKylix
is not that some fantatic-borland-{*word*60} reason, I simply have a business running with
products written in Delphi/Kylix, and I needed a way to boost my productivity and keep
this as safe as it can get for the future. And if I would see a decent migration path
I sure would consider taking it.
I will give FPC another try and let you know my findings.
Simon
 

Marco van de Voort wrote:
That is exactly the point of this project. LCL isn't bad,
but it doesn't support Delphi. You sound like you are very
involved with the project. If you can convince them to
include Delphi compatibility, then this new project would
not be needed. But so far I have gotten a cold shoulder
about the whole idea of including a Delphi build capability
of the LCL.
most of the work is already done there.
all. From following this newsgroup for the last 2 years,
there are people like yourself that don't think Kylix is
going any place but still use Delphi. What if there was a
library that allowed you to program in Delphi, open the
project in Lazarus and compile to Linux and Mac with less
then 1% if defs in your code? Would that be cool? Join our
list and help us figure out how to make this work. You
may even decide to help program a little :-)
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

On 2004-11-08, Simon Kissel < XXXX@XXXXX.COM >wrote:
at least if it can be detangled from unit libc.
tested in court.
But it is murky waters, I agree.
However I don't want to talk down trolltech (or Borland with their Open
Edition). While I would not do major development based on a GPL source,
because of the commercial angle, such a GPL/commerical dual license allows
getting a fixes/patches project of the ground that can have a public codebase
and site.
I can still remember the trouble with TV that was never opened up.
the winners, not VCL.NET.
(I can remember an EU db appserver) _before_ Kylix was even released.
and polished RAD attached. However to dismiss the entire project as hobbyism
is simply wrong.
Anyway, compilerwise, I'd say we are pretty close. The massive deployment
problems of Kylix apps alone are often enough.
We know for half a decade already that full substitability will be hard.
in spring.
at it, and Indy9 is only usable (on D6) after the threading fixes last
spring (make sure you have a snapshot of after April)
ICS/win32 works fine though. With threads.
aware of problems.
apps without mods doesn't automatically make it hello world levle.
Delphi is not complete, and you wouldn't be able to prove me wrong.
PowerPC and Arm.
I can't comment on your business cases, since I don't know your business. However it
sounds you are in some inflexible business environment.
continue to 1.9.6.
up generic codebases.
continuum, pretty much like Delphi, a future FreeCLX etc.
That's also why I keep hammering on selecting a case by case basis, and keep
asking for real arguments, and a decent case, not vague mutterings about
business cases, and rambling on about "hello world" on Amiga.
The thread situation is indeed one. As said, it is certainly not complete.
TMRSW is missing, and probably for certain codepieces won't work (I don't
know one atm, but it could be for other platforms than I'm using. FreeBSD
uses a different pthreads implementation, as said ICS/win32 works )
However to dismiss the entire system ( a 100MB+ codebase) as a "hello world"
program is plain silly.
with the safest choice. That is using delphi and{*word*222}all other platforms, till
you really can't anymore.
I did the same thing with BP/Topspeed the compilers I was using then. It won't work, you
have to take some risks.
The smart way is to simply add FPC to the Delphi/Kylix combo. Keep up to
date on these fronts, and make sure you don't crank out new code that has
avoidable incompabilities, and keep existing generic codebases compilable.
That way, when you have a choice (on per project basis) with FPC, you will
have a fair choice, otherwise the overhead involved with crossing over will
_always_ hold you back.
website or on mail to me, but preferably with compilable code to reproduce.
 

On 2004-11-09, Thomas Miller < XXXX@XXXXX.COM >wrote:
(some short points, I already overstepped my time with Simon's reply)
problem.
- designtime support will be hard.
- Delphi has bugs (e.g. compiling FPC with Delphi 6/7 doesn't create a working version)
- FPC has extensions. (inline, operator overloading). D2005 has some of these though.
For more reasons from the Lazarus teams, see the answer on Andreas msgs :
www.lazarus.freepascal.org/list_archives/lazarus/08-17-02_01-02-04/msg04927.html
I also (or actually one of the Lazarus devels) dug into the threading
problems Simon mentioned, and something has dawned on me. Synchronize() is
not implemented, and I probably never noticed since I always used critical
sections to guard subsystems and data. Apparantly ICS doesn't either, or at
least for the components I tested, but ICS does indeed do a lot of stuff in
its own way, since ICS is still compatible with _all_ delphi version
including D1. I used ICS mostly console anyway.
Note that rejections are always at the time, nothing is ever definite ( I
can remember heated debates about implementing delphi compat 8 years ago,
and see what we are discussing now :-)
of the VCL (read forms and deeper)) should be doable. Specially with D2005,
since some things might be better in it.
to library requirements comes from it.
for small sysadmin like progs, I do use lazarus already.
I'm a more likely candidate to focus on Indy porting. Also because I use
Indy on the Delphi side (historically due to its early SSL support)