Sunday, March 27, 2011

SciMark2 and Delphi

Your reviewer was surprised with SciMark test ported to Delphi that Mr. Phillip Goh posted.

On a Core i7-2600K it achieved:

**                                                              **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov)     **
**                                                              **
Using       2.00 seconds min time per kenel.
Composite Score:         1885.62
FFT             Mflops:  1426.20    (N=1024)
SOR             Mflops:  1146.66    (100 x 100)
MonteCarlo:     Mflops:   515.48
Sparse matmult  Mflops:  2096.31    (N=1000, nz=5000)
LU              Mflops:  4243.46    (M=100, N=100)

With same Delphi version:

**                                                               **
** SciMark2a Numeric Benchmark, see http://math.nist.gov/scimark **
**                                                               **
** Delphi Port, see http://code.google.com/p/scimark-delphi/     **
**                                                               **
Mininum running time = 2.00 seconds
Composite Score MFlops:   576.03
FFT             Mflops:   363.08    (N=1024)
SOR             Mflops:   935.87    (100 x 100)
MonteCarlo:     Mflops:   181.13
Sparse matmult  Mflops:   488.35    (N=1000, nz=5000)
LU              Mflops:   911.74    (M=100, N=100)

Readers are welcome to submit their own tests and find their own conclusions.
The C++ version is 3.2 times faster than Delphi version.

Readers can download the test at http://code.google.com/p/scimark-delphi and run it on their own computers.


There are deep implications beyond MFlops, FFT, LU and other metric tests.

Suppose you tell an organization to "get the latest hardware" to run your Delphi apps faster.

This benchmark was run on an Intel Core i7-2600K, 3.4GHZ (TurboBoost to 3.7GHZ). This is quite expensive for consumers. Most corporations would probably buy a Core i3 or Core i5 to give to their staff to use. If the program is not optimized to take advantage of latest hardware, it's like telling whatever expensive hardware you give it, it gives very little performance gains.

Suppose you're the developer creating these wonderful apps that sell for money but for some reason, there's this part which takes incredibly long, like generating reports, crunching numbers for sales report, making that graph (licensed from TeeChart) or computational intensive operation (like posting to proprietary Delphi Database). It takes hours or maybe a whole day to generate report.

Your competitor uses C# (or JavaScript or C++) and then makes a competing app, which seems to be 30 or maybe 50 times quicker than your app. What happens next?

You can foresee trouble that starts to brew.

Update 1:
The benchmark for Delphi is from Mr. Phillip Goh's Google Code site. Download the link from that GoogleCode website, it comes with 3 EXE files. From looking at the binary, it is GCC.

Friday, March 25, 2011

How not to File Share Delphi in Eastern Europe

In certain forums, there's always this person who have a need to share "Delphi 6, 7, 2005, 2006, C++ Builder" and unfortunately, many of them live in Romania and... Czech Republic.

Unknown to them, since Borland sold off their Delphi assets to Embarcadero, it was later found that Embarcadero has presence in Romania and Czech Republic.

For instance, the head regional manager of Embarcadero Romania and the sales manager at Embarcadero Czech can easily go and get a court order to Deutsche Telekom (and other ISPs) to disclose the IP addresses for those illegal forums and FTP sites.

Here are some suggestions to fight against piracy in their own countries:

a) The registrar for the .EU and .CZ domains keeps records who pays for what and who the owners are. They can strike off a domain based on fraud registration. (i.e., person gave fake credentials to register domain for software piracy).

b) They can bring the ISP to court to lookup the IP address of the idiots who opens FTP sites to share Embarcadero Delphi and C++ Builder...

Hint: the physical IP address of them are in Sofia, a few miles from Embaradero's head office :).

c) They can then advertise the person's name publicly after going to court. That way, everyone will never employ these persons ever again.

d) Bring RapidShare to court to find the actual IP address of that person. One company solved this by setup a fake file-sharing website to nab the actual IP address of the file-sharing person.

The funny thing about is, Delphi developers complain there are no jobs, maybe reason is stinkers sharing Embarcadero Delphi are doing this to their own people in their own countries.


Article Update: Czechoslovakia changed to Czech.

Thursday, March 24, 2011

JavaScript Performance vs. Delphi

Native compiled code should be faster than JavaScript interpreted code, the usual saying goes.

