November 5, 2008
Delphi Native Code: Fast or Reliable?
Delphi for Win32 is a tool focused on native code. Delphi compiled programs are fast... but does this really matter? In my view, reliability and stability are more important.
Delphi for Win32 is a tool focused on native code. Delphi compiled programs are fast... but does this really matter? There has been some debate over the last month, with CodeGear Product Manager Michael Swindell pushing Delphi for its fast compiled code, and Hadi Hariri and other bloggers disputing this idea. Truly, Microsoft .NET is not really slower than Delphi compiled code. So why does Delphi and its "traditional" Win32 support still matter, and matter quite a lot?
In my view, reliability and stability are key factors, more then speed. The fact is you can be sure your Delphi application of 5 years ago can be easily moved to Vista and Unicode support, without a total rewrite as in case of a VB application moving to VB.NET. Similarly, you might not be using the latest, smartest, and coolest technology if you create a Delphi database application today, but you can be pretty sure it will keep running for a few years. This means you can embark on a long term project with limited fears (now that Delphi has left Borland for a more solid company).
What about a .NET client/server application written today? Will you write traditional ADO.NET code, with no coolness factor? Will you use LINQ to SQL, which is being deprecated today? Will you use the Entity Framework, which looks great but is a brand new and far from stable technology? Will you wait for Oslo? And what about the user interface in case you don't care about the Internet? Will you use WinForms or the totally incompatible WPF? What will be around and kicking in five years time? That's very hard to know.
The same dilemma was there in the Java world in the early years, but after some time things got stable. Yes, they are slower to move than on the .NET platforms (or so it seems to me) but large corporations with long terms investments need stable technology, not ever-evolving-forever-beta cool architectures.
I keep thinking that if you can keep evolving a platform, adding new cool features, without disrupting existing investments you are doing your users base a huge favor.... Or am i getting too old to understand?
36 Comments
Re: Native code
Source code compatibility is definitely an issue. Borland/CodeGear have proven to provide backwards compatibility for many, many years, creating solid products. Microsoft, on the other hand, has a track record of creating backwards incompatibilities, and if their earnings and backwards compatibility should conflict in the future, they will always go for the earnings. There are still lots of VB 6.0 developers out there, because those old apps need to continue, but Microsoft won't help them. I'm a leader of a development team where we restrict the use of certain language features in order to ensure compatibility into the future and code simplicity. This saves money and secures our investments. I would not allow LINQ unless I see a business case that says that we make more money by allowing it, than if we didn't. Already, we don't allow pointer operations except in special units that are optimized for performance. I can read between the lines, that you guys are thinking about the future roadmap. Don't let Kylix make you afraid of supporting other platforms. I was one of the Kylix customers, and I immediately found the huge flaw in Kylix: It was sold as being "for Linux", but it was really for "Intel i386 Linux with specific libraries". Since CLX was very sparse, Kylix mostly made sense for industrial applications, and that required support for other CPU architectures, which was not possible and not roadmapped. You would have had more success with a Kylix that compiled for mono, or a Delphi that generated Win32 exe files that were guaranteed to work with Wine. It would give you all the VCL 3rd party components, and still be Linux compatible. I still test our applications with Wine from time to time, just to make sure that they could be deployed on a virtualized Linux/Wine, if needed. That said, what advantages does Delphi/Win32 give? I see several: Simple deployment, exe files run directly off a document folder, even on machine on which you have no administrative rights. Performance and memory usage: I don't know why .net GUI apps tend to be slow and memory consuming - but our apps are definitely fast and memory tight and always act in a predictable manner. The main disadvantage is memory allocation. This can be solved by proper code style guides, but it would be cool to see some kind of deterministic and automatic object deallocation. Don't use a garbage collector - it may perform better in average, but it performs in a less predictable way. And the question is, does the increased speed of the garbage collector system really outweigh the disadvantages of using more RAM? The multithreading advantages of garbage collection memory management can be solved in much better ways in the language itself. Garbage collection is a temporary good solution to multithreading memory performance, but when the number of cores goes up a lot, deterministic memory management will be necessary. I'm fully convinced that we will see more NUMA-like hardware in the future, where there is a thread/memory relation which determines performance, and where the language needs to help the programmer specify which threads use what memory, before it is being used. Just imagine 1000 mergesort threads on a 1000-core NUMA machine, that need to merge lists. The read/only data can be copied from core to core, but the resulting lists from each thread definitely need to be stored in the RAM associated with the thread's CPU, until it is ready to be copied to the next CPU. We need a language that makes this easy. Why? Because Delphi will still be around in 25 years.Comment by Lars D [http://compaspascal.blogspot.com/] on November 5, 20:52
Delphi Native Code Fast or Reliable?
That basically summarizes the problem of .NET. After 3 weeks of vacation you can't be sure that the framework you were using is still supported, has not been deprecated or replaced with something else. Less is more I think.Comment by Olaf Monien [http://www.monien.net/blog] on November 5, 21:58
Delphi Native Code Fast or Reliable?
I think this is a huge chance for Delphi. Lots of developers, including myself, are sick and tired of chasing the latest greatest coming out of redmond. C# has become incredibly complex in a very short time and there's no sign that this madness will stop any time soon. Delphi on the other hand is pure and simple. Beautiful. However, its major drawback is its narrow platform focus. I wish Codegear would focus more on bringing Delphi to more platforms instead of messing around with crappy PHP and Ruby- IDEs.Comment by fritz on November 5, 23:07
Delphi Native Code Fast or Reliable?
I'm in strong agreement with you here Marco, the speed
of the code is not the most important thing. I work
on a project that was originally written in Delphi 1
and has been under continuous development since then.
It has been compiled with every version of Delphi
(except 8 and 2005) and run on everything from Win95
to Vista. That is to say, portability between
versions is highly important to me.
Certainly when running on Win95 boxes ("fast" 486s and
Pentiums) the speed of the code mattered greatly, and
was a concern for us, however, the cheapest computer
you can buy now runs our software great.
If it had been written in VB, how many times would it
have needed to be rewritten from scratch? Or would I
still be stuck in VB6.
I've just spoken to someone migrating 1.3 million
lines of VB6 code to Delphi 2009. "Against much VB
patriotic zealots advice, I am pleased I have made the
switch". He sounds pretty happy.
Anyway, I'm starting to rant ;-)
Alister
Comment by Alister Christie
[http://codegearguru.com]
on November 5, 23:21
Delphi Native Code Fast or Reliable?
Totally aggree! This is the main reason I try to avoid .NET stuff. I've done a lot of VB back in the days of version 3,4,5 and 6, before I jumped in to Delphi. One of the main reasons for the move was that there was always a new and improved technology that you seem forced to adopt. So far my Delphi code has been stable and it has compiled across several versions without a hitch(As long as my third party components are up to date). And it is still a very much productive tool.Comment by Mane [http://www.open-consult.com/] on November 5, 23:47
Delphi Native Code Fast or Reliable?
I think that, programmers have their own fashion and they try to follow it, not try to make existing technologies better. Especially if that fashion comes from the big boss. "Hey look at that what a great idea that is the future!". In these days whatever MS makes, it becomes WOW. When the .Net first introduced it was lots of missing pieces if you compare with VCL. But third party vendors had closed that missing parts. Many software houses migrate their solid, stable projects made with Delphi to .Net. Why a person makes such a think? I can only explain that with "Following the Fashion" to my self. Market needs new ideas, products, ... for to be alive, for to make money.Comment by Namık Kemal Karasu on November 6, 00:32
Delphi Native Code Fast or Reliable?
Dear Marco, In my opinion, Microsoft .NET 3.5 is an stable and robust application platform. Although there are bugs but I prefer .NET to Win32. Why? A very simplified example: you can use Microsoft Enterprise Library, when you want to implement a composite/complex caching mechanism: Microsoft Enterprise Library http://msdn.microsoft.com/en-us/library/cc467894.aspx Or there are WPF data bindings too (the next generation of data controlled applications): http://msdn.microsoft.com/en-us/library/ms752347.aspx Microsoft Dynamics (CRM - Business Applications) http://www.microsoft.com/dynamics/default.mspx Azure Services Platform (ASP) http://www.azure.com Perhaps, it is time to change. :) Dear my friends, Delphi Prism is the future.Comment by daywalker [http://devportal.hu] on November 6, 01:29
Pascal is still faster.
http://shootout.alioth.debian.org/debian/ benchmark.php? test=all&lang=all&calc=calculate&xfullcpu=1&xmem=1&xloc=1&binarytrees=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=1&nbody=1&nsieve=1&nsievebits=1&partialsums=1&pidigits=1&recursive=1®exdna=1&revcomp=1&spectralnorm=1&hello=1&sumcol=1&threadring=1Comment by Anonymous [] on November 6, 10:38
Delphi Native Code Fast or Reliable?
There are several things that can make programmers use a certain language. Hype/New features/Going with the flow is the most well known. Sticking with what works is another one. Microsoft is about the first, CodeGear is about the last, and that's why CodeGear's customers are so loyal. Many of us know several tools and languages, but when we need to get something done, we can do it with Delphi/Win32. It's the small things that make Delphi cool. AnsiString was faster than the Microsoft compatible WideString. The support of Variant in a compiled language was extremely cool - a real feature enabler. What Delphi needs, is to make things possible, without getting bloated, and without blocking the future. Many Microsoft libraries make things bloated or complicated. Whenever CodeGear can make Delphi do one of these simpler, Delphi gets an advantage. For instance, VCL instead of MFC, Firebird instead of MSSQL, MIDAS/XML instead of DCOM, Indy instead of Win32 API, IBX instead of ODBC/ADO etc.Comment by Lars D [http://compaspascal.blogspot.com] on November 6, 10:59
Delphi Native Code Fast or Reliable?
Does speed matter? Sometimes, yes. Does scalability matter? Sometimes yes. It depends on what kind of application one is developing. Unluckily the Delphi compiler didn't keep pace with new CPU features - hope the next 64 bit compiler will fill the gap - and will improve somewhat the 32 bit compiler too (although sometimes I am afraid we will have the only 80386-64 compiler on the market <g>). A better memory manager had to be borrowed from a contest set up by users - the same happened for many RTL functions. Does using a native compiler make sense when it outputs old 386 code, its memory manager was designed in times of old, and its RTL is not performant and relatively poor, when p-code can be precompiled or jitted to take advantage of latest CPUs, garbage collectors improve, and good frameworks are developed? Native code makes really sense when working on application with special needs - speed, memory, footprint, low level data access and system integration. But it has to fully take advantage of them. I am happy if I can compile ten years old source code, less happy if I get ten years old compiled code.Comment by Luigi D. Sandon on November 6, 12:18
Delphi Native Code Fast or Reliable?
With the support of oxigene the .net dream from codegear is closed. We have now a real alternative for .net programming a la microsoft manner. Linux servers are knocking the door of enterprises now, and we can be there without a big economic effort. The linux desktop part can wait for future versions. Now we need to really slowly rethink the "real" delphi roadmap to make it a "fashionless" native multiplatform environment.Comment by Francisco Ruiz on November 6, 12:22
Delphi Native Code Fast or Reliable?
I totally disagree. Even though I'm an avid win32 Delphi programmer, the future in all topics is virtualization - regardless whether it is OS, Applications or programming code. Why? Well, abstractive layers (yes, I disagree with the onion thing) is something you use in Programming too, why not in the resulting Programming Code as well? Advantages: Portability. Will my app run on Windows 7 (or how about MacOs or something like Android)? On a virtual code base: yes. Native code? Maybe - what happens if my OS turns into a 64 Bit System only without 32 Bit support (which my "old" app is in)? With "virtual Code" this is no problem. of course there are things to consider like visualization problems (WPF Problems, etc, take a look at how Java solved this). Native code is needed for slow and old devices, sure. but for example take a look a the mobile phone cpu's, how the increased processor speed in the last years. ok battery life had to be optimized as well as a sidedraw, but this is a general problem. Virtual Code has one more big advantage: No one is caring about the Language which created the code. Is a Delphi programmer compared to a C++ only a second class programmer? With virtual code: No. Wouldn't it be nice to use Delphi for all OS and devices (like iPhone)? If virtualized code overrides the generic aspect, this is possible. I love the future. Generally spoken, my opinion is: The future (not today) is virtualization in every aspect. Including program code.Comment by Dennis S on November 6, 12:49
Delphi Native Code Fast or Reliable?
@Dennis S - I don't know if you remember the hoopla surrounding 4GLs, Prolog, etc. This topic comes up at least once per programmer generation. And it doesn't work, not because of speed, but because in the end, when the customer says he wants his logo three pixels further in, you gotta have a way to do that. Virtualisation creates layers of abstraction that you have to fully understand before you can do anything non-trivial. After 5 years of C# programming, I still find I have better control of the end result using VCL forms than using .NET, also better control over memory allocation and release, graphics, etc. .NET is fine for database front ends (yet even then, in my experience, not always...), but for an industrial grade application, you need the granularity native code gives you. Speed? Startup speed is what makes the first impression. I hate how .NET apps wobble into life. We had to break out some graphic stuff to C++ code for speed and ran into distribution difficulties. Delphi would have done it in the same exe. Indeed, one form that selects a directory is now a Delphi .dll which I quickly knocked up after none of the experts could do what the customer needed using .NET. Support for newer processors? What for? (see above) Doing so merely limits the supported hardware base, which may be uncool, but I need to pay the bills. I even ran into the trap years ago of using supplied features like Actions, and various 3rd party tools that shipped with Delphi back then. Bad mistake. Never again. In the long term, for serious, long-life applications, building your own is the best solution. It does exactly what you need, only what you need, and you know how it works. The only thing I wish for is some way to reduce exe size in Delphi. The identical app just gets bigger with each Delphi version.Comment by Ken Knopfli on November 6, 16:31
Delphi Native Code Fast or Reliable?
Yes, you're old! :-) But so am I and quite a few other Delphi programmers. It just seems as if every new programmer just skips Pascal as an alternative language. C# tends to become what Pascal used to be about 20 years ago. I still remember building applications in Turbo Pascal 3.0 om my 8086 XT computer with 640 KB ram and a hard disk of 20 megabytes. Yes, back then native code was really important. System resources were low and slow so as a programmer you had to do anything you could to gain some performance. Nowadays, we have plenty of resources. Memory gets measures in gigabytes and terabytes nowadays. I sometimes wonder if anyone can still remember the kilobyte and I feel old because I can. When you have lots of resources then you can waste some to make development easier. No longer do you need the fastest algorithm. Nowadays you need those that are easier to understand and implement. A simple thing like a hash table is just a standard part of many development systems but there was a time when I had to write my own. And while my own implementation would be much faster than those current implementations, I still can't fight at the ease of those modern ones. I feel as if I've build some fast boats that can travel around the world in a few days, yet now we have these huge cruise ships that are bulky and slow but everyone prefers them because they're way more comfortable...Comment by Workshop Alex on November 6, 16:33
Virtualization
Virtualization and sandboxing also means that it doesn't matter, whether your app is .net, java or win32/win64 based.Comment by Lars D [http://compaspascal.blogspot.com/] on November 6, 16:36
Delphi Native Code Fast or Reliable?
Oracle's Larry Ellison already said (talking about cloud computing but can be applied in general) "... The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?" And I'm sure he must know ... DanielComment by Daniel Luyo on November 6, 16:46
Delphi Native Code Fast or Reliable?
I surely do not think that .net usage is for db front ends only, for god shake! We build any kind of app here (and millions other are doing this) without problems and with very good results. Also, M$ has done a quite nice work in 3.5 SP1 regarding app startup speed. It really makes a difference now. As for Delphi, i think that "Reliable" is it's best bet. And this because with these processors nowadays and with .net speed at a very good level, it's (Delphi's) always admirable speed, is now not relevant any more.Comment by king kikapu on November 6, 18:21
Delphi Native Code Fast or Reliable?
"Virtualization" is another buzzword of today - I see lots of people wasting resources setting up VMs for everything while they often could do without - just setting things up as they should have been in the first place. And don't forget the Law of Software Inflation: software expands to fill the available hardware. No matter how processor speed and memory increases, software needs will increase more. "Virtual Code has one more big advantage: No one is caring about the Language which created the code." Well, that's true for compiled code too. Who cares about what language your .exe was created with??? At least you don't see everytime you get a new application "sorry, this application requires JRE/.NET framework x.y.z, install it to run this application". Or do you believe that each language compiler would produce the same "virtual code"? And do you believe all WMs will be "created equal"? Is a Mono VM on par with a MS Windows VM? Again, the problem just shifts... "Wouldn't it be nice to use Delphi for all OS and devices (like iPhone)?" Yes, but each OS and device has its own GUI, rules, design guidelines and platform specific features - does one really believe he can use the same code for a Windows and iPhone application? And if he could the problem is not how instruction are translated into machine executable code, be it a compiler before or a VM/jit later, the problem is how to develop a *real* cross-platformm framework - those existing now or makes your application look alien on each platform, or make your application ugly on each platform. "Will my app run on Windows 7 (or how about MacOs or something like Android)? On a virtual code base: yes. Native code? Maybe" Are you sure? What if you have an application requiring an old WM like JRE 1.3 or .NET 1.0 and your brand new OS no longer supports them? "but for example take a look a the mobile phone cpu's" Take a look at mobile phone OSes: Windows Mobile 6.1 is slow even on latest CPUs, especially on devices with high resolution screens, "software expands...."Comment by Luigi D. Sandon on November 6, 19:50
Delphi Native Code Fast or Reliable?
Hi Marco, I was going to follow-up here but it turned out quite long. So I've followed up on my blog.Comment by Hadi Hariri [http://www.hadihariri.com/blogengine/post/2008/11/06/Delphi-Native-Reliable-all-combined-into-one.aspx] on November 6, 20:32
Delphi Native Code Fast or Reliable?
1. Microsoft will never port it's Office suite to .NET 2. Microsoft will never release a Windows version on which it's Office suite will not run.Comment by Ken Knopfli on November 7, 12:12
Delphi Native Code Fast or Reliable?
Any sample of relevant applications made with .net? In the native world I can count most everything you are using including the visual studio and the java virtual machine.Comment by Francis on November 7, 13:41
Delphi Native Code Fast or Reliable?
@Francis Not entirely true: Visual Studio 2005 had 7.5 million lines of C# code... http://blogs.msdn.com/danielfe/archive/2005/12/16/504847.aspxComment by king kikapu on November 7, 17:02
Delphi Native Code Fast or Reliable?
@King Kikapu It's true, but which support the entire house isn't c#. in words of Michael Swindell: 'Despite reports to the contrary, native code remains the core foundation of application development'Comment by Francis on November 7, 18:43
Delphi Native Code Fast or Reliable?
@Ken "Microsoft will never port it's Office suite to .NET" Why not? It may not happen today or tomorrow, but I think this will be done some day. @Luigi "Who cares about what language your .exe was created with???" The ones who asks me on porting it to a unix system (not running wine). With native code the compiler has to be unix aware (hooray dead kylix) or there has just to be a compatible environment (hooray mono) and my delphi app will run on linux and macOs. Currently I'm still using native Win32-Code (hello 64Bit-Delphi?) but thinking about moving to the future some day (.netish), when "fast" and "reliable" applies to those code outputs as well.Comment by Dennis S on November 7, 19:21
Delphi Native Code Fast or Reliable?
Native or managed? Here is my answer: Microsoft Singularity (the first managed OS "core") http://channel9.msdn.com/shows/Going+Deep/Singularity- A-research-OS-written-in-C/ http://en.wikipedia.org/wiki/Singularity_ (operating_system) The future is beautiful.Comment by daywalker [http://devportal.hu] on November 7, 22:28
Delphi Native Code Fast or Reliable?
@Francis, This might come as a shock, but below .NET, Java and even Delphi is ASM. Should we all just use ASM?Comment by Hadi Hariri [http://hadihariri.com] on November 7, 22:53
Delphi Native Code Fast or Reliable?
@Francis: Do you see that Swindell's opinion is fulfilled in reality ?? Because the only thing i see, is that M$ is investing on .net more and more.Comment by king kikapu on November 7, 23:42
Delphi Native Code Fast or Reliable?
@daywalker Here you have an alternative to microsoft singularity. http://gocosmos.org/index.es.aspx, it's cosmos a really open source c# from Kudzu (father of indy and winshoes), in an interview to zdnet you can read : Kudzu: Singularity actually has a fair bit of C or C++ down in the core. Cosmos is 100% C#. The only assembly is emitted by our compiler. @Hadi (about asm) Of course not Hadi. What's a nightmare. OK c#.net is a really fantastic work plenty of functionality. But if you want to use it, here is prism. (I also will use it for some works). But delphi for win32 need to go in his own way and don't play in java and .net arena.Comment by Francis on November 8, 23:44
I need all
I need Fast, Reliable, Maintainable and Portable apps.
The problems i have seen with .Net as compared to
delphi are.
1. Slow load times.
2. Deployment Headaches like
a. not a single exe any more.
b. Suddenly your app stops working. Solution:
Just reinstall .Net framework and its
gone. simple.
3. Slow UI.
4. More memory usage.
on the contrary i like
1. asp.net
2. I can program devices. (Although when i tried 5
years back the resulting app was too slow to be useful
for my clients.)
Om sure there must be more to add here.
Regards
Comment by bravo on November 9, 17:05
Delphi Native Code Fast or Reliable?
@Dennis: "With native code the compiler has to be unix aware (hooray dead kylix) or there has just to be a compatible environment (hooray mono) and my delphi app will run on linux and macOs." Again, it's just a matter where your code gets transformed into machine code. It's not a matter if executable is a native code image or a p-code image. There's plenty of C/C++ compiled code that run on Unix, Mac and Windows machines. The problem is the lack of a Delphi compiler/framework for non-windows platforms, not a issue of native code itself. As much as Mono framework lacks several .NET features available on Windows - there's not assurance your application will run on Mono unless limit yourself to Mono on both platforms. The very fact that Kylix went nowhere means that many Delphi developers dream a multiplatform tool but very few actually tried. I guess many now talks about going everywhere with Mono just to stick to Windows.NET - it's just the "feel good factor".Comment by Luig D. Sandon on November 9, 20:38
Delphi Native Code Fast or Reliable?
Did you see trolltech QT? one framework can create applications for windows, mac os, linux, wince, embedded linux and s60(beta). It's for c++ and java (that's not for me) also it can make entire devices. I think this is the way delphi need to go. You can see the section of 'applications and devices using QT' and the list is incredible. Simply compare to others. In my opinion, and with the proper resources ($) native code always will be more fast and more reliable.Comment by Francis on November 10, 12:29
Delphi Native Code Fast or Reliable?
QT is a good example of "looks alien or looks ugly" way of developing multiplatform GUIs. There are still too many differences in widget sets and interaction rules to develop a good user interface using the same framework on different platform. Look at Skype: it uses Qt on Linux, but it uses native Delphi controls on Windows. Which interface is better? Delphi already attempted a Qt library (CLX used Qt, AFAIK), and it didn't succeeded.Comment by Luigi D. Sandon on November 10, 14:04
Delphi Native Code Fast or Reliable?
@Hadi: "Should we all just use ASM?" Don't knock it. I spent my formative years programming in ASM. When I disassembled my first Turbo Pascal program down to ASM, I was surprised how recognizable it still was, without being verbose. In the same way that Basic has morphed from line number based, to procedural, to pseudo-object, and now to fully object-oriented, there is no technical reason why ASM couldn't be changed in the same way. The first C was originally just ASM macros, and the first C++ was just C macros. Of course there's no market so it will never happen. But ASM is not as scary as some people think. Try disassembling some .NET code (Microsoft provides the tools). You will still recognize the source and after a bit may even try modifying the CIL P-code manually!Comment by Ken Knopfli on November 12, 13:33
Delphi Native Code Fast or Reliable?
Incidentally, below .NET, Java and (I think) Delphi is machine code. .NET CIL and Java definitely don't go through an assembler stage, and IIRC, TurboPascal was the first compiler to forego the assembler and link directly to machine code.Comment by Ken Knopfli on November 12, 15:36
Delphi Native Code Fast or Reliable?
@Knopfli: assembly is just a human readable form of machine code. An assembler just turns the mnemonics into their equivalent numeric codes, and resolve the addresses. Most native compiler just outputs machine code directly - only a few produce an intermediate output that needs another compiler/assembler to produce the final executable. Linking is a different task - it means combining object files (already in machine code...) into an executable and relocating addresses. Until TurboPascal 4.0, TP didn't link at all - it just produced simple .com executables, while assemblers may need a linker too to produce more complex executables. Below .NET and Java there is a machine independent code (bytecode) - which needs to be interpreted or compiled into final machine code to be executed - usually by the VM.Comment by Luigi D. Sandon on November 13, 10:55
Post Your Comment
Click here for posting your feedback to this blog.
There are currently 0 pending (unapproved) messages.
Delphi Native Code Fast or Reliable?
Comment by Nick Bradbury [http://nick.typepad.com/] on November 5, 20:40