Pakistani Power Outages & Pakistani Delphi developers

Many Delphi software developers in Pakistan have suspended their software development activities while many others are on the verge of losing their livelihood due to gas and power loadshedding in Pakistan.

Pakistanis are currently having to endure without electricity for more than 8 to 10 hours a day. Your reviewer has Pakistani friends and asked them for some feedback about this issue.

Mohammad, a Pakistani Delphi Developer who spoke on condition of anonymity, feels the situation is getting worse and worse every day. Many Delphi Developers in Pakistan are doing outsourcing, with people working around-the-clock to satisfy American and European customers. "There would be one or two developers who work overnight and then and give instructions to the software development team who comes in the morning", says Mohammad. "With these power-cuts, we are unable to even contact our customers".

Software development using Delphi has been severely affected. The power suddenly is cut-off and computer reboots, many times a day. This causes lost works and sometimes, we have to repeat the works done again. With power-cuts from 8pm onwards and sometimes more than 10 hours a day, we are unable to contact our American customers who are waiting on us to deliver, Mohammad explains.

Mohammad is anxious about his job. His boss, is facing prospects of laying off all his 30 Delphi developers if this power-crisis continue further. Without power and internet connection, very hot summer and no electricity for cool water, Mohammad and his work colleges sit idle in darkness, sometimes, pass their time reading code printed on paper, or read some Computer books.

With little or no money coming in, Mohammad and his friends are very worried. "If I cannot earn a living, what should I do?". Sunset comes and at 8pm, the power is cut again.

Without the ability to do software development timely and quickly, Pakistani Delphi developers are quickly losing their advantage, and rival Indian Delphi developers are quick to mention this to their customers. Rama, an InfoTech business owner in Mumbai, says his company receives 2 or 3 customers requests a week to take-over Delphi development work from Pakistani Delphi developers.

DevExpress VCL Build 50 - A haunting in Nevada, part II

Many of the readers must have read my former article DevExpress Build #48: A Haunting in Nevada and earlier article DevExpress Build #48: security analysis.

Illegal users
Since the last two blog posts, DevExpress has taken certain security measures to prevent illegal users from using their DevExpress VCL products and more security measures.

Since the last haunting, your reviewer looks at certain security measures DevExpress has put in place and advises more security measures to prevent illegal users from using DevExpress VCL products.

Will it stop the Fiend and his friend DarkCraptor?
It will take a long shot to stop them, but the current Build #50 has positive steps to prevent the Fiend from sharing his DevExpress license with the whole world.

Your reviewer suggests:

Change the AES encryption algorithm slightly and changing keys on every build.
While the AES algorithm used to secure the DevExpress payload containing sources is secure, the key used is symmetric. Meaning, that the key did not change from Build #49 to Build #50. Thus, the Fiend could re-use his old unpacking codes on the newer version with little effort. Changing the AES encryption a little will raise the bar: It would require some serious coding to reconstruct the customized AES algorithm and unlock codes to unpack DevExpress payload.

Take out the start/stop code comment markers.
Your reviewer found certain comments fashioned in a manner which could expose how the code re-ordering works. If someone re-formats the sources and observe closely, there are certain markers which expose the where the start/stop of the code re-ording segments are. Take them out, pretty please.

Start to watermark the demos and help files.
Think about it... Since the demos and help files can be put in the customer's download section (hint: make it harder for illegal users to get help) why not watermark the files? It would be fun to put some "extra" information before the download process starts and then monitor "certain" forums for these files... download it and remove the user. 'Nuff said.

Webservices download instead and in-memory DLLs
Since few builds ago, DevExpress started to use in-memory DLLs. Here's a step further: Download extra DLLs in-memory from the DevExpress license service and then execute them on-the-fly, like extra decryption modules, and extra protection modules.

Watermark other files
Your reviewer thinks adding a couple of WaterMarked EXE files raises the bar further. Since there's a skin configuration file, why not watermark the EXE and then encrypt the EXE file?

Consider some files to be non-source and with watermarks
Your reviewer thinks it will be joy when ebars.pas, dxskin.pas are no longer distributed and only available in DCU versions. The other codes are available. That will raise the bar a little since it's a bit harder to remove DCU watermarks.

Download on demand
Your reviewer thinks: No payload. Download on-demand what the user licensed. That would be wonderful idea.

Find another vendor other than VmProtect.Ru
Your reviewer looked at many of the security features offered in VmProtect.Ru (VMProtect is used to encrypt the current DevExpress build #50 setup) and found it was garbage and toy copy protection. It will stop the casual hackers... but it may not be sufficient to stop a crap.

Your reviewer received certain emails about the last posts -
Fan Mail: The ***** us all trip
Your reviewer will continue to annoy a certain segment of the Delphi community.

Fan Mail: Tips for other Delphi Developers
Your reviewer hopes other vendors find these tips to be valuable to secure their products.

Conclusions
Since the last two builds, DevExpress has raised the bar, doing interesting watermarking, like re-ordering source code files, to the annoyance of some customers, but a necessary step to prevent software piracy. Your reviewer, a licensee of DevExpress products, hopes these suggestions will greatly deter cheat and lying Delphi developers.

Website Obituary: VisPdf.com, Sybrex.com, VersyPdf.com

PDF Blues
PDF generation used to be a lucrative market - Many aspiring developers made shoddy VCL components that creates PDF files or assists in creating PDF files, expecting to get rich overnight. This is sad tale of a PDF component vendor who could have made it...

What killed VisPdf?
It was almost the perfect business model - write a PDF library, sell PDF library for US$298 (Single User) or US$798 (5-10 developer licenses), then sell upgrades every year (20% of price), and do email support every day. Before the website went off-line, the vendor and author Mr. R. Husske claimed there were more than 100,000 users using it (Approx US$29,800,000 in sales).

So what went wrong?
1) Contrary to what the vendor says, your reviewer did some digging up some financial information and found less than 50 sales (Approx US$14,900) or almost 95% less than what was claimed.

2) The VCL written is not complete. It does not encompass the full set of specifications laid out by Adobe. This was probably the deal breaker. Load an Adobe PDF 6 (1.3) or PDF 7 (1.4) file, and it would lose certain graphics, or texts, but..., since this vendor never bothered to update it since 2 or 3 years ago (Since 2008) ... and this vendor out of business, your reviewer thinks this does not matter anymore.

3) There is amazing Perl Modules for PDF, PHP libraries also include PDF export out-of-the-box, free PDF code for Ruby, and PDF manipulation in Python, free PDF libraries in Java, why should I pay for Delphi PDF products?

Since IntraWeb is almost useless, many Delphi users who want to export to PDF from Delphi, would find many free libraries when Delphi users "translate" their Delphi Win32 product to PHP, Perl, Python, ASP, ASP.NET for the Web.

4) No Report writer export. Go back 5 years ago, QuickReport did not have a PDF export, ReportBuilder had no PDF export, Nevrona Rave had no PDF export, but now, almost every Report Writer on the market has a PDF export, so ... buying James Waler's PDF Export component for ReportBuilder, RareFind's export components for FastReport is now a thing of the past.

Since there is no PDF export adapter for those report writer, one less product to buy.

5) No Grid export component. There was no way to export from DBGrid (or InfoPower Grid, DevExpress Grid) to VisiPDF.

6) The main vendors - Gnostice PDF and Debenu QuickPDF surpassed VisiPDF in terms of feature and functionality, you could just replace the VisPDF component with Gnostice or VisiPDF. It did not take too long - maybe just a few hours of work to replace the VisiPDF to QuickPDF instead.

7) The DLL and 64-bit DLL issue. Some people use C++ to access legacy Delphi DLLs. Since there is no container or provision for DLL usage in VisPDF, people who use C/C++ could not use this product. Also, people who use 64-bit Visual C++ could not use the 32-bit DLL, if VisPDF was compiled to a DLL. Go figure.

Lessons
Your reviewer sees survival of the fittest - the best PDF product in terms of functionality and feature will win, not some half-implemented PDF library with so many limitations. Unfortunately, VisPDF vendor could have made substantial improvements to their product, but failed to do so.

Of course, you could revive VisPDF by doing the following steps:
1) Contact the vendor and ask them for a price to buy the copyright for VisPDF
2) Make a new website and more web-pages to sell the product
3) Spend hours and hours upgrading the PDF library to latest Adobe specifications

But of course, nobody would do such a thing because the copyright would be very costly and substantial time and effort to update the library. Also, there is no guarantee of success - you could end up closing shop like what this vendor did.

Next article
Your reviewer's next article will be on Nevrona Designs Rave Reports. Your reviewer has written about Nevrona Rave Report, asking Embarcadero to replace Rave Reports with FastReports instead. At least your reviewer is not the only person complaining about it - Thomas Pfister wrote on his blog he would no longer be using Rave Reports.

ModelMaker: Making Toy Models

ModelMaker, Code Explorer Review.

Your reviewer was looking around for a modeling tool to map and refactor his legacy codes and decided to look at ModelMaker, Code Explorer but found it much lacking else instead...

ModelMaker: Making Toy Models
Let me take the story out of context. Suppose you are a vendor who writes a Modeling tool for a certain language, the code-parsers that you develop, should support every aspect of that language. So, you should support the latest features added since Delphi 7, such as nested types, generics, Delphi's equivalent of partial classes to name a few. Then, you need to also support refactoring, proper UML diagrams and so on. Because the language keeps getting updated, you would need to update your parsers to support the latest features...

Fast forward to the year 2010.It has been almost two years since Delphi 2009 was released (Delphi 2009 was released on Aug 25th 2008) and you should expect Delphi generics to be supported in ModelMaker when you import sources to ModelMaker. Ditto for the ModelMaker C# edition. It has been nearly 5 (five) years since C# 3.0 was released and ModelMaker does not support any of C# latest features in NET3.0. The end result is you can post nasty messages on ModelMaker newsgroup or ask for a refund or don't buy ModelMaker tools until they finish updating their code parsers to support the latest Delphi and C# features.

Their newsgroup was "dead" for two or so months, but the ModelMaker vendor did absolutely nothing about it, since it was on the same newsgroup as the Jedi newsgroups, which was hosted free-of-charge. It was also good that the ISP that hosted Jedi, ModelMaker and other newsgroups on that site did not receive a single cent for the newsgroup hosting. It was in a way, good for the ModelMaker vendor - many of the messages where from pissed-off customers and nasty complaints - and all removed now and since nobody else can see them, they would blindly assume the product works and then find 101 problems...

By the way, I commend the person who "generously" hosts the talkto.net newsgroups, that person must have woke-up from the Delphi delusion - after 3 or 4 years from setting up a server to host newsgroups, he had no money to upgrade the server, no time to update the server with the latest security patches, and when the server got hacked, and taken off-line, the best thing happened - the opportunity he had to charge the Jedi people, ModelMaker, Madshi vendor and others for money to support the server was all gone. Hosting a private server (at today's prices) would have costed around US$250 a month, excluding initial licensing costs. That person probably spent US$3,000 a year (US$250 * 12) or US$12,000 (3,000 * 4 years) for that "feel good feeling" and supposed respect from others. In reality, it was more like - most of the Delphi people are nothing but free-loaders and the person who hosted the newsgroup server "woke-up" found out he had no more money left to pay, and closed shop. It's a good thing in an ironic way - if you are doing some business and make no money (or losses) from it, it's time to move on. Back to the review -

The C# versions of their product, ModelMaker for C# and CodeExplorer for C# suffers from serious limitations that make their products almost useless. Almost every vendor in the world uses partial classes, nested types, and regions inside classes, and both ModelMaker and CodeExplorer would choke and either corrupt the C# class file or just give up. Now suppose the above mentioned feature was implemented into the C# 3.0 specification 5 amazing years ago - the ModelMaker vendor had 5 years to "update their C# parser" but after 5 years was not able to do so. Almost every year since 2005, the ModelMaker vendor was busy charging "upgrade" fees, and the same people would ask when these features would be supported. Now that Visual Studio 2010 is out and the C# language has been updated, don't be surprised that nobody uses ModelMaker for C# and CodeExplorer for C# because it does not support basic features in the C# language.

Concerns
This leads your reviewer to wrap-up this review with few notes:
1) Prior to the newsgroup being removed, the ModelMaker newsgroup was filled with complaints and won't buy until the ModelMaker/CodeExplorer is updated.
2) Since the last update for ModelMaker was on September 15th 2008 (two years ago), all the vendor was doing was nothing but just re-compiling or updating the integrations to use the latest version of Delphi and charging for upgrade fees.

If  a respected vendor like ModelMaker tool does not update their code-parsers to use the latest Delphi grammar (and ditto with the C# versions), that means that either the vendor has burned-out all his money and started to leave the site as-is, and just charge upgrade fees (and no updates) or it is an indication of greater issue - nobody is buying his product anymore.