Wow! What an input! There was also a bunch of posts in forums, of course. I tried to let the information flow to be free as much as possible (even if I was tempted to response in several times) in order to gather a general idea on what’s happening:…
First of all, I do think that Embarcadero’s decision to go cross-platform instead 64-bt first is / was the right one. Yes, I know that there are certain kinds of applications which require a 64-bit compiler (like the applications which need more than 32-bit memory addressing and the ones which interact with an 64-bit OS (shell extensions etc.) – tell me if there are other kinds) but the community’s voice was / is more to cross-platform than 64-bit – see here where the cross-platform issue gained a substantial lead vs 64bit and here where the 64bit compiler and the cross-platform are (almost) head-to-head. But if you want, we can do a poll here (thanks to your interest, we have a greater traffic 🙂 ) – if someone is interested please drop a comment, even if it’s a little bit late now – they already are in the works with the ‘Project X’ and revamping the compiler. Perhaps a less known bit of information is Barry Kelly’s question on Stack Overflow – see it here.
In the other courtyards, there are also a much stronger focus on cross-platform than on 64-bit computing. For example, while in the last years Adobe had the same revenue from Macintosh products compared with the ones for PC, Scott Byer, Photoshop’s software architect is quite reserved in his blog when it comes to jump in 64-bit bandwagon. In fact this is, generally, the position at Adobe. Strong commitment for cross-platform, slow advancement on 64 bit.
Same for Microsoft. Office 2010 will be the first version for 64-bit whereas the first Excel was for Mac. (since… how many years?) And since then there were constant versions of Office for Mac. Also there were separate versions for Word and Excel. (ok, you can flame me: Microsoft didn’t produce anything for Linux…) So in my humble opinion, not here is the problem.
The main problem is to meet the user expectations.
Surprised? No?
Many said that with Kylix the problem was the price, the bugs / instability, CLX, lack of market culture to adopt a commercial product for Linux etc. etc. etc.
But I think that the main problem was that they failed to find in first place what the user expectations where and after this to fulfill them. If they’d keep asking early ‘We’re doing the things right?’ and had the humbleness and flexibility to listen, then they weren’t Kylixed. The same, of course, happened with .NET strategy (CppBuilderX anyone?)
Fast-forward today. It seems that, by far, the main problem is VCL (correct me if I’m wrong). IDE will stay the same, RTL isn’t such a big problem, the compiler… oh, the compiler – ok, it will be a new one. But the bugs will be ironed out. In a ‘few days’… 😉
And from what I saw, nobody from us has a ‘right’ global view on what it should be done. (sorry guys 🙂 – me included – I didn’t say that I know how it should be done). The thing is so complex that only by an incremental approach it can be perfected. That’s why I think that the only chance for the new ‘baby’ to be born is to find a common vision on what should be delivered. Ok, perhaps some of us are biased speaking from the point of view of their applications, but please try to see the community as a whole and be more neutral. From materials which I gathered there are some points to discuss (some of them are contradictory, as you’ll see):
- it should be one core VCL 2.0 with ‘painters’ (look-and-feel controllers) for each OS
- no, it shouldn’t have ‘painters’ – it’s enough to look ‘acceptable’ on each OS
- no, isn’t enough to look ‘acceptable’ – it must look exactly the same
- the above VCL 2.0 will have platform-specific extensions – classes, units etc. (eg. TRichEdit, TNSBrowser etc.)
- the VCL 2.0 will try to keep a (limited) compatibility with the present one
- no, it must be a totally different library (most probably a Pascal layer over an already existent one like Qt, wxWidgets etc.)
- no, each platform must have its own libraries VCLWIN, VCLOSX, VCLLINUX
- some mix of the above
- something else? 🙂
Wings of Wind Software 
Geez, not again! Why do you think this time will be better then the previous one? I mean Kylix and .NET was such waste of time that brought to downfall of Borland. Why repeating same mistakes again and again…
What about VCL? I can’t imagine how they will preserve the compatibility with Windows VCL and at the same time will make it happen with the other platforms.
The people want cross-platform support, but they want it seamless. And with cross-platform it is NEVER seamless (except for “Hello, World” example).
The people hearty welcomed the new Delphi. It finally has some long ago desired features. But some of these features are about 10 years too late.
I hope 64bit support won’t be that far in the feature, cause otherwise I’ll be forced to switch my favorite developing tool with something else.
I’ve been found much interesting your post, thanks 🙂
I want give you a question: why should I’ll pay and use ad hipotetic delphi cross platform, when there is YET a free pascal compiler with its IDE called Lazarus?
Just for discussion 🙂
bye
Corrado
Have you try to developpe a professional application with lazarus?
Lazarus is not enought stable.
I’m an early FPC developer. I’m a professional win32 delphi developer since many years, I’de worked with D5,D6,D7 and i’m still developing with D5 and D7.
I want move to linux for a lot of reasons.. my natural migration path leads me to FPC. Obiously I did’nt still made any professional application with FPC, but the FPC community is very vary active, bugs are corrected in hours or in days!
You don’t have to wait for the service pack like win32 delphi compiler.
As an opensource project, you can have many intermediate releases between the majors and stable releases, but this don’t mean that you are using an unstable compiler. It’s enough to use only the stable releases.
Note that i’m spoken about FPC, the free pascal compiler, NOT about LAzarus, the most used IDE which drives FPC to compile native crossplatform code.
Bye
I make professional applications with lazarus that have to run 24/7, mostly unattended.
Yes, it’s difficult to keep up, since it’s improving day after day and you have access to every revision, but I wouldn’t say that it’s unstable.
Well, i dont know wich is exactly for you a professional application.
My company have 100s 24×365 servers builded with FPC/LAZARUS/Data Abstract runninf from two years ago. That servers are not only database servers, also interact with embebbed devices via ETHERNET and RS232/RS422 ports, real time.
Is enough professional for you? 😛
Neither RAD stdudio 2007, 2009 or 2010
Even the last RAD Studio 2010 trashes some project files or stop working (i tried to recompile DEV-CPP for testing and i only could open a single form).
Embarcadero released RAD too early, it was not enough time to stabilize it, the unicode issue was a huge effort and the gesture integration with VCL was pretty and the new tier app wizards were interesting but the template issues for C++, the sudden death of the IDE in the middle of anything yo do and the mess they call documentation makes you wonder why would you pay near 1500 Euros for standard or 4500 Euros for architect while you can get the infamous visual studio 2008 Standar for 250 dollars, Professional for 500 Dollars and well the development premium edition for 6900 Euros.
You speak here about C++ personality, right? – I confess that I don’t have much experience with it. The Delphi part is quite performant (including the IDE)
My dear friend, with all respect, Maybe Kylix is already dead, but despite is a relic, is IMHO more complete than Lazarus is today.
Best regards!!
FCG
We have to decide first WHY anybody would want to use Delphi on a foreign platform. I don’t think even that’s clear yet.
The dream of writing once and compiling for anywhere is naive.
For example, when Kylix came out, we were told the way Qt and Windows interact with their client programs is fundamentally different. That is why, in part, CLX was necessary. Imagine a CLX (or VCL) to cover all OSs in all versions. It would be a monster. Delphi doesn’t even wrap the Win98/XP Unicode change transparently.
And how do you cover the situation when you get functionality in one that does not exist in another? Ignore? Simulate? Offer only for relevant target?
“We have to decide first WHY anybody would want to use Delphi on a foreign platform.”
Don’t worry, it’s plenty of them. As there were millions of developers wanting to use Delphi and VCL.NET on .NET. Unluckily they discovered they wanted to use .NET. But using VS and C# – not Delphi.
“we were told the way Qt and Windows interact with their client programs “. It’s fundamentally different how GUIs works under different operating systems. Windows is message based, for example, other platforms are not. People hoping Delphi will mask the underlying OS idiosincracies will soon discover than anything but trivial applications need enough skill programming non-Windows OSes.
I am also worried about the time they could need to build a good xplatform solution. Porting VCL to 64 bit would be much easier than building a new VCL from scratch supporting at least three operating systems. I guess it would take at least two or three releases to reach an usable one. Meanwhile I am afraid they will stall other developments – and we will be pushed back to the D7-D2009 limbo.
“Unluckily they discovered they wanted to use .NET. But using VS and C# – not Delphi.”
Indeed, that’s me. D8 was my introduction to .NET, and was what ultimately pushed me to C#
I don’t have a problem with cross platform support in Delphi. I do think (IMO) it is a mistake to delay 64 bit support (yet again) in favour of it. I also think the VCL arguments are really just a distraction.
IMHO, 64 bit, cross platform and .NET support are more about being able to compile your code against those platforms than the VCL. Issues with VCL support are secondary. I’ll repeat that: Issues with VCL support are secondary. Once you can compile against a platform you have the ability to deal with your VCL related issues in a way that suits your purpose and application platform.
So, get the compiler support sorted first, then worry about the VCL 🙂
…but we can speculate ’til the cows come home. If Wings of Wind, you know something/are permitted to reveal something, then let’s hear it.
Otherwise we’ll just repeat the same arguments again and again.
…OK, so we can check out Eli Boling’s blogs at the Embi site. He’s doing Apple, targeting OSX only. Interesting reading, if you’ve ever worked at that low a level.
64 bit is SPEED! I develop native software for engineering calculations, I need SPEED! I have the (very good!) math library from DewResearch but they can´t go 64 bit untill Delphi goes… The 4GB limit is OK for the matrices I use (althought someone else could use bigger ones) so getting more than that is a bonus, what I do need is speed and precision.
Why do you think 64 bit is speed? The only reason I can see is that there are twice as many CPU registers. That may get you a 20% boost, but that’s not shocking is it?
More registers can mean better optimizations. Do you think a 20% is bad when it comes to engineer calculations? Also targeting the more recent instruction set would allow for even more optimizations, which Delphi can’t use right now. Operations on large integers may require less instructions. It won’t speed up your average db front end, but there aren’t only those.
And having more memory available could mean to avoid to swap to file and process data in memory.
I do calculation heavy programming myself, so I well appreciate any speed improvement. But I think speed isn’t a good 64 bit selling point. The difference between compilers is greater than the difference between 32 and 64 bit. A 64 bit version of your Delphi code could even be slower than the 32 bit version, who knows 😉
I want 64 bit Delphi as much as the next guy, but from a technical standpoint the bigger address space is the only reason. Customers wanting a 64 bit version just because they want it is also a good reason 🙂
hey, I´m doing this since 8 bits 🙂
when the microprocessor has its math instructions rewritten for the bigger word and bigger registers, they became faster – just try to compile the same code on Delphi 1 and 2.
Floating point math uses 8087 or SSE anyway, so there’s not much to gain there. The only thing that would really benefit from 64 bit is int64 math.
I suggest you compile it with lazarus… If you have mathematichal functions, and you have enough isolation of GUI from bussiness tier, you can do the GUI with Delphi and the bussiness tier or mathematichal libs in FPC! Easy.
AFAIK, FPC code is not that optimized at all. You can have all the library you like, but if the compiler performs poorly that’s nothing you can do. Check why some windows/linux applications are compiled with Intel compilers…
You are wrong. Or in anycase, just show us where you get that info?
Just search the Internet. In any benchmarks I saw, Delphi outperforms FPC. And Delphi compiler is not really the best of all today, much could be done to improve it.
It’s surely easier to optimize a compiler for a single hw/sw platform, than having to optimize if for several.
Again, you me your sources. FPC compiler is good enough. You are wrong.
64 bit is NOT Speed! Re-read again what I wrote. Especially the part about Adobe and Scott Byer. Be sure to read his blog post. Link in my article. (FTR, 64-bit is speed only if you hit 4GB and you need to fall on disk). Basically the problem is that the chunk of data to be processed is twice as bigger and RAM is a bottleneck nowadays compared with CPU cache (all levels).
First, you don’t hit the 4GB barrier: under a 32 bit operating system you hit the 2GB barrier (3GB with the 3GB switch). How much speed you gain depends on the size of data you manipulate and how – why processor has instructions to manipulate data larger than 64 bit already? SSE uses registers 128 bit wide, for example. Photoshop is *one* application. Not all applications are like Photoshop. I’d suggest you to go to the source, read Intel manuals first, not just some blogs. 64 bit is many things, including speed.
Another note: multicore processor allows more threads to be run concurrently. But threads share the process memory space: the more threads, the more memory you may need for the process to allow each thread to allocate enough without going to disk. Or you rewrite your app to be multiprocess and not multithreaded (which under windows may not be the right choice), or the number of concurrent threads you can run gets limited by available memory, if your application is highly parallel and each thread may allocate lot of memory.
Almost all the application segment of the IT market is against you. There is big pressure in gaining new platforms MacOSX, iPhone etc. Give me some references (except server market) where the 64-bit is a concrete and big selling point compared with all the fuss and the buzz around Mac, Linux, mobile etc.
You are right: there is a lot of fuss and buzz around Apple, but their products are a still a *niche market*. You should stop reading blogs, and look at real companies. Don’t expect anytime soon lots of office workers with MacOS machines on their desktops. MacOS is tied to an expensive although stylish exclusive hardware platforms – and it totally lacks a server platform, but a very low-end one good for very small offices.
Same for iPhone – lookt at any company and you’ll see much more Blackberries and Windows Mobile devices than iPhone or Androids. The consumer market may be slightly different, put Windows PCs still outsell everything else. And again, only Apple makes money on iPhones – AFAIK noone became rich selling iPhones apps.
The fact that a small but with a big Internet presence group of geeks prefers MacOS or Linux just to show they’re smarter, does not enlarge their market share at all.
And when you say “except the server market” do you understand you’re ignoring a very large market segment? Why should it be an exception? Do you believe all Delphi developers just develop small desktop utilities? And even if your target is Linux, do you know how many 64 bit Linux servers are already in production, given it does cost nothing to upgrade and exploit your new powerful hardware? All our Linux servers are already running 64 bit Linux. Even if we get a 32 bit Delphi Linux compiler, it would be useless for us.
Luigi, almost all serious DTP is on Macintosh, believe me. And this isn’t a niche market. And, no, I’m not a Macintosh fan.
Also, we’re Delphi developers, but, no, we don’t develop small desktop utilities. But anyway, I think that this discussion is moot. We’ll have cross-platform first, either if we like it, either not. And believe me, there are almost no chance for our applications to have an easy conversion path to cross-platform, even if we’ll have this as a target.
DTP *is* a niche market compared to the global “office workers” market. Just look at how many Apples are sold compared to Windows PCs. Apples are expensive compared to the average Window PC, and you’re tied to a single HW vendor.
Good for small office or departments, but they will never go beyond that. Apple knows it’s better for them, they have to justify their higher prices and margins with “exclusivity”.
Apple has still a strong market in the image industry, but it has no longer the advantage it had over Windows several years ago. Mostrly, they uses Apples because they are used to. And why Adobe would release all those Windows versions if they weren’t sold and used?
Anyway, to sell in the Apple market you have to meet its users expectations. If you release applications wich are not fully MacOSX integrated, believe me, they won’t sell. Maybe a DBA could use a DBArtisan anyway on a Mac, just to justify the higher price for a laptop to manage a remote DB.
Well, if they are going xplat before 64 bit we will simply avoid to upgrade – let’s see how well that version performs – if it can outsell Delphi 8…
BTW, if you run a Win32 process on Win64 it does get access to 4GB of memory.
To be honest I want the cross platform (mostly for OSX), but if they are going to do another QT CLX type thing, then rather bin it and give me 64bit. I want a VCL that functions the same across all the platforms, or I’m wasting my time. Yeah I know wishful thinking, but the QT CLX thing was a complete load of rubbish.
Lom you will ever waste your time if you think this 🙂
The only VLC I known that, as you said, “functions across all platform” is a JAVA GUI (swings), because it runs over a VM.
Delphi cross platform will generate native compiled code for differents platform, and it is impossible to keep the code unchanged.
Take a look to Free Pascal Compiler to understand why you have to change your code in dependency to platform you would compile.
Bye
Swing works across all platform because 1) Draws everything itself 2) Does not use OS widgets 3) Uses its own look and feel and controls. A “XCL” could to the same, but would hit the same issues Swing had: 1) slowness 2) look and feel “alien” on each platform.
A mixed approach could be that swt, qt, wxWidgets, which try to use the OS widgest when possible. The risk is they can’t take advantage of advanced features of widgets, and may lack some not common on each platform. And an “XCL” should use the same approach, but shouldn’t use one of those libraries because it will end up to be a wrapper of a wrapper, with the perfomance issues implied.
But reimplementing a library from scratch will require time and resources, and first releases may be problematic, both in stability and number of controls available – unless Embarcadero really surprise us.
“I want a VCL that functions the same across all the platforms”. Then ask Apple to support MS APIs, or viceversa. CLX used Qt exactly because of what you asked for. You can’t have a library GUI that works the same across all the platforms unless you accept compromises. Qt, wxWidget, whatever, are compromises. And they are already wrappers. If Embarcadero builds a VCL wrapper over another existing wrapper performance may not be goood – and they would have a strong dependency on somebody’s else plans. They can build their own wrapper, and it would take much more time to develop a full scale one – and anyway you would get a compromise again – platforms are still too different to have a good one. For example, what about ribbons in MacOS or Linux? And would users like them or not if that’s not the standard interface?
For example, I want a VCL that functions the same across all the platforms, because of otherwise a such VCL library is useless. In addition, VCL provides a good level of abstraction from the platform, sufficient for the most applications. The maintenance it the same on these platforms is not unsoluble problem. Ant it dosnt require from Apple to support an Win32 API. However, I agree with you that it will require substantial time. And I think that Kylix 20xx we will offer the continuation of CLX. And what are the problems with the ribbons. This is just a concept, a species of toolbars. It does not depend on Win32, and you can implement it on any of these platforms.
VCL is far less abstracted than you think. It’s a good OO encapsulation of the Windows API, but it’s very tied to the Windows GUI model. CLX was born because it was almost impossible to port the VCL to Linux. Of course it’s possibile to have a xplat library – just it must accept compromises. Those compromise may be acceptable for some applications, or may not be for other applications – it depends on teh GUI complexity and the integration required with the underlying OS.
Ribbons in Windows 7 becomes native controls with a COM API, and don’t require any longer to be implemented from scratch. There are also patents on them – don’t know if they can be easily implemented outside Windows.
64bit has and always will be our priority. We need the increased memory support. We have already smashed our heads against the /3GB limit on a number of occasions and have been “relying” on Borland/CodeGear/Embarcadero delivering on their “promises”.
At what point should we jump ship, bite the bullet and re-code in a tool that gives us the capability we need. Should that have been 3 years ago, 2 years, last year or now? Every year they hold out hope of 64bit compilation. Every year a “valid” reason comes along to kick it into the long grass. As of today (after the Michael’s roadmap address) we still aren’t ANY clearer on what will be delivered and when.
Cross platform. Great for everyone who wants to relive the glory days of Kylix. Ok, they may find a way to get it right this time. The market may exist and developers may be ready to pay for Delphi on other platforms. I’m certainly no expert in this area, but I’ll be extremely surprised if they pull this one off and make money out of it. I do hope I’m wrong as another wrong turn won’t exactly help matters.
Widening this out, my general view is that Embarcadero should stick to the plans they publish. Yes, they caveat everything in safe harbor terms etc, but at some level, they are wanting the community to buy into those plans. That means commiting products to a certain track. In our case, we swallowed each and every roadmap that offered up the expectation of 64bit. With 20/20 hindsight, we’d have been out of this community 3 years ago and griping about some other tools provider by now…
And finally, before it is pointed out that roadmaps aren’t cast in stone, can I ask where the preview 64 bit command line compiler is that was promised for mid 2009 and demoed some time back? Nick Hodges did give a very reasoned and rational explanation as to why the whole thing was being re-engineered, but nonetheless, prior to that particular bombshell, the community could almost taste the 64bit product simmering away in the labs. Now we don’t even rate being told what time dinner is likely to be served….
@Paul: I am with you 100% on this. We need 64 bit to get at > 4GB memory. Nowadays we can buy machines with 16Gb for very reasonable prices, and we could use it all…
3GB on Win 32 with /3GB switch is a bit of a hack (and Windows is not as stable under load either). 4GB on Win64 is better, but it’s still not enough.
My priorities for Delphi are get 64 bit out the door and fix Prism wrt object pascal compilation.
@ Raymond. We’ve found the /3GB to be very reliable. You definately get issues if you have a beefy machine (lots of RAM) and try to get clever by enabling /PAE as well. That ends up eating lots of free page table entries (PTE’s). Google around Exchange server as there are quite a few things written about it in that area – but it applies generally. In fact we’ve seen it in practice and cured it by getting rid of the /PAE that someone in their wisdom thought would help…. On 4GB on win64, yes we need to look at that as it will give us a 25% boot. I’ve not had any experience yet, but the theory is there. Have you pushed it to the limit in thsat configuration? In the /3GB on 32 bit, you can also seem to have problems approaching the 3GB if your application is consuming memory at a rapid rate. It looks like windows tries to allocate a large block of memory in anticipation, fails and thus you can actually run out of juice before hitting the limit. A slower rate of attack gets you right up to the 3GB limit..
We also need to look at implementing AWE on 32bit, but are reluctant due to the effort required in the application and also the implications if and when 64bit comes along…
Paul,
Our memory allocation growth rate is usually gradual (in that it’s more tied to I/O performance than anything else); we have not seen the issue you mention as you approach the 3GB limit.
We have not done any significant stress testing of 4GB under Win64 other than to verify it works.
AWE would be an answer, but comes at a price of complication and is only supported on upper strata Windows Server systems (and Windows 7, to some extent too I think). If we were forced to consider AWE as an option I think I would look at spawning child processes that serve as buckets of memory (and that’s only going to fly on Win64 systems anyway) as this might be a simpler solution given our architecture.
I think “they” recommend AWE is good for addressing upto around 16GB. After that all bets are off. Of course that it is 2GB at a time at most. The requirement for upper end windows server platforms wouldn’t be an issue for us, but the complication of AWE certtainly is. The nature of our application would preclude spawning child processes but we would have to partition memory somehow. We basically have upto 400,000 entities (depending on the customer), each with a number of data sets (we use DIContainers for these). So somehow we’d have to farm out those data sets with AWE and when we need them, page them back in. Only problem is that we need them quite often!
You will never make money selling development tools to linux developers. You will equally never convert enough windows programmers into linux devlopers to make a profit selling it.
Why? Linux has MANY free compiler options already, including free pascal, and except for the server platform the Linux market is far too small to make it worth the migration effort for most developers.
Worse, though those involved in OS development claim that the free software movement behind linux is about free like beer, for many users it is more accurate to say it is free as in load. Most of your potential customers are currently developers. If you release a closed source for profit app, chances are no one will buy it and if it is a good enough idea, a group will form to create a free open source alternative.
You aren’t going to open source and give away a perfectly viable Windows product just to make a few linux geeks happy – so who does that leave as the audience for a Kylix project again?
Let’s face it, Embarcadero isn’t going to open source the Kylix IDE and compiler for exactly the same reason.
So, let us admit once and for all that Linux is a DEAD TARGET for cross platform Delphi. Not going to happen. If Embarcadero is foolish enough to try, the product will die within 2 releases AGAIN. No.
Let’s be honest, the only serious cross platform target is Mac OSX – now THERE is a group, regardless of its small size, that is at least willing to pay top dollar for their software. Fortunately, OSX is based on FreeBSD, which is close enough to Linux to make many of the compiler target issues at least familiar ones, recovering some of the effort for Kylix.
(There is one other area that Linux shines – embeded devices. I do not, however, see Embarcadero creating a dozen different cross compiler engines to make this a realistic goal for Delphi ever – so I don’t even usually consider it worth discussing in reference to a kylix ressurection)
So please, PLEASE, LET KYLIX DIE. It was a huge HUGE mistake, doomed before it was concieved, repeating the process will not change the outcome.
Too many developers babble about “cross platform” without ever trying developing software for a different platform – and Embarcadero will discover soon how many won’t go multiplatform because they have not the required skills.
This is the third big mistake in a row, after Kylix and .NET. Delphi development is stalling again, and we will pay the price of being unable to deliver what we need.
“Adobe had the same revenue from Macintosh products compared”. C’mon guy, Adobe was born on the Mac, and sells tools aimed at people who’s being using mac for ages, how many Apples do you believe to see in the average company, where humble data handling Delphi applications are used?
Adobe is slow on 64 bit because Carbon was not ported to 64 bit – only Cocoa is available, and they have to rewrite Photoshop using Objective-C instead of C/C++ – and 64 bit Windows Photoshop is already available.
Delphi really needs new people, the old ones aren’t able to understand where to go really – they jump from a bad idea to another. And never learn.
I suspect PlatformX addresses a need in Emracadero itself.
If so, we have both the tool writers and tool users talking to each other.
I do hope you’re not right Ken. That would be too incestuous and at the expense of their customers.
It has advantages and disadvantages.
If Embarcadero database tools are the driver for Delphi I would be very worried. First, I was never impressed by Embarcadero tools, they even look a bit outdated. Second, the DBA is not a common kind of customer – especially the Oracle ones – they may not need very advanced guys, usually they need power.
64-bit is much simpler than cross-platorm, so I think they will do both in parallel.
Windows 7 64-bit will be ~ on half of win-users computers in 1-2 years.
So EC will do all right, they are no foolls.
64-bit is much simpler than cross-platorm, so I think they will do both in parallel.
Windows 7 64-bit will be ~ on half of win-users computers in 1-2 years.
So EC will do all right, they are not foolls.
IMHO and as I see how this is evolving:
* A new compiler is needed for 64 bit
* This is the reason why a cross compiler IS a priority: 64 bits will be another platform target.
* Aparently it’s easier to get the cross compiler ready for Linux and OSX than for 64 bit, and here i’m talking ONLY about a base compiler (non VCL only console mode)
* Once they get a functional base multiplatform compiler then you can think on what to do with the UI, I think we can consume any type we want: a QT wrapper, a wxWidget wrapper, native implementation or even X.
Personally we need a Linux-console-only-compiler for our server development.
If you need a Linux console compiler for server development, just trys crosskylix: http://crosskylix.untergrund.net
This cross compiler needs a Kylix original CD, and is not maintained any more, but it’s very easy to use and cross compile any application from the Delphi 7 IDE. You obtain a true linux executable, very stable, small in size, and very fast. It is the same compiler than Delphi 7, it uses exactly the same language (and assembler) features than Delphi 7, and all low level VCL (not GUI, but Classes, SysUtils, etc…) are 100% cross platorm. Synapse is OK for network cross-platform programming. You can also use multi-threading and FastMM4 memory management in your application. We obtained for some of our applications a very responsible system.
In my web site http://bouchez.info I have posted some optimized LVCL units, and will soon release custom system.pas and sysunit.pas for cross platform development between Win32 and Linux. I’ve only found a unicode setting problem with the RTL, which prevent widestrings to work properly on modern Linux system with UTF-8 encoding set as default.
Thankyou for this post, i didn’t know crosskylix!
I forget to mention, please dont use QT! If lazarus/fpc can do it with native code, Embarcadero can.
There is no native UI in Linux, the most *native* on Linux would be X or framebuffer….
Lazarus AFAIK uses GTK
Lazarus has GUI ‘plugins’ essentially, and you can switch between widgetsets. The default on linux is GTK, but it also supports QT, GTK2, on windows direct winapi, and on macs their native interface.
And that’s precisely the way Embarcadero should do it.
Well, nothing is native in GUI. Windows also use libraries ok? In linux you have options GTK, GTK2, QT, and specially in Lazarus fGUI, Cocoa, etc.
I did not see an option for 64-bit, that is why I voted for cross-platform.
I was wrong last year when I thought cross platform was more urgent because:
1. WINE got a immensely better in the past six months. You can run Delphi apps on Linux today using WINE 1.1.29 (free) or CodeWeavers 2.0 (not-free).
2. 64-bit is selling faster than expected (and will accelerate even more with Windows 7).
3. My 32-bit Delphi-created DLL’s doesn’t work in 64-bit MSVC programs because it isn’t even loaded into the same process.
Again, you can run Delphi apps on Linux today without even recompiling. Just use WINE 1.1.29 (www.winehq.com) which is free and it is light years ahead of 1.0. And a non-free version from CodeWeavers is available, too.
I’m all for crossplatform. Only not the ones mentioned here. Why does no-one talk about mobile devices like iPhone, iPod touch, android phones, etc.??? These are the fat clients of the next decade and they have no dev tool like Delphi to cater for them. I just don’t understand the focus here.
“iPhone, iPod touch, android phones” are the Game Boys of the next decade. You don’t see them really in any business environment.
I personally love the idea Kylix 2011 would be awesome, now this would make Delphi the best development tool on the market(with the right price…).
@JerseyGuy I don’t like Lazarus, way too many bugs and it’s not really helping…
@Tim I bulive Google will do something about Android OS, make a nice IDE or something
Bottom line, it shouldn’t be too hard for Embarcadero to make Kylix 2011, after all they have Freepascal(even Lazarus) as inspiration.
Do you have any reference about Google’s plans to make an IDE?
On the market there are already some offerings like MotoDev etc.
First, Embarcadero and all commenters should, IMHO, study Swing and SWT toolkits for Java. They are just “use Canvas and paint everything by Java code” and “use platform controls” approaches. Or like it’s called heavyweight and lightweigth controls. Both have as positive sides as negative ones.
Second. IMHO, VCL is way outdated in databinding, absence of multicast events, etc. When going X-platform I personnaly would prefer new good design instead of backward compatibility. Main points I would like to see are: new modern databinding, multicast events, property change routers (see JavaFX) and all the framework buit around MVC/MVP patterns.
Third. I think that to support creating X-platform applications for the first time its’ enough to have only non-GUI “server/middle-side” Pascal-coded components that provide support for JavaScript clients (even when run locally), say ExtJS or Qooxdoo. This way you can have X-platform, clean separation of GUI and scalability. Then, when you have a working solution you can address specific platforms (in some priority order) for thouse who need true paltform-tied functions.
Good contents!
As far as I know in D7, VCL is outdated but i don’t know if D2010 version too.. are there databindigs? MVC?
Maxim do you confirm what you said is even for D2010 VCL??
thanxs
Just the same…
No use of new generic types in controls, no use of “for .. in” when iterating fields or columns, etc. May be, still not found anonymous methods in VCL code…
Some is dictated by backward compatibility. Some by the lack of time/resources?
Anyway, I don’t ask to massage VCL code. Because we (sorry, I) would like to see completly new VCL.
“Just the same” – well, somewhat but not quite.
They fixed a lot of bugs but they didn’t use their new language features in the already existent source code in order to not introduce new bugs. But if you’ll look at the new RTTI engine, new Gesture engine or IOUtils then you’ll see that they’re full of generics, class constructors, anonymous methods etc.
That VCL is now a bit old is true, but please keep Javascript away from Delphi code 🙂 If there’s somehting I hate is to mix too many languages within an application code. The web is already gone to far in mixing as much as different languages in one single application as it can. And without a native GUI, what would be the Delphi appeal on other platforms? Especially MacOSX which doesn’t have a server platform at all?
One of the biggest mistake Embarcadero could do is to tie a xplat Delphi to “foreign” technologies it has no control over. Look at what happened with .NET. It would require lots of compromises to fit the Delphi model to other different models. What would be the payoff?
I don’t speak of JavaScript instead of Pascal. I mean use Web browser instead of platform-specific controls. Modern JS libraries are quite sophisticated for general UI. If you have not enought resources to address all possible platforms using either Swing-style ot SWT-style approach in one-year timeframe then it’s just OK to provide a way to do cross-platform with server (or model)-side code and Web browser as a pure UI part. And if you don’t like JS then you have ExtPascal (http://code.google.com/p/extpascal) or Raudus (http://www.raudus.com).
What if they’ll give you an abstract canvas and you’ll do there all your painting?
Also, perhaps they’ll will provide some ready made controls. FEW controls. This will be as an addition to the other dedicated GUI solution(s) provided OOTB.
“What if they’ll give you an abstract canvas and you’ll do there all your painting?”
If you want to race for the “slowest interface ever made” it’s a good solution.
You spoke about “native” GUI. Btw, what means native GUI on Linux?
Or do you think that they’ll deliver in a year (together with a new compiler etc.) a library with a maturity comparable with Qt / wxWidgets etc.? Most probably they will base their abstraction on such a library (GTK etc.).
What I meant (and I still do) is to provide an addition to this, having a TxCanvas (think at a cross-platform TFrame) where you can do your really cross-platform GUI – no need to redesign parts of your GUI three times – and in fact in some cases (most notably on Linux) it will draw actually faster. Or perhaps do you want to work directly with the X server?
What’s the benefit? Why should I buy an expensive tools to code Javascript interfaces to be run within a browser (and you still have to code a form designer to handle them… or why should I use Delphi) when I can write them with lots of free tools? Or write a whole web application?
IMHO the only opportunity Delphi has to become an appealing xplatform tool is to offer outstanding RAD native development on each platfom – which was what made it the toos of choice for many under Windows. If it will offer just compromises and half baked and half working solutions it won’t go far and will be soon and easily forgotten. While Delphi 1 could build on TurboPascal strong user base and reputation, an xplat Delphi must counter a declining user base and a bad reputation built in the past years.
Personally I do not understand this Embarcadero movement. Multi-platform has been tried in the past with no much success (both in IDE side -CBuilder/X- and in the target platform -Kylix-).
The problem has always been reducing Windows capabilities to be able to run under a toolkit like Qt on other platforms.
I would bet for 64 bit support, and also more efficient generated-code, which is the main problem since Borland/Inprise/CodeGear/Embarcadero days.
Ok, native Kylix for all platforms and a new CLX open source project (started by Embarcadero) because we need new releases of CLX with every new release of Qt.
Qt must not be embeded on Kylix. CLX must be able to use an already instaled Qt library.
Of course, Embarcadero can sell Kylix with different GUI libraries, native for all platforms but for crossplatform development, this CLX project must exist (it can be cheap because it needs few project leaders from Embarcadero and the team can be made from international volunteers – no headaches).
You want maximum speed on your system? Then use VCL and other two (?) libraries for Mac and Linux.
You want crossplatform? Use CLX based on the latest Qt package (just download it form Embarcadero servers – or google code, or sourceforge)
Good enough?
Vasi
Otherwise, Lazarus+fpc is continuously advancing and in 2011 you will have a nice crossplatform RAD being able to compile Delphi projects. Inevitable.
Vasi
Well – time will tell. I’m a little bit reserved that their development model + team can compete with Delphi’s one. But let’s see.
Well I would like to have cross platform support in Delphi, because we could potentially get new customers.
However 64bit support is more crucial because we are loosing our existing paying customers. A lots (most?) of new computers come with 64bit OS by default. And all the plugins for Office, Explorer, etc just CAN’T work anymore. Customers want and need 64 bit support. We can’t wait another year or two. This is it for Delphi. Deliver or STFU. Sorry but promising 64bit since 2006 and not delivering it, just does not cut it anymore. We have already migrated most of our application to .NET.
I have reported 56 bugs to Freepascal and currently 8 of them are still opened (4 of them are IDE related). So basically there is not much left from our standpoint to use FPC for production use. Cheaper and better (crossplaftorm and 64bit).
Well I still don’t get it. MAC Snow Leopard is mostly 64bit, 64bit linux installations don’t come with 32bit enviroment by default. Even installih 32bit Firefox is a pain. So why use half baked 32bit only Delphi Cross Plaftorm at all? Developers still won’t use/buy it, until there is 64bit support. Limiting yourself to 32bit only in 2010. All I can say is LOL.
http://store.steampowered.com/hwsurvey/ Well somewhat biased survey. Windows 7 are more 64bit than 32bit at 23% vs 11%. Surprised? No? Well Embacadero apparently should be. On Linux I expect 64bit version in 2010 to have even greater percentage.
Decision to go cross platform first is WRONG. Unless they deliver it with support for 64bit of course.
And a word of advice for Embacadero. Clear roadmap is a must. If I don’t have an idea when cross plaftorm, 64bit, etc feature is going to be released, I am not going use Delphi at all and fall for it again … Remember Unicode support? My bosses want solutions not excuses.
Embarcadero, please give us delphi with cross-compilation for OSX / Linux. The pressure is getting higher every day.
to correct myself:
Embarcardero, please give us at least some hints what will be needed to mac our apps ready for corss-compilation?
Will there be that VLC 2.0?
Will there be QT support?
Coming also… 🙂
…even if we aren’t affiliated with Embarcadero in any way.
Coming…
With Lazarus and FreePascal today, we can look back to Kylix with sympathy. We finally have what we wanted. A perfect viable and cross-platform alternative to Delphi/Kylix. And the good part is that the development is a continuous process.