New Kids on the Block?
There are many reasons why Delphi developers claim Native development is better: It creates smaller EXEs (if you consider that 20megs setup packages to be pushed every month is fun for customers), it is faster (with certain exceptions) and better overall experience (like no garbage collection, so Delphi apps usually crash Windows 7, with Delphi Server Apps crashing Windows 2008 server with unstable TCP/IP and consuming 2 Gigs before dying).

JavaScript is considered the worst language (by Delphi developers' point of view) for coding:
  • It is not strictly type-cast, 
  • Has overall very poor performance and very, very poor floating point performance
  • Consumes lot of memory 
  • Waste of development time (i.e., the answer is IntraWeb instead)
  • Is interpreted and therefore, easy to make mistakes.
Yet, since Delphi developers eyes are closed to the world (i.e., the world revolves around Delphi and nothing else. A Delphi developer is a Delphi developer for life, they cannot open their eyes to learn other things).

The world passes by Delphi, both in price, feature and performance.

With JavaScript, there is:
  • Server Side Java Script (SSJS)- use JavaScript on server to stream web-pages,
  • Desktop JavaScript - why use Delphi for, when you can use JavaScript for "native" development
  • JavaScript.NET - the "unpopular" version of JavaScript
  • Javascript Java - see Rhino.
  • SQL with SQL - Using JavaScript to query Oracle, MSSQL and MySQL (except Delphi proprietary databases)

Costs for learning JavaScript is free with many IDEs available (see: Eclipse). There is working Intellisense (This is broken in many versions of Delphi), many free scripts available (example: HotScripts.com), many Ajax frameworks available (see: Moo Library, Node.JS, JQuery and so on).


Project Disclosure?
Your reviewer was looking at a post by Eric Grange how "another language" beat Delphi.

The problem with this lies in the way how formerly Borland handled disclosure of "floating point  benchmarks", performance benchmarks. Many (former) professors (i.e., the gray-hair one who teaches you computer science) were silenced by Delphi's license agreement preventing them to speak up against Delphi.

While other compiler vendors (D++, C++, PHP) started to optimize their floating point with lesser languages (FreePascal, GCC, RealBasic) starting to compile with SSE2 (and even SSE3, SSE4) optimizations and giving developers good floating point performance, C++ Builder & Delphi languished with i386, i486, MMX (Pentium) performance.

It was like saying, since the day Anders Hejlsbery left, Borland could find nobody to fix floating performance since Delphi 2.

It could be considered a classic conspiracy theory - Floating Point are like UFOs and floats around in the sky and the official policy is that floating points that fly faster than the average thing in the sky does not officially exist.

If the next version of Delphi still have same floating point performance, same problems and just bug-fixes (i.e., it should be called Delphi 2009 update '11)... it would be really, really tough sell...

Saturday, March 19, 2011

How not to appraise your competitors

How not to appraise your competitors
Your reviewer was looking at the Delphi Product Manager's blog, Mr. Michael Rozlog(1) and wondered if he was preaching to the choir(2). Mr. Michael Rozolog's blog goes two ways - writing opinions "Mobile will be a possible future" (which may be true) but the second one your reviewer do have opinion against: bashing competition. Posts like "Top 10 technology predictions" in the guise of promoting future, "Java is the cobol of the 90's" which bash Java.

Does the Emperor have no clothes in the future?
When you preach to the choir - you can make all sorts of insults towards other competitors, that they are no good, that their products are useless and will not help you. You can make assertions that your product is the finest development tool in the whole world and buying this product will make you hundreds of thousands (of dollars), if not millions (of dollars). You can make all sorts of claims, misrepresentations and allegations. But this is the real world, the world does not revolve around Delphi, it does not revolve around Embarcadero and if you cannot provide a working and affordable solution, there are other vendors hard at work to provide working and affordable solutions.

Your reviewer sees the usual pulpit preaching that other solutions are bad and Embarcadero's solutions are superior. Posts like "Java continues to be the Cobol of the 90's", "3D gaming technology is not the next big thing yet", "Top 10 technology predictions of the future" sounds like advising on all things you should not do with Delphi.

Sounds more like:
- Avoid 3D because Delphi's floating point and 3D libraries are not up-to par. Even Chris Benson wonders why the same EXE built with a physics engine ported to Delphi is much slower in Delphi.(3)

- Avoid TCP/IP SOAP stacks because RemObjects SOAP interop requires you to buy RO SOAP for NET or Java because the RO SOAP client/server serves up non-compliant SOAP packets whereas JavaSoap and NET SOAP interop with each other.

Corrections Requested
Your reviewer corrects some of Mr. Michael Rozlog's predictions with realistic assumptions:

- Native Development will be "in the game" again. He argues because of the smartphone booming. The hard issue is that he wants to make a logical fallacies framework: if you will take that Native Development will be the future, you will think in general that Delphi will be great. Also he states things that are true for VM in particular too: the idea that you can use whatever your OS can bring.
To be fair, there are places where native development do matter: performance critical parts of code. Games are the best frame to say so, bot to say in perspective, here is where Delphi as performance do not shine. Anyway, Mike was kind enough to estimate that games are not what it will happen. Many things changing native development (as of Win32/VCL)  are dead for some years. Your reviewer not here to say that it will disappear, but as of today reality are not that relevant. Is like if you write compilers you should know most likely assembly language, but never use it, excluding for that 10% that you have no other option (even in this case, you can write to LLVM or to VM's bytecodes, so rules are a bit different today).

Another area where "native development" matter is to achieve responsive guarantees that the a VM (mostly on underpowered device) is not always capable of. Anyway, this is different in many ways today, like Android uses a fairly decent VM (that have a JIT for some time), Windows Phone too, and in supported languages Delphi (or Delphi support) is not included.

Is Java really the next Cobol?
- Is it really Java a Cobol "replacement"? Why does Mike said things that he knows already, since he worked as the JBuilder Product Manager and he understands how Java works? He wants to promote his software that he's selling. At the end, he bashes the two platforms are competing Delphi at its heart: Java and .NET. Both are not as much as phone toys software, but are platforms that work on enterprise. Don't worry, he bashes one year before RIA (and he apologizes next year). that was another competition of Delphi: if you can distribute your application in browser, using either Flash, Silverlight or JavaFx, so you will not need Delphi anymore. Even you will use an HTML5 application, can become rich enough to not become RIA, browsers support that. Look to Facebook that you don't believe me or GApps (GMail, Google Docs, Google Calendar). Did you heard a Delphi's server side site that is widely used? Does anyone use JBuilder anymore?(3)

(Did anyone find a working, affordable and usable equivalent TCP/IP, HTTP, SOAP and RIA stack in Delphi?)

 Even Java did not released a big overhaul for some reasons as internal hardships (Your reviewer can argue that Delphi did the same from 2002 till Delphi 2006 making to stagnate as platform). Java is a platform that evolves and innovate. Is also much faster than .Net have to offer in raw performance and how applications scale. Delphi does not scale well server side as does not have support for 64 bits and huge heaps. Java and .Net offer mature support for 64 bits at least for 5 years to date. Java bring stable betas for at least 1 year as time. Some things may not be there for deployment, but everyone seems to love the message boxes that sometimes appear to Delphi application, and many complained on Delphi applications and libraries stability. JRuby is a very active project. Also GWT or Android could not exist without Java heritage, and they build and run and move as we speak.

At the end the problem is not about which platform is the best, your reviewer does believe that .NET is not a silver bullet, but on the other hand, Delphi as is today is not a better replacement for .NET.

Some things are missing in Delphi and as far as it seem for me, Delphi will lag behind more and more to "impress" people that will be long gone to .Net like platforms. AIR runtime for me at least appear a more mature distribution platform: a very small runtime to run, a fairly fast JIT that will generate for any web application an instant response, accelerated controls to: see movies, to make controls with easy workflows from Photoshop. Do you need speed for your HPC code and you cannot use Java as backend? You can call it from AIR by handling data via TCP. Theoretically Silverlight 4 let you call native code directly, if you allow it.

At the end, will Mike promote open ideas? Maybe never. As far as I'm concerned, probably your reviewer should not write this post, on the other hand, just thinking that making blunt statements at the end will hurt his blogging authority. Wanna see a more interesting and less biased posts? Look on Cliff Click(6) and Java in general, or Miguel de Icaza(7), or Linus Torvalds.

Your reviewer wonders why Mr. Michael Rozlog not praise his competitors? The Mozilla Team praises Chrome's JavaScript implementation(8)



Wanna biased talking persons, look also on Steve Balmer's quote: "someone will pay that much on an iPhone" he said... and people did.

Some of your reviewer's more accurate predictions vs. Mr. Michael Rozlog's predictions are:

1. It will be less usage of "native code" in enterprise word. People need to scale, a garbage collector give predictable throughput, a memory leak more  unlikely. Second problem is the software stack: vertical stacks are mostly in JEE or high level frameworks. And as C++ is hard, you will likely invest on a Ruby on Rails implementation or PHP implementation.
Talking about Garbage collection to Delphi developers is like talking to a lazy person who cannot check their own work because AQTime (standard) is massively crippled and requires US$599 for accurate profiling.

Did anyone hear about the Delphi developers who had a memory leak in the server application and the server applicate ate up 2 Gigs of memory before failing? Maybe nobody did because there are no Delphi embedded servers or lack of sales due to customers complaining about a big server app that eats-up 2GB of memory...

2. More applications will go towards browser-only, maybe HTML5: FF4, IE9, Chrome, Safari and Opera will have guaranteed JIT for all instances running your code. This will make clear that users will get a bit richer experience, maybe flash like from browsers.

3, "Going native" will happen probably on PHP server side, as Facebook's HipHop will get more traction and most of it's bugs will be fixed. No other platforms will likely get this path. Node.JS a Google JavaScript server side projects will get more traction for somewhat more complex server side part.

4. Google Go will be hit and still miss. Language sugar is not enough to change the world, just making interfaces minimalist will mean that some people may use it, still will not give to it momentum. As it have just C like integration, have no advantage to Java, C#, or Delphi on that matter.

5. A lot of Free to play game will appear. Browser based may use flash and integrated socially. Native ones will be free to play like MMORPG or so. The baseline will be connected and to one level social. The business model will change for a lot of games

6. (Your reviewer have just one biased prediction and is somewhat related with my project, but will happen your reviewer think for a lot of projects:) The tendency will be for people to integrate higher level platforms on top of old codebases. GCC is necessary for most people, sometimes reflection, a good code completion also helps. What your reviewer mean with this is that many giant applications will offer higher level platform interoperation: OpenOffice may rewrite some of the dialogs using  Java or Qt (this will be a 2012 prediction) to make the messy code to go away. Your reviewer predict this because your reviewer work on a fairly complex logic app. This application if was written in C++ was much less advanced than the C# today codebase. Your reviewer really think that similar codebase would require much bigger team and much more extensive tooling but with a lower market price.


(1) Michael Rozlog Blog. http://blogs.embarcadero.com/michaelrozlog/
(2) Idioms. http://www.phrases.org.uk/meanings/preaching-to-the-choir.html
(3) Box2D. Chris Benson's blog. http://chrisbensen.blogspot.com/2011/01/delphi-box2d.html
(4) JBuilder 2008 review. TheRegister. http://www.theregister.co.uk/2008/04/28/jbuilder_2008_review_rough_edges/
(5) HipHop. FaceBook. https://github.com/facebook/hiphop-php/wiki/
(6) Cliff Click's Blog. http://www.azulsystems.com/blog/
(7) Miguel de Icaza Blog. http://tirania.org/blog/
(8) David Mandelin's blog. CranShaft. http://blog.mozilla.com/dmandelin/2010/12/08/crankshaft/

Sunday, March 13, 2011

Beam me up Scotty, part II

Hi Scott,

Can you please check your mailbox and contact me...

First issue: The (other) forums are rigged. If you used the same password (as is for your Gmail or Yahoo account) for that forum, the mods and admins can find out your password by looking in the forum-database and steal your GMail or (Yahoo) account. If you are using same passwords as your Gmail or Yahoo account or any other account, please change it.

Second issue: I'd best advise that you stay away from those forums as those forums record down your City, Location, State as you go browsing along. If your ISP has enabled look-up or "IP triangulation", they can trace you down to the nearest 100m where you live.

I'm sure the forum admins will flatly deny these statements but think about it when you got hacked and got some other mysterious things happened to you...

Wednesday, March 9, 2011

May the Schwartz be with you

Mr. David Schwartz let out a nice rant on the Embarcadero newsgroups:

Mr. David Schwartz writes:They've been running promotions regularly since before XE was launched.

Subscribe to the Programmer's Paradise list and you'll hear about their promotions directly.

I don't recall getting anything directly from Embarcadero either, although I have gotten a few phone calls from someone in their sales Dept.



Their pricing and marketing strategy still baffles me, even with the "Starter Edition".

Microsoft has a licensing policy whereby if you're working for someone, you can run a copy on your own computer at home and/or laptop.

The cost of MSDN, which gets you almost everything MS produces, is also less than the cost of any "professional" versions of Delphi, C++, Prism, etc.

I haven't found any "real work" for 16 months. I'm not homeless only because of the kindness of my landlord. The only Delphi jobs I've seen are to maintain D5/D6/D7 code while they port it over to .NET or Java. And I seem to be competing with people here on H-1B visas who are willing to accept $20/hr through job shops who say their clients won't pay more than $25/hr.

It's a horrible job market, and Embarcadero wants me to spend my own money -- money I don't have to spend -- to learn a product that nobody who'd hire me even cares that I know.

I have an interview set up with a company next week that has software in thousands of sites around the country, and it's all running D6. My contact told me that it's cost-prohibitive for them to upgrade to a newer version of Delphi for some reason. In fact, their clients are all still running Windows XP.

This is the same story as the past five contracts I've had since 2005.

There's zero ROI there for me to keep current. Actually, it's negative.

When I talk about the newest versions of Delphi with people at these companies, they want to know how much experience I've got with it. Well, uhhh.... I don't have the funds to buy it just so I can learn it and ultimately help Embarcadero sell it into Corporate accounts that they already can't convince to upgrade.

I print out and show them the product feature matrix PDFs, but ... so what? They can pick up the phone and have a handful of resumes within a week of people who've got plenty of experience with the latest .NET/C# stuff. But they can't find decent Delphi developers at all.

Ironically, if I wanted, I could probably get a legitimate copy of MSDN for free somewhere, including directly from Microsoft.

Borland/CodeGear/Embarcadero has never made much of an effort to get their products into the hands of the people who have the greatest influence in making sales, namely independent consultants, contractors, and people who just want to stay current with things. The "Starter Edition" is an interesting attempt, but ... the net effect is it simply allows me to speak authoritatively to clients in order to get them to buy a bigger package with more bells and whistles in it. And my experience is that when they compare the price vs. MSDN or just Visual Studio, they politely thank me and that's the end of the discussion.

There's no line-item in a budget for "savings due to productivity". They only believe the productivity claims AFTER they've seen them with their own eyes. Other than that, it's just a "big risk" -- a more expensive package from a company that's got a reputation of being 2 years behind the technology curve with buggy software.

Embarcadero says they're changing that. But what they're NOT changing is ensuring that the troops on the ground who walk into companies using old versions of Delphi can say, "I've been working with the latest versions since they were in Beta and I know all of their kinks". Most of the consultants I've run into say that about .NET and C#, but not a single one says that about Delphi. Why? "I'm not spending MY OWN MONEY to help CodeGear sell their products. If a client wants me to use the latest version, they can pay for it."

That's never an issue with Microsoft's tools. Or Apple's tools.

The new "Starter Edition" is supposed to give you a way to afford the product when you're "getting started". It requires you to buy an upgrade after you've hit $1000 in "gross revenues", which if your business is not built around software development, is a silly meaningless number. Anyway, every penny of that $1000 will have to be saved up to pay for the upgrade rather than your rent and marketing.

It would be great to know who's using Delphi XE so I can talk to them about some work. But the latest version I've seen discussed in job ads over the past year is D2006, and that's been very rare.

I'd love to be working with the newest version of Delphi. But it's a chicken-and-egg problem: I need to find a company who'll foot the bill FIRST, which isn't likely to happen because nobody I talk to is using it. And without it, I can't convince them it's a smart buying decision.

BTW, Apple's entire development platform was FREE, until they started charging ... OMG ... $99!

And THAT is to get registered in their Developer's program that lets you get keys to submit apps to their App Store.

Since they instituted their $99 fee, Apple has sold over a BILLION DOLLARS worth of apps through their App Store, the vast majority of which sell for under $5 a pop.

Is it just me, or is there a very suspicious inverse correlation between the price of these development platforms and the size of their developer base?

Embarcadero should figure out a way to get a copy of RAD Studio XE into the hands of every single software contractor and developer they can find, with the proviso that they ONLY USE IT FOR PERSONAL STUFF -- as a "learning tool" so to speak. These are the people in a position to motivate sales and use within these corporations who are still stuck in D6 land. The net cost to them is ... a download. These are not people who'd buy the product, but they CAN and DO influence sales. Maybe charge $99 for it. But don't expect these guys to upgrade after they get a job or get their employer to upgrade!

-David
[Source]

Tuesday, March 8, 2011

Article corrections.

Special thanks to Mr. Allen Baur for hints on his twitter feed. The article "Tea Leaves for 64-bit Delphi, part 2" is updated with several corrections.

Based on mathematical deductions, educated guessing your reviewer now has the most accurate portrayal of the situation for Delphi/64.

Misfortune telling?
The original roadmap had Delphi/64 on mid-2009, then end of 2010, then first quarter of 2011, now first half of 2011. Lot of people renewed their SA and updated their versions of Delphi (from 2009 to  2010) only to be disappointed when Embaracdero released Delphi XE with no trace of x64-bit compiler and with the need to later renew the SA soon since almost 250 days passed (or, by the time x64 is out, there will be need to renew SA).

Suppose you go to a fortune teller. The person says, I forsee a great turn of events, it will erase all the bad karma you had and make you better. You pay the fortune teller Euros 2500 the first time. The fortune teller tells that you will have a great future and demands another 800 Euros to clearly see your fortune. Then another 800 Euros to see the future again, then another 800 Euros. You find out that most of the things predicted turn to no effect or things gets worse and worse. How confident are you going to hand over another 1600 or maybe 2400 euros (800x3) to the fortune teller when almost all the predictions become false?

It only takes a few minutes to write an article that fairly and clearly depicts the state of Delphi/64 today. Since Embarcadero has not bothered to do so, your reviewer does it with plain simple language.

Monday, March 7, 2011

Saturday, March 5, 2011

Tea Leaves for 64-bit Delphi, Part 2

It appears your reviewer spoke about Delphi XE3 instead of Delphi XE2.


Your reviewer was gazing too much into the future and went 2 or 3 years ahead of time.

From educated guessing, Embarcadero will ship with 64-bit compiler preview in 30-60 days* (worse case: 80+ days) from now with time-frame to be around April/May 2011 time. This is evident with a big Embarcadero promotion (presumably to get rid of old stock) currently on right now.

How will the Delphi 64-bit preview fare? Your reviewer looks at all the VCL64 evidence and it looks grim. Unless they do good QA testing, it feels like similar experience to Delphi 2 (read: full of bugs) and took 2+ years to stabilize. (hint: Delphi 5/6/7-era)

They would probably change the Integer size:
Integer = +/- 2^63
LongInt = 2^64;
UInt64 = 2^63;

Correction:
There is no change in Integer size, just pointer size -->
64 bit compiling will not change for certain integer sizes, but only Win32 APIs that integer map pointers. Pointers will be 64 bit.

Correction #2:
There is no i386 FPU levels, masks, op-codes in 64-bit mode.

Piecing the 64-bit jigsaw
Dcc32.exe does a "one-pass compile". That means, many of the symbols are ready-made and resolve at link-time (see: rlink32.dll) immediately.

Dcc32 consists of two parts: dcc120.dll (called from the IDE) and dcc32.exe (called from command-line). The DCU files are intermediate machine language (usually i386 with few optimizations) with preamble (like basic checks, i.e., before a maths operation is called, it calls the overflow check, those that you find on the compiler tab) and restores the CS:EIP (Counter Stack, Instruction Pointer), Data Segment and Stack.

For dcc64, looking at the current integration (assuming they are going with a 32-bit IDE with 64-bit debugger bridge), then they would need to write a debugger bridge that translates __debugbreak() (previously known as Int3) into 32-bit equivalents with to and from 64-bits.

Assuming they did write a VCL/64, they (those at Embarcadero) writing the 64-bit VCL, they would need to roll-back to older versions of the same code (such as IntToStr before it became all-assembly) and translate that to 64-bit equivalents. They could do it both ways: For example, write to SSE2 registers or use NEON (Android/IPhone) registers.

How your reviewer would do 64-bits.If your reviewer was doing a compiler, your reviewer would use the Edison Design Group front-end compiler with back-end Dinkumware for the RTL x64, instead of hacking and slashing through MMX or older assembly optimizations.

Troublesome Console Application?Your reviewer looked at the tiny or very little information about VCL64, DCC64, RLINK64, DCC1xxx64.DLL and other files and wondered what's taking Embarcadero so long?

The trouble seems to be the bridge between 32-bits and 64-bits. In Visual Studio, they use a smaller version of the Visual Studio remote debugger to host the 64-bit EXE and Visual Studio "talks" to the remote debugger interface.

For Embarcadero, either they missed the boat or didn't bother to update TDEBUG32 to TDEBUG64 equivalent for very long time.

For example, if you write "array of [1..65536] of widestring" in your code in Delphi 2005, 2006, this would cause a DCC failure when "Include Remote Debugging Symbols" is turned on -- because array of widestring is not clearly defined in TDBUG32 information.

Who uses TDEBUG32 information? The former TurboPower SysTools, the former MemProof on Automated QA website before it was removed, AQTime, AQ(whatever) products.

Before you can write a debugger, you need to have properly working symbol generation working. Suppose you have to build a remote debugger bridge to bridge between 32/64-bit EXE debugging.

Hence, your reviewer guesses:

1) Delphi 64-bit compiler is missing the debugger when it comes out... or if Embarcadero releases it, it would be half baked or have so many bugs and issues, it becomes impossible to debug a large app.

2) Delphi XE was released on 30th August 2010. Assuming that Delphi XE2 would be released usually 365 + 30 days later (to annoy Delphi developers to update their SA subscription)

3) Delphi x64 compiler preview would disappoint many people. They think it's complete product ready to recompile their favorite app into x64 but it's not -- the next group of people who need to get rid of all the old 32-bit assembly and check their product to work with x64 are the component vendors. The larger vendors (DevExpress) do not even have any Delphi x64 news.

That means, give or take a year to make Delphi x64 stable, it could drag on to 2012 or 2013 more to get a stable compiler... by that time, most of the Delphi developers would have been out-foxed, beaten by their 64-bit competitors, without house, without any way to make more money... making 32-bit EXEs is no longer a marketable asset.

The people who still use Delphi will have to make hard choices when the 64-bit preview comes out...

The less information Embarcadero gives on the compiler development status (other than just being very silent) the more people will start to wonder WTF is happening?

:)

Article notes:
- For non-English speakers: "Tea Leaves" means predicting the future based on known available information.
- Spelling mistakes corrected.
- Pointer information corrected.

Friday, March 4, 2011

Around the web

Blog of the Week:  If you guys aren’t reading "The Delphi Hater’s Blog", then you are missing out.  This guy is a championship calibre ranter.  Great stuff. (From Nick Hodges' Blog).

Marco Cantu has a bad habit of deleting messages that are on his blog that are not favorable to Delphi but leaving all those other supportive messages.

- Wonder where was that comment regarding a person who had "reduced income" waiting for Delphi/64 to come out?

Unhappy with this blog? Debunk it instead...

Your reviewer was looking at nasty insults by stupid Delphi developers. They are the same kind who like to use all non-legal software, claim to be very honest but download DevExpress non-legal version, Dbisam non-legal version...

If you're not happy about this blog, go and debunk it instead....


- Your reviewer wrote Delphi In Russia, Rent a Coder - money back guarantee and many other postings which have no criticism on the content. I wonder why? Maybe because I write with brutal honesty and accuracy.

- Your reviewer challenges people to make a big extensive website with IntraWeb they can deploy. Yet, nobody have seem to taken that challenge seriously. Wonder why Jolyon Smith (Delphi in NZ) uses WordPress? Why can't he use IntraWeb to host his own blogging site?

- Why is there so many Visual Studio and C# articles on TeamB.com? Maybe because the whole TeamB uses Visual Studio or maybe it's time to ask Craig (TeamB) to start writing about Delphi articles?

- Saying the usual insults won't help. It only reinforce the message "Delphi is dead", the "newsgroup are full of trolls that defend Delphi", but if you look deep inside Delphi, may developers are tired of paying for this and that, more like borderline towards earning nothing or no money.

- The jury is out on the Tea Leaves - 64bit Delphi. This is all based on educated guessing. If there is anything to say, Embarcadero would have easily released the 64-bit product. Why bother wait until near the end of this year? (Maybe they want the current SA for Delphi-XE to expire so they can collect even more money)

- Wonder why nobody use WxWidget with C++ Builder? Or how about QT with C++ Builder? Surely, if Embarcardero C++ Builder is sooooo good, nobody would complain... except maybe nobody uses C++ Builder...

- Why not call up some of the people whose companies are featured on "Vendors who stopped supporting Delphi" blog posting and ask for their opinion about Delphi? They will tell you very honestly and very factually about what they think about it.