|
Replies:
76
-
Last Post:
Nov 19, 2015 6:56 AM
Last Post By: Dalija Prasnikar
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
What compiler features you expect/want/need on Linux?
Personally, I could probably live with ARC (performance wise), but if anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way there.
UTF8 in -> UTF8 in the middle -> UTF8 out.
--
Dalija Prasnikar |
|
|
Posts:
121
Registered:
12/24/04
|
|
Delphi is using 16 bit unicode because of Win api. What is used in Linux api
or kde gnome gui framework?
<Dalija Prasnikar> schrieb im Newsbeitrag
news:735395 at forums dot embarcadero dot com...
What compiler features you expect/want/need on Linux?
Personally, I could probably live with ARC (performance wise), but if
anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way
there.
UTF8 in -> UTF8 in the middle -> UTF8 out.
--
Dalija Prasnikar |
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
Delphi is using 16 bit unicode because of Win api. What is used in Linux api
or kde gnome gui framework?
I have no idea. But AFAIK Linux is currently planned for
server side only, so GUI frameworks do not matter.
--
Dalija Prasnikar |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?
Firemonkey!
--
Regards,
Bruce McGee
Glooscap Software |
|
|
|
|
Posts:
1
Registered:
4/11/02
|
|
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?
Firemonkey!
Well, FireMonkey actually is not a compiler feature. But who knows, maybe in the future it will be  |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
Michael Justin wrote:
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?
Firemonkey!
Well, FireMonkey actually is not a compiler feature. But who knows,
maybe in the future it will be
I'm not limiting my response to compiler only features.
DataSnap would be the other, obvious choice, but that's not nearly as
controversial.
--
Regards,
Bruce McGee
Glooscap Software |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
DataSnap would be the other, obvious choice, but that's not nearly as
controversial.
Good luck to offer Datasnap to Linux developers, and its utterly lack of security. Try to tell them that PC1 is a safe, well known encryption algorithm, and that encryption keys are fixed and stored locally... |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
Luigi Sandon wrote:
DataSnap would be the other, obvious choice, but that's not nearly
as controversial.
Good luck to offer Datasnap to Linux developers, and its utterly lack
of security.
I see you haven't paid any attention to DataSnap outside of your narrow
use case.
Are you at least using a more recent version of Delphi?
--
Regards,
Bruce McGee
Glooscap Software |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
I see you haven't paid any attention to DataSnap outside of your narrow
use case.
I paid a lot of attention to Datasnap. Under the "security" features, it didn't improve at all. Maybe your use cases are very simple and narrow, my requirements for security are pretty higher and broader.
BTW: how many Datasnap applications have you ever deployed? I have a now old one that fully relies on the old DCOM Datasnap implementation. That was then secure enough, thanks to DCOM built in security. The issue is the new Datasnap implementaion - especially when it can't rely on a web server HTTPS implementaion (not always you can ask to install a web server just for some remoting...)
Are you at least using a more recent version of Delphi?
No, we're moving most development to C++ for lack of real improvements for our needs. Sorry, no mobile apps here.
But I did use the trials, and couldn't see any improvement. Worse, the same basic mistakes have been made in the other remoting technologies.
You may not have noticed, but security is getting paramount importance lately, and today you can't really deploy security-flawed applications but for the most simple and useless tasks.
But feel free to explain me how much secure Datasnap is - and were to find a sound critpgraphic library in Delphi... (hint: Lockbox is the wrong answer). |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
Luigi Sandon wrote:
I see you haven't paid any attention to DataSnap outside of your
narrow use case.
I paid a lot of attention to Datasnap. Under the "security" features,
it didn't improve at all. Maybe your use cases are very simple and
narrow, my requirements for security are pretty higher and broader.
Most of mine use HTTP, which secures very nicely.
I seem to remember that you didn't care because you only use TCP/IP and
didn't have a good strategy for storing keys. That sounds like a
narrower use case than mine.
BTW: how many Datasnap applications have you ever deployed?
More than a few.
Including some using the old architecture.
Are you at least using a more recent version of Delphi?
No,
That explains a lot.
we're moving most development to C++ for lack of real
improvements for our needs.
Good luck.
Sorry, no mobile apps here.
These aren't the only advances made, but maybe you don't use any of the
other stuff, either.
But feel free to explain me how much secure Datasnap is
We had a whole thread about that. Didn't you absorb any of it?
--
Regards,
Bruce McGee
Glooscap Software |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Most of mine use HTTP, which secures very nicely.
You forgot an S....
And no, it doesn't secure very nicely everywhere - especially since it relies on certificates, which, especially for client authentication, may be a big management overhead - but you authenticate clients, right? Have you ever had the need to impersonate the client security context on the server? Or the need for fully bidirectional connection?
And remember, installing a web server is not always an option for remoting - there are many situations where you don't want, or simply you can't. You have a very narrow view of remoting.
More than a few.
Good luck to your customers... I'd advise you to ask a professional to perform a VA.
That explains a lot.
Sure. It explains I can't trust the actual architecture for my data. Why should I spend thousand of dollars to get subpar security?
Good luck.
It works very well. Being server code, all the RAD part would be useless.
We had a whole thread about that. Didn't you absorb any of it?
Time to revist it, after the new releases you talked about, right? Or it is still in the abysmal state of old, so no need to revisit it? |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
Luigi Sandon wrote:
Good luck to your customers... I'd advise you to ask a professional
to perform a VA.
I have.
Have you?
--
Regards,
Bruce McGee
Glooscap Software |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Have you?
Yes. We do VA and pentest... |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 09.10.2015 um 17:39 schrieb Luigi Sandon:
I see you haven't paid any attention to DataSnap outside of your narrow
use case.
I paid a lot of attention to Datasnap. Under the "security" features, it didn't improve at all. Maybe your use cases are very simple and narrow, my requirements for security are pretty higher and broader.
BTW: how many Datasnap applications have you ever deployed? I have a now old one that fully relies on the old DCOM Datasnap implementation. That was then secure enough, thanks to DCOM built in security. The issue is the new Datasnap implementaion - especially when it can't rely on a web server HTTPS implementaion (not always you can ask to install a web server just for some remoting...)
Are you at least using a more recent version of Delphi?
No, we're moving most development to C++ for lack of real improvements for our needs. Sorry, no mobile apps here.
But I did use the trials, and couldn't see any improvement. Worse, the same basic mistakes have been made in the other remoting technologies.
You may not have noticed, but security is getting paramount importance lately, and today you can't really deploy security-flawed applications but for the most simple and useless tasks.
But feel free to explain me how much secure Datasnap is - and were to find a sound critpgraphic library in Delphi... (hint: Lockbox is the wrong answer).
Hello,
afaik datasnap nowadays supports more security wise than PC1!
Afaik it has at least a filter system where you can plug something in.
You might want to look here:
http://blogs.embarcadero.com/pawelglowacki/2013/10/16/40089
Greetings
Markus |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
afaik datasnap nowadays supports more security wise than PC1!
Not out of the box unless you piggyback a web server. Even their RSA implementation is just the "easily exportable" one - an unsecure version.
Their finger to hide behind is that exporting cryptography needs a permission, so they can't - they would need some paperwork it looks they don't want to pay for. Let's see if Idera is less mean.
Afaik it has at least a filter system where you can plug something in.
Filters as designed are useless to implement proper security. Sure, you can manipulate the traffic, but you have no way to implement a proper cryptographic protocol to ensure the traffic gets properly encrypted. There is no support for handshaking - take a look at how TLS implements handshaking to secure the channel, and you understand why filters may be good for compression, and little else. You can't really encrypt traffic with a fixed key stored locally on both endpoints, and the same for every client.
Also Datasnap doesn't support any authentication method which is not user/password based. Instead of having a pluggable system able to support actual authenticatio methods which don't send the password (i.e. Kerberos...), it requires you to send a password to another system. Of course everything password as strings, because authentication data are only strings, never binary data, right?
No matter how much a channel is secure, sorry, I can't send password around for several reasons... it's 2015, not 1985 nor 1995. |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 12.10.2015 um 11:27 schrieb Luigi Sandon:
afaik datasnap nowadays supports more security wise than PC1!
Not out of the box unless you piggyback a web server. Even their RSA implementation is just the "easily exportable" one - an unsecure version.
Their finger to hide behind is that exporting cryptography needs a permission, so they can't - they would need some paperwork it looks they don't want to pay for. Let's see if Idera is less mean.
Afaik it has at least a filter system where you can plug something in.
Filters as designed are useless to implement proper security. Sure, you can manipulate the traffic, but you have no way to implement a proper cryptographic protocol to ensure the traffic gets properly encrypted. There is no support for handshaking - take a look at how TLS implements handshaking to secure the channel, and you understand why filters may be good for compression, and little else. You can't really encrypt traffic with a fixed key stored locally on both endpoints, and the *same for every client
*.
Also Datasnap doesn't support any authentication method which is not user/password based. Instead of having a pluggable system able to support actual authenticatio methods which don't send the password (i.e. Kerberos...), it requires you to send a password to another system. Of course everything password as strings, because authentication data are only strings, never binary data, right?
No matter how much a channel is secure, sorry, I can't send password around for several reasons... it's 2015, not 1985 nor 1995.
Ok, if your information is current, then you have valid points.
Did you already talk with Marco Cantu about this matter?
Greetings
Markus |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Did you already talk with Marco Cantu about this matter?
Embarcadero is well aware of my complains about security in its remoting solutions. It's a pity this area is still overlooked.
Another issue is Delphi has no libraries to easy access Windows security APIs. I see CodeRage sessions using OpenSSL thorugh Indy and the like. OpenSSL is a widely used library, but under Windows it's not the standard one.
That means you have to update it for your customer every time a security fix is made available (and in the past months, after Heartbleed vulnerability and OpenSSL scrutiny, there have been a lot...), and your customers have to patch your application themselves outside the Windows update cycle. For customer who properly test applications before putting them in production, a stream of patches is not usually welcome.
Moreover, OpenSSL is not integrated with Windows certificate store, meaning you have to manage certificates (and protect private keys) yourself, and especially can't rely on Active Directory to easily distribute certificate (and revoke them). A little issue if you have a single web server, a not so little one when you have 50,000 clients each needing its own certificate to authenticate, also using a non flat PKI hierarchy. |
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Luigi wrote:
Moreover, OpenSSL is not integrated with Windows certificate store
Not natively, no. However, it is possible to use Windows certificates
with OpenSSL using a little manual code. And IIRC there are some third-party
addons that integrate the Windows certificate store into OpenSSL.
--
Remy Lebeau (TeamB) |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 16.10.2015 um 15:44 schrieb Luigi Sandon:
Did you already talk with Marco Cantu about this matter?
Embarcadero is well aware of my complains about security in its remoting solutions. It's a pity this area is still overlooked.
Another issue is Delphi has no libraries to easy access Windows security APIs. I see CodeRage sessions using OpenSSL thorugh Indy and the like. OpenSSL is a widely used library, but under Windows it's not the standard one.
That means you have to update it for your customer every time a security fix is made available (and in the past months, after Heartbleed vulnerability and OpenSSL scrutiny, there have been a lot...), and your customers have to patch your application themselves outside the Windows update cycle. For customer who properly test applications before putting them in production, a stream of patches is not usually welcome.
Moreover, OpenSSL is not integrated with Windows certificate store, meaning you have to manage certificates (and protect private keys) yourself, and especially can't rely on Active Directory to easily distribute certificate (and revoke them). A little issue if you have a single web server, a not so little one when you have 50,000 clients each needing its own certificate to authenticate, also using a non flat PKI hierarchy.
Hello,
there is a new http library/component added to Delphi now which uses the
platform apis on Windows afaik.
Greetings
Markus |
|
|
|
|
Posts:
913
Registered:
9/22/99
|
|
Markus Humm wrote:
there is a new http library/component added to Delphi now which uses
the platform apis on Windows afaik.
Correct. And also for iOS, OSX and Android.
Since you guys evidently didn't attend my CodeRageX talk:
https://github.com/jkaster/RTLPerf
Grab either my slides or my notes.
You will probably also be interested in:
WinAPI.Security.pas
WinAPI.Security.Credentials.pas
WinAPI.Security.Cryptography.pas
--
John Kaster http://johnkaster.wordpress.com
Software solutions |
|
|
|
|
Posts:
913
Registered:
9/22/99
|
|
Luigi Sandon wrote:
Embarcadero is well aware of my complains about security in its
remoting solutions. It's a pity this area is still overlooked.
Overlooked by you, perhaps, but no longer by Embarcadero.
https://github.com/jkaster/RTLPerf
Grab either my slides or my notes.
You will also be interested in:
WinAPI.Security.pas
WinAPI.Security.Credentials.pas
WinAPI.Security.Cryptography.pas
Which are party of the DXS RTL.
--
John Kaster http://johnkaster.wordpress.com
Software solutions |
|
|
|
|
Posts:
155
Registered:
5/3/07
|
|
Afaik it has at least a filter system where you can plug something in.
Plug in filters can easily be implemented in an insecure way. Encrypting x number of bytes with a shared key is usually the examples given with filters.
Patterns in the data will arise because of it.
TLS 1.2 and protocols like it that use public key crypto to exchange a random symmetric key are far more secure.
Shared keys mean that the key typically has to be distributed with the client, which is only as secure as you can keep your clients, which is typically not secure.
One comprised client == all communication can be decrypted regardless of the client. |
|
|
|
|
Posts:
155
Registered:
5/3/07
|
|
Try to tell them that PC1 is a safe, well known encryption algorithm, and that encryption keys are fixed and stored locally...
There are far more problems:
PC1 code references a website that does not exist anymore, but I found following C code that had the same url
http://xrootd.org/doc/githead/xrootd/src/XrdCrypto/PC1.cc
Form this I believe the code implements the algorithm published by Alexander Pukall on usenet in 1991, and the algorithm has
been studied since it was used with Kindle DRM.
The following paper is the Cryptoanalysis of the "Kindle" Cipher, which is same as PC1
http://orbilu.uni.lu/bitstream/10993/17072/1/Cryptanalysis%20of%20Kindle%20Cipher.pdf
Some quotes from the paper:
"We show devastating attacks against the PC1 cipher"
"This analysis shows that PC1 is very weak and probably made its
way into popular products due to the lack of academic cryptanalysis, which we
provide in this paper."
PC1 algorithm is not on the listed as a valid algorithm for PCI, FIPS, NSIT, or ISO compliance.
DataSnap however can use SSL/TLS with Indy and and can also use SSL/TLS via a web server. But you need to make sure you are using TLS 1.2 exclusively as all the other variants can
be exploited by POODLE and other attacks. |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 27.10.2015 um 03:52 schrieb Robert Love:
DataSnap however can use SSL/TLS with Indy and and can also use SSL/TLS via a web server. But you need to make sure you are using TLS 1.2 exclusively as all the other variants can
be exploited by POODLE and other attacks.
Hello,
how would I enforce TLS 1.2?
Greetings
Markus |
|
|
|
|
Posts:
155
Registered:
5/3/07
|
|
how would I enforce TLS 1.2?
So with IIS you can use this free product, or you can figure out the various registry entries.
https://www.nartac.com/Products/IISCrypto
With Indy you set the SSLVersions property. Here is the demo code from my last coderage sessions where I discussed it.
https://github.com/rlove/Indy-SSL-Examples
although you should limit it to TLS 1.2 on client & server you really only need to do it with server as the POODLE exploit is due to a man in the middle causing you to downgrade from 1.2 to lower exploitable versions. |
|
|
|
|
Posts:
155
Registered:
5/3/07
|
|
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 28.10.2015 um 02:28 schrieb Robert Love:
Hello,
unfortunatelly I want to build something directly using DataSnap without
any IIS etc. so it's self contained.
Greetings
Markus |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Firemonkey!
Yes, all Linux server administrators will be happy to setup X and OpenGL just to configure or monitor an application... <G>
IMHO it's better if they re-addTurboVision.... |
|
|
|
|
Posts:
392
Registered:
6/9/02
|
|
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?
Firemonkey!
It would need to be renamed Flaming Penguin to have a chance. |
|
|
|
|
Posts:
137
Registered:
8/2/15
|
|
What compiler features you expect/want/need on Linux?
- Not ARC, for sure (it would break a lot of existing code, running perfectly on Windows or OSX).
- 8 bit strings (almost everything in C like API uses *char and UTF-8), even if I'm fine with string=UnicodeString as long as I can define my own type string(CP_UTF8).
- resource binding
- standard .map file for debug info
- .o static linking in latest gcc format (Kylix is tied to deprecated gcc 2 layout)
- share a lot of API headers with other POSIX targets
I'm currently spending a lot of time in FPC those days, and I can say that cross-platform integration of this compiler is just great.
AFAIC, a Kylix-level compiler with gcc 4/5 .o static linking would be just fine. |
|
|
|
|
Posts:
137
Registered:
8/2/15
|
|
- Not ARC, for sure (it would break a lot of existing code, running perfectly on Windows or OSX).
- 8 bit strings (almost everything in C like API uses *char and UTF-8), even if I'm fine with string=UnicodeString as long as I can define my own type string(CP_UTF8).
- resource binding
- standard .map file for debug info
- .o static linking in latest gcc format (Kylix is tied to deprecated gcc 2 layout)
- share a lot of API headers with other POSIX targets
And I would add, the most wanted:
- Linux 64 bit target.
Nowadays, all installed Linux systems are 64 bit, and Linux needs specific packages for running of 32 bit executables.
In short, running a 32 bit executable under Linux is more complicated than under Windows (which has a specific translation layer of all APIs).
Even if a Delphi executable has very few dependencies, my experiment is that running as native 64 bit app is a requirement under Linux. |
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
Kylix level would mean Delphi 6. The new Delphi 10.1/.2/.3 "Kylix" compiler
would have the same language features as the Win compiler.
<Arnaud Bouchez> schrieb im Newsbeitrag
news:735420 at forums dot embarcadero dot com...
What compiler features you expect/want/need on Linux?
- Not ARC, for sure (it would break a lot of existing code, running
perfectly on Windows or OSX).
- 8 bit strings (almost everything in C like API uses *char and UTF-8),
even if I'm fine with string=UnicodeString as long as I can define my own
type string(CP_UTF8).
- resource binding
- standard .map file for debug info
- .o static linking in latest gcc format (Kylix is tied to deprecated gcc
2 layout)
- share a lot of API headers with other POSIX targets
I'm currently spending a lot of time in FPC those days, and I can say that
cross-platform integration of this compiler is just great.
AFAIC, a Kylix-level compiler with gcc 4/5 .o static linking would be just
fine. |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
Ralf Stocker wrote:
Kylix level would mean Delphi 6. The new Delphi 10.1/.2/.3 "Kylix"
compiler would have the same language features as the Win compiler.
I certainly hope so.
I want to be able to deploy a server to either Windows or Linux with as
little hassle as possible.
Mac, too, I suppose, but that's mostly just for completeness. I'm not
sure how many people are actually deploying Mac servers. I know I'm not
planning to.
--
Regards,
Bruce McGee
Glooscap Software |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?
Probably it will be almost the same as Mac OSX
[]s
Cesar Romero |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Probably it will be almost the same as Mac OSX
OSX is essentially a desktop OS. Linux today is essentially a server OS.
That means very different applications and very different loads. Do not expect a compiler optimized for GUI desktop applications to perform well on heavy server applications. |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
Luigi Sandon wrote:
OSX is essentially a desktop OS. Linux today is essentially a server
OS.
That means very different applications and very different loads. Do
not expect a compiler optimized for GUI desktop applications to
perform well on heavy server applications.
Like the OP mentioned, I mean the compiler (and RTL implictly), not UI
Libraries.
Sorry if I was not clear enought.
Regards,
Cesar Romero |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Like the OP mentioned, I mean the compiler (and RTL implictly), not UI
Libraries.
Exactly. A compiler able to produce highly scalable multithread code is very important. And how object instances (and all memory management features) are managed is very, very important.
In OSX basically you have a single user application that may run a few threads. On a server, you may have thousands (or more) users running over as many threads as your CPUs allow. If the compiled and the RTL are not designed to handle it, you've got a big problem...
Delphi really needs to get rid of its Windows 3.1 desktop apps roots. It could work for mobile apps, it won't work for server applications. They should have noticed Windows became a valid server operating system since Window 2000, but they failed to do so... |
|
|
|
|
Posts:
1,754
Registered:
8/10/13
|
|
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
I don't think this is true when it comes down to compiler (although it can certainly be improved).
Object and memory management is a compiler matter. Actually between the compiler (non ARC one) and the RTL the biggest issues are in the latter.
kicking some Java and C# asses
Under Linux, the competitors will not be nor Java nor C# nor Python. It will be GCC (also, under Windows the real competitor is VC++). And the RTL has to paly against libraries like the standard C library and Boost, which are usually far better optimized.
Anyway, if you want to convince someone used to free tools to pay for your not-so-cheap one, you have really to offer something really capable of outperforming the free tools. Otherwise, good luck to sell yours... |
|
|
|
|
Posts:
1,754
Registered:
8/10/13
|
|
Under Linux, the competitors will not be nor Java nor C# nor Python. It will be GCC (also, under Windows the real competitor is VC++)
I really don't get this. If Java is not in Linux servers nor in Windows servers where it is after all? Desktop? The same for C# on Windows... |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
I really don't get this. If Java is not in Linux servers nor in Windows servers where it is after all? Desktop? The same for C# on Windows...
Ask yourself. If ever Delphi targets Linux, who could be its prospect customers? Java developers? PHP/Python/Ruby developers? Same for Windows - with C# on the same level as Java.
On Linux, and other platforms, Java is the realm of large enterprise applications, especially thanks to products like Tomcat, WebLogic, WebSphere and the like - something that Delphi can't really offer. Raw speed is nor really the main issue for Java applications, the main issues are scalability, robustness and the like - especially often in the hands of not-so-skilled developers.
Nor Delphi is good to deliver web applications.
Thereby who could be the targer of a "Delphi for Linux"? Unluckily, it's the same target actually using GCC and writing C/C++ native applications. And it also needs to ask money, while all the rest is free.... where's the appeal? |
|
|
|
|
Posts:
137
Registered:
8/2/15
|
|
On Linux, and other platforms, Java is the realm of large enterprise applications, especially thanks to products like Tomcat, WebLogic, WebSphere and the like - something that Delphi can't really offer. Raw speed is nor really the main issue for Java applications, the main issues are scalability, robustness and the like - especially often in the hands of not-so-skilled developers.
I can assure you that raw speed is a huge factor in a lot of SOA applications.
Once your SaaS applications start to have success, scaling abilities are the main question.
Vertical scaling is used in the Java world (more RAM and CPU, mainly to help GC process)...
I've worked for companies spending millions to get rid of Hibernate or SOAP just to gain raw speed.
Even writing some core component in raw C/C++, just to ensure best speed possible.
something that Delphi can't really offer
Nor Delphi is good to deliver web applications.
We developped the whole http://mormot.net framework just to write such large entreprise applications, following SOA principles.
I'm currently working on a huge cloud of mORMot servers, creating IoT interfaces following DDD principles, and it rocks.
I can assure you that in terms of ease of deployment and resulting performance, it is just great, when compared to classic Java servers: no JVM, low RAM and CPU consumption, per-node fast embedded databases.
Even the small MVC web part is very promising (but seldom used).
With Delphi, you have the benefit of C/C++ deterministic execution, with the ease of a high level language like object pascal, based on interfaces and SOLID.
With mORMot, you even get some unique features like asynchronous callbacks over websockets which allow to deploy large event-driven systems without the need to use a message queue or dedicated libraries like ZMQ.
It is not a J2EE compliant system, so would not be as a replacement but was definitively built as an alternative.
This is what is great with SOA, and today convention like REST or JSON: you could mix services, and let J2EE services consume mORMot REST services, if needed.
Thereby who could be the target of a "Delphi for Linux"?
Windows is an awfully complex system for plain servers - at least until the Nano Servers would come.
Linux is much easier to administrate and secure.
Windows 2012 updates are a real PITA for production servers.
And I would not put a Windows server on the Internet without a dedicated hardware firewall in front of it, or without a domain controller...
Last but not least, Windows licensing can be very pricey...
We currently use Kylix and FPC for Linux compilation of our mORMot servers.
An official "Delphi for Linux" may definitively help.
Especially when Embarcadero, just acquired by another DB company, would like to focus on entreprise solutions. |
|
|
|
|
Posts:
392
Registered:
6/9/02
|
|
Thereby who could be the targer of a "Delphi for Linux"? Unluckily, it's the same target actually using GCC and writing C/C++ native applications. And it also needs to ask money, while all the rest is free.... where's the appeal?
I can't believe you're the only one who gets this. I'm reminded of a web page that wanted to show how fast Delphi was and pitted it against PHP and some other interpreted languages, but not a single compiled one.
I've run benchmarks of Delphi code against GCC myself and on Linux (as opposed to Windows) GCC is very finely tuned; I've yet to see GCC do worse than double Delphi's speed (Linux/GCC vs. Windows/Delphi). CLang is catching up to GCC in optimization but it's not quite there yet (although it compiles much faster).
I've been asking for years for someone to share with me how they would pitch the case for Delphi to a Director of IT or CTO or CIO. I worked in a company that dealt with business-to-business sales for eight years and I don't know how you're going to pitch a slower, more expensive compiler vs. a faster, free one. On top of that, Linux users are not going to develop in a VM running Windows (in fact, no developers except Delphi developers develop in a VM in the first place). In fact, many Linux users don't use big, heavy IDEs; they use Vim or Emacs or Sublime Text and command-line utilities and SSHing into servers, etc. The development model of Delphi itself is rather alien to the world of Linux. While we're at it, static linking is shunned in the world of Linux (one reason why Kylix failed to attract any Linux users). Proprietary languages are shunned everywhere nowadays.
As usual, the only market I see is a fraction of the already existing Delphi market that wants to cross-compile to Linux. You're not going to generate any new customers out of this, so they're still stuck with milking the cow rather than expanding the user base (which would lower prices).
|
|
|
|
|
Posts:
75
Registered:
3/6/08
|
|
On 10/26/2015 6:18 PM, Joseph Mitzen wrote:
While we're at it, static linking is shunned in the world of Linux.
Nitpick: Static linking is traditionally shunned in the world of Linux,
but Go is gaining a lot of traction and is statically linked by default.
--
Josh Kelley |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Luigi Sandon wrote:
I don't think this is true when it comes down to compiler (although
it can certainly be improved).
Object and memory management is a compiler matter.
Not with manual memory management.
--
Rudy Velthuis http://www.rvelthuis.de
"I never miss a chance to have sex or appear on television."
-- Gore Vidal |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Luigi Sandon wrote:
Probably it will be almost the same as Mac OSX
OSX is essentially a desktop OS. Linux today is essentially a server
OS.
For the compiler, why should that matter?
--
Rudy Velthuis http://www.rvelthuis.de
"Why do you sit there looking like an envelope without any
address on it?" -- Mark Twain |
|
|
|
|
Posts:
392
Registered:
6/9/02
|
|
Probably it will be almost the same as Mac OSX
OSX is essentially a desktop OS. Linux today is essentially a server OS.
Linux is everywhere from embedded (e.g. routers) to supercomputers. In fact, 495 of the top 500 supercomputers in the world run Linux.
That means very different applications and very different loads. Do not expect a compiler optimized for GUI desktop applications to perform well on heavy server applications.
How would a compiler optimize for a desktop application? The difference between desktop and server loads is dealt with via the Linux kernel scheduler and not via application optimization. There are Linux schedulers optimized for responsiveness/latency at a small expense to performance and there are schedulers tuned for heavy loads. There are even experimental schedulers now that are optimized for SSD vs. HDD systems. |
|
|
|
|
Posts:
68
Registered:
11/5/00
|
|
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?
Probably it will be almost the same as Mac OSX
I am not sure, try binary search in
"c:\Program Files (x86)\Embarcadero\Studio\17.0\bin\Borland.Build.Tasks.Delphi.dll"
for dccLinux and you get (with another strange compilers)
<ExePath Platform="Linux32" Path="%BDS%\bin\dcclinux.exe"/>
<ExePath Platform="Linux64" Path="%BDS%\bin\dcclinux64.exe"/>
and dccOSX is only for 32.
R. |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
Radek Cervinka wrote:
I am not sure, try binary search in
"c:\Program Files
(x86)\Embarcadero\Studio\17.0\bin\Borland.Build.Tasks.Delphi.dll"
for dccLinux and you get (with another strange compilers) <ExePath
Platform="Linux32" Path="%BDS%\bin\dcclinux.exe"/> <ExePath
Platform="Linux64" Path="%BDS%\bin\dcclinux64.exe"/>
and dccOSX is only for 32.
I think we are talking about Compiler and RTL features, isn't?
Regards,
Cesar Romero |
|
|
|
|
Posts:
68
Registered:
11/5/00
|
|
Radek Cervinka wrote:
I am not sure, try binary search in
"c:\Program Files
(x86)\Embarcadero\Studio\17.0\bin\Borland.Build.Tasks.Delphi.dll"
for dccLinux and you get (with another strange compilers) <ExePath
Platform="Linux32" Path="%BDS%\bin\dcclinux.exe"/> <ExePath
Platform="Linux64" Path="%BDS%\bin\dcclinux64.exe"/>
and dccOSX is only for 32.
I think we are talking about Compiler and RTL features, isn't?
Sorry I don't understand.
I think that 32 or 64bit is main compiler (and of course RTL) feature. This is real hint that maybe 64bit Linux compiler can exists.
So if I thinking of 64bit, I know that only public 64bit compiler for x86 is Win64, not OSX (compiler features).
If you look at source code of RTL in current Delphi, there are many IFDEF POSIX, IFDEF LINUX and so on.
system.pas
{$ELSEIF defined(LINUX)}
{$IFDEF EXTERNALLINKER}
{$DEFINE ZCX_BASED_EXCEPTIONS}
{$ELSE}
{$DEFINE PC_MAPPED_EXCEPTIONS}
{$ENDIF}
{$ELSE}
or
{$IF defined(LINUX64) and defined(CPUX64)}
function GetCPUType: Integer;
begin
Result := CPUPentium;
end;
{$ENDIF LINUX64 and CPUX64}
This two example function is important (External linker?) |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
Radek Cervinka wrote:
Sorry I don't understand.
Linux compiler and rtl features in Linux will probably match features
with OSX compiler, unless the feature is specific of the platform.
I think that 32 or 64bit is main compiler (and of course RTL)
feature. This is real hint that maybe 64bit Linux compiler can
exists. So if I thinking of 64bit, I know that only public 64bit
compiler for x86 is Win64, not OSX (compiler features).
If you look at source code of RTL in current Delphi, there are many
IFDEF POSIX, IFDEF LINUX and so on.
Yes, a Linux compiler exists since Kylix, but I also think that we will
se another one anytime in future, some Embarcadero employees already
mentioned that "Linux compiler is a work in progress", it only was not
high priority to release.
Regards,
Cesar Romero |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Personally, I could probably live with ARC (performance wise), but if anything,
On LInux, I do expect a compiler able to generate code able to perfrom well on a heavy multithread server application (see very little need for desktop apps, there). ARC would be a real performance killer if it does serialize a lot. Better a GC, then, I guess it could scale better. If they avoid both a GC and ARC and implement a good multithreaded memory manager, the better... |
|
|
|
|
Posts:
68
Registered:
11/5/00
|
|
Personally, I could probably live with ARC (performance wise), but if anything,
ARC would be a real performance killer if it does serialize a lot. Better a GC, then, I guess it could scale better. If they avoid both a GC and ARC and implement a good multithreaded memory manager, the better...
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting). |
|
|
|
|
Posts:
137
Registered:
8/2/15
|
|
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).
There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).
ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.
And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.
ARC would break a lot of existing Delphi code. |
|
|
|
|
Posts:
68
Registered:
11/5/00
|
|
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).
There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).
Yes I agreed, I am only compared ARC and GC. I have no problems with manual memory handling.
R. |
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Arnaud wrote:
And currently, ARC has some performance issues in Delphi RTL.
Some of those have been addressed in Seattle (but not as well as they could
have been, but it is a start).
--
Remy Lebeau (TeamB) |
|
|
|
|
Posts:
1,754
Registered:
8/10/13
|
|
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).
There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).
ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.
And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.
ARC would break a lot of existing Delphi code.
Agreed |
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).
There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).
ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.
And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.
ARC would break a lot of existing Delphi code.
Can't argue that.
Which brings me to conclusion that introducing ARC in mobile
compilers was wrong decision.
Having compilers that operate under different memory management is
not exactly optimal solution in the long run.
--
Dalija Prasnikar |
|
|
|
|
Posts:
137
Registered:
8/2/15
|
|
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).
There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).
ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.
And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.
ARC would break a lot of existing Delphi code.
Can't argue that.
Which brings me to conclusion that introducing ARC in mobile
compilers was wrong decision.
Having compilers that operate under different memory management is
not exactly optimal solution in the long run.
--
Dalija Prasnikar
Having compilers that operate under different memory management is
not exactly optimal solution in the long run.
Indeed.
About ARC general discussion, circular references and zeroing weak pointers:
http://blog.synopse.info/post/2011/12/08/Avoiding-Garbage-Collector%3A-Delphi-and-Apple-on-the-same-side
http://blog.synopse.info/post/2012/06/18/Circular-reference-and-zeroing-weak-pointers
http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/11
http://clang.llvm.org/docs/AutomaticReferenceCounting.html
The FPC team did discuss about ARC some months ago.
There is even a branch with a starting implementation.
The discussion is worth reading.
See http://lists.freepascal.org/fpc-devel/2014-October/034668.html
The main idea was to try to implement ARC in parallel with non ARC.
As I proposed in http://blog.synopse.info/post/2012/10/06/Delphi-XE3-is-preparing-reference-counting-for-class-instances :
But one issue of the implementation as previewed from XE3 sources (in addition to its alpha stage and poor performance) is that it is global to the application: the TObject memory model will be either ARC-based or manually handled (just like before).
This is a breaking change in the Delphi way of coding, and I would rather prefer a dedicated TObject / class type, able to coexist with the huge amount of third-party source code. Even if most user-level code may work with no issue (since Free will use the reference counting), some lower level code may be broken by such a change.
A dedicated class type may allow clear distinction between the "classic" model expecting manual Free of instances, and the new ARC model with its own style of coding.
I like very much the FreePascal approach, with its syntax modes: you can have several syntax and even class models in the same application. It is used for instance to mix objective pascal and classic pascal classes in the same project. Clean and easy.
It will also make the OS X integration much easier than the current interface-based marshalling of the Objective C APIs within Delphi. A lot of plumbing which should be leverage at compiler level.
I hope Embarcadero has such features on the road map, otherwise its future could be problematic: not compatible with legacy code (which is its main strength), and with no obvious benefit when compared to alternatives. |
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
ARC is no performance killer. ARC <> GC!!!
<Luigi Sandon> schrieb im Newsbeitrag news:735476 at forums dot embarcadero dot com...
Personally, I could probably live with ARC (performance wise), but if
anything,
On LInux, I do expect a compiler able to generate code able to perfrom
well on a heavy multithread server application (see very little need for
desktop apps, there). ARC would be a real performance killer if it does
serialize a lot. Better a GC, then, I guess it could scale better. If they
avoid both a GC and ARC and implement a good multithreaded memory manager,
the better... |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
ARC is no performance killer. ARC <> GC!!!
I know they're different, still they both try to manage objects lifetime on your behalf and thereby has to find a way to keep track of them. And here lie the issues. Do it in the wrong way - i.e. the need of serializing accesses to shared structures - and you're going to kill performance especially on the kind of applications usually run on a server.
ARC may have little impact on client, user driven applications - but it may have far larger one on server application serving many connections. A GC, despite its overhead, may work better in that situation, if you really want automatic memory management.
OSX doesn't use ARC everywhere. Objective-C uses ARC, but a lot of OSX is not written in Objective-C. A good slice is written in C/C++. Anyway, OSX is not a server operating system, nor are its Apple applications.
C++ chose RAII because it doesn't need shared structures. although I don't like it too because it had to rely soon on all the "smart pointer" semantic to overcome its limits - some of which may hit serialization too (i.e. shared_ptr) - at least it's up to the developer to design its application properly and use them only when needed (or avoid them altogether if possible).
If they stay away from ARC and GC, and let developers manage memory - after all if you're developing a server application I hope you know what you're going to do - the better. |
|
|
|
|
Posts:
248
Registered:
1/12/00
|
|
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
Personally, I could probably live with ARC (performance wise), but if anything,
On LInux, I do expect a compiler able to generate code able to perfrom well on a heavy multithread server application (see very little need for desktop apps, there). ARC would be a real performance killer if it does serialize a lot. Better a GC, then, I guess it could scale better. If they avoid both a GC and ARC and implement a good multithreaded memory manager, the better...
If ARC would be a problem from performance side, then I absolutely
prefer manual memory management.
--
Dalija Prasnikar |
|
|
|
|
Posts:
424
Registered:
6/28/02
|
|
If ARC would be a problem from performance side, then I absolutely
prefer manual memory management.
--
Dalija Prasnikar
If ARC has problem for performance . We can not edit compiler or RTL. And all of us are at a loss what to do.
So i wish supply two object model. TObject TARCObject. Supply ARC, but leave the right of choosing memory management to the programmers.
By the way. The hidden field for lockable object is really should be selected by the users.
e.g. TSomeObject = class lockable (TObject)
Only such object will have the hidden field and can be locked. |
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
If ARC would be a problem from performance side, then I absolutely
prefer manual memory management.
--
Dalija Prasnikar
If ARC has problem for performance . We can not edit compiler or RTL. And all of us are at a loss what to do.
So i wish supply two object model. TObject TARCObject. Supply ARC, but leave the right of choosing memory management to the programmers.
By the way. The hidden field for lockable object is really should be selected by the users.
e.g. TSomeObject = class lockable (TObject)
Only such object will have the hidden field and can be locked.
You have already ARC: Strings, dyn. Arrays. Isn't it performant? |
|
|
|
|
Posts:
424
Registered:
6/28/02
|
|
You have already ARC: Strings, dyn. Arrays. Isn't it performant?
Yes. You're right. We also have PChar, static array. Is it?
They are peaceful.
No one is forced to use String, not PChar.
I am very glad I can make a choice according to the need. |
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
You have already ARC: Strings, dyn. Arrays. Isn't it performant?
Yes. You're right. We also have PChar, static array. Is it?
They are peaceful.
No one is forced to use String, not PChar.
I am very glad I can make a choice according to the need.
Don't fear! There is no performance penalty with ARC. (ARC <> GC)!!!
Edited by: Ralf Stocker on Oct 16, 2015 2:33 PM |
|
|
|
|
Posts:
353
Registered:
10/15/99
|
|
Don't fear! There is no performance penalty with ARC. (ARC <> GC)!!!
Actually, that isn't true. ARC does have a performance penalty compared to manual memory management, and how large it is depends on how the ARC workings are implemented. That's true for a GC has well.
ARC may use less memory than a GC, because it would usually release memory earlier than a GC does.
And one thing is to have reference counting for just some types of data, another is having it for each and every memory allocation. Then there are all the issue related to weak references and so on... |
|
|
|
|
Posts:
1,529
Registered:
9/23/99
|
|
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?
Personally, I could probably live with ARC (performance wise), but if anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way there.
UTF8 in -> UTF8 in the middle -> UTF8 out.
Except UFT-8 is not an 8 bit string encoding scheme. It is a variable width
encoding scheme that a single code point can be up to 4 bytes long.
https://en.wikipedia.org/wiki/UTF-8
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
Learning is finding out what you already know. Doing is demonstrating that you
know it. Teaching is reminding others that they know it as well as you. We are
all leaners, doers, teachers. (R Bach) |
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Jeff wrote:
Except UFT-8 is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be up to 4 bytes
long.
The same can be said of UTF-16:
"Except UTF-16 is not a 16 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 2 or 4 bytes long."
The same can be said of Ansi, for that matter:
"Except Ansi is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 1+ bytes long."
--
Remy Lebeau (TeamB) |
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
Jeff wrote:
Except UFT-8 is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be up to 4 bytes
long.
The same can be said of UTF-16:
"Except UTF-16 is not a 16 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 2 or 4 bytes long."
The same can be said of Ansi, for that matter:
"Except Ansi is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 1+ bytes long."
+1
--
Dalija Prasnikar |
|
|
|
|
Posts:
332
Registered:
4/6/00
|
|
Except UFT-8 is not an 8 bit string encoding scheme. It is a variable width
encoding scheme that a single code point can be up to 4 bytes long.
Dalija didn't suggest otherwise. '8 bit strings' = strings with 8 bit, 'AnsiChar' elements in Delphi-land. A UTF8 string type with 16 bit, 'WideChar' elements would be odd, no? |
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
What compiler features you expect/want/need on Linux?
Personally, I could probably live with ARC (performance wise), but if anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way there.
UTF8 in -> UTF8 in the middle -> UTF8 out.
Well, UTF8String and RawByteString will be supported on Linux, and they will
also find their way to mobile compilers. Great
But it seems that Linux compiler will also have ARC. Fine for me, too.
https://plus.google.com/u/0/+HoracioJoseCavalcantiFilho/posts/eKEEmp3tCjx
--
Dalija Prasnikar |
|
|
|
|
Posts:
143
Registered:
2/17/02
|
|
I missed the end of the discussion.
A lot of material here.
Well, UTF8String and RawByteString will be supported on Linux, and they will
also find their way to mobile compilers. Great
Good sign.
But it seems that Linux compiler will also have ARC. Fine for me, too.
I'm NOT fine with that.
It would disallow to share the same code between Windows and Linux, for server apps.
Maintaining both ARC + not ARC low-level code is not an easy task... very time consuming, for little benefit.
|
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
But it seems that Linux compiler will also have ARC. Fine for me, too.
I'm NOT fine with that.
It would disallow to share the same code between Windows and Linux, for server apps.
Maintaining both ARC + not ARC low-level code is not an easy task... very time consuming, for little benefit.
I think that is because long term goal is to merge compiler features and
have ARC everywhere. And while pushing ARC on Windows may be
risky because of all existing code, ARC on Linux does not carry that burden
and it can be perfect place to polish and improve performance.
Having two memory management systems in place is pretty bad situation
for people that have to manage code across platforms. That is the main
reason why I am looking forward to ARC on Windows (eventually). You
cannot embrace full power of ARC if you have to make your code work
on non-ARC compilers too.
--
Dalija Prasnikar |
|
|
|
|
Posts:
143
Registered:
2/17/02
|
|
Having two memory management systems in place is pretty bad situation
for people that have to manage code across platforms.
I agree.
But on the contrary, I did not ask for ARC, nor needed it.
I'm fine with current memory management in Delphi.
Introducing ARC did break the Delphi platform.
See what I wrote to Allen in the G+ post.
If the Linux compiler would be ARC, it would be difficult to work with for me.
It would disallow to re-use the same code between Windows and Linux, for server apps.
Maintaining both ARC + not ARC low-level code is possible, but not an easy task... just to release the resources when needed, or do proper circular references, you would definitively need $ifdef $endif blocks... very confusing and time consuming, for little benefit.
If only ARC would be a compiler switch, for the whole project? If you need ARC, just use it. If you want to re-use an existing code base, disable ARC and use the "classic" mode.
If there is no efficient Linux debugger (I guess it would be GDB-based), it would be very difficult to track ARC-related issues. On server side, a memory leak is even worse than on desktop side! For mobile platforms, most of the memory is allocated via TComponent ownership - so ARC was only used at lower level. But for a server running 24/7, any resource or memory bug would be a nightmare to track.
I usually stabilize a server app under Windows, then cross-compile with Kylix (or FPC) to get the Linux version, which runs with no surprise. If there are two diverse models, it would be very time - and therefore money - consuming, for no benefit.
|
|
|
|
|
Posts:
2,325
Registered:
11/9/99
|
|
Having two memory management systems in place is pretty bad situation
for people that have to manage code across platforms.
I agree.
But on the contrary, I did not ask for ARC, nor needed it.
I'm fine with current memory management in Delphi.
Introducing ARC did break the Delphi platform.
Agreed.
While I am fine with or without ARC I am fully aware that ARC may
be problem for others.
Like I said having two memory management systems is unbearable and
from that POV I will welcome ARC everywhere. But I am still not sure
whether introducing full ARC compiler in the first place was good or bad decision
and I am more inclined to the later.
--
Dalija Prasnikar |
|
|
|
Legend
|
|
Helpful Answer
(5 pts)
|
|
Correct Answer
(10 pts)
|
|
Connect with Us