Ruminated Rumblings

In yet another stunning victory for Microsoft's cross-compatibility, their RTF system is incompatible between their own products. Let me begin by explaining that I have a Delphi app that uses a mail merge system to merge database text into a document. Naturally, you can do this a lot of different ways but, for my particular instance, I need to merge from a non-ODBC compliant database and then automatically E-mail the resulting document to the correct person. This is a management tool we use fairly heavily. In the past, I've always just used raw HTML formatting because it's handy and relatively standard. The particular request I've been working on is to format the resulting merge so that it can be printed in a "one summary page per item" format. HTML has the ability to do this with a style sheet as such: < STYLE TYPE ="text/css" > P.breakhere {page-break-before: always} </ STYLE > and use it via: < p class ="breakhere"...

A few weeks ago I started down the path of discovering how to GeoCode addresses for Delphi. This is related to a project we had where we wanted to show a map of a given point and then show facilities located near it on a map. I had originally started working with maps.live.com (which is a MS site). They have a decent little interface for JS that seemed to work for what I wanted AND I didn't have to store the annoying little GeoCoding addresses anywhere. This works great if all you want is a single address. For instance, the code below works for single addresses: < html > < head > < title > Address Lookup </ title > < meta http-equiv ="Content-Type" content ="text/html; charset=utf-8" > < script type ="text/javascript" src ="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6" ></ script > <script type= "text/javascript" > var map = null ; ...

Serge Dosyukov recently posted about the speed of the Delphi installer. While I agree that it's annoying to have to wait for the initial installation, I find that one of the largest failures in most development environments (including Delphi) is uniformity in a group setting. For some reason, you can use products like subversion to manage your source code, but there is no product to standardize and manage your development environment. In our case, we have a handful of developers who all are working on different aspects of a large application (>1 million lines of code). We need to be able to manage the third-party add-ons and Delphi patches in a uniform way. The only method of doing this (to my knowledge) is to carefully install everything in the same paths and, usually, same order. At one point I thought we could be clever and tried to install all add-ons to a networked drive for every workstation to minimize the amount of thrash we encounter when installing SP for the add-ons....

I'm back to work on the HTTPS Post issue with DHL's ShipIt XML API. The problem I'm having is when I use Indy to post the xml via an HTTPS post, the response is that the file is malformed. I should mention that I'm using a relatively recent version of Indy 10. If I use FF (if you don't have it, check out the Poster add-on, let's you play with the HTTP functions using FF's libraries) it works fine. The first problem is that it's a little hard to see what FF is actually doing that is different from what Indy is doing. Enter Fiddler , stage right. Fiddler is an http proxy that captures that http information and lets you manipulate it or display the raw headers. So, pointing FF to the localhost proxy on port 8888, the headers I get are: POST /apilandingtest.asp HTTP/1.1 Host: ecommerce.airborne.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0...

If anyone has ever tried to get the OpenSSL libraries to work with Indy, you may have experienced a lot of pain with the process. I'm in the process of trying to develop an application for DHL's ShipIT XML Api that utilizes an HTTPS POST. The actual post code from Indy is easy response := HTTP.Post(url, file); but getting the SSL side to work, especial on Vista, is painful. I should disclose here that I have yet to get the HTTPS to send the data correctly via Indy, but I did finally get OpenSSL playing with Indy under Vista. Basically, the problem stems from the fact that Indy lets you make SSL assignments that will fail at run-time and then provides very little in the way of information about the failure. This is caused by IdSSLOpenSSLHeaders.pas not having any meaningful error reporting on the OpenSSL libraries failing to load. To be clear, it does basically say "Can't load library" but that's it. To fix it, search on SafeLoadLibrary in IdSSLOpenSSLHeaders.p...

For everyone who isn't hiding under a rock, Embarcadero has agreed to acquire CodeGear from Borland. I'm sure all of us who have been annoyed with Borland for the last 5 years are relieved that the other shoe has finally dropped. Why 5 years you ask? Let's call a spade, a spade, and say the last really good release of Delphi was Delphi 7 until Delphi 2007 hit the scenes. That comprises a 5 year window where Delphi basically floundered around trying to be things that the core audience really didn't care about in a way that hurt sales and led everyone to assume that there would not really BE another good version of Delphi... ever. Fortunately, Delphi 2007 came out and changed that. Not right off the bat, it did take a service pack (or two) to get things flowing relatively smoothly, but I think everyone pretty much agrees that 2007 is the version to beat now. The biggest question is probably, "What's the future of Delphi?" Not in a "Delphi sucks" s...

Adding to my previous post on detecting virtual environments, here's the code for detecting Virtual PC. Note that it's a conversion from CodeProject, the original author is here . I also didn't write the conversion, I'm simply accumulating the VMM detection code here. Original credit for the conversion goes to Dennis Pasamore who did the bulk of the conversion work with some assistance from Avatar Zonderatau. Code: function TForm1.IsRunningVirtualPC: boolean ; asm push ebp; mov ebp, esp; mov ecx, offset @exception_handler; push ebx; push ecx; push dword ptr fs:[0]; mov dword ptr fs:[0], esp; mov ebx, 0; // Flag mov eax, 1; // VPC function number // call VPC db $0F, $3F, $07, $0B mov eax, dword ptr ss:[esp]; mov dword ptr fs:[0], eax; add esp, 8; test ebx, ebx; setz al; lea esp, dword ptr ss:[ebp-4]; mov ebx, dword ptr ss:[esp]; mov ebp, dword ptr ss:[esp+4]; add esp, 8; jmp @ret1; @exception_handler: mov...

CubicDesign on delphi-talk.elists.org recently asked the question: "How do I know/detect if my software is running under Windows [or a virtual environment]?" Well, it turns out that it's a lot harder to tell than you would think. Apparently, the VM (VMware, Xen, Wine, etc.) doesn't really want you to be able to do this. At least not easily. For VMware, there is a decent little C routine called jerry.c that does the trick. Jerry actually uses a simple communication channel that VMware left open. It's not 100% foolproof since the admin can change the channel, but that's not likely going to happen unless the system is specifically designed to be a honeypot. If you're running on a honeypot and still have a legitimate reason for detection, you could look at the much more complex scoopy implementation which inspects how the system is actually virtualized using the SIDT CPU instruction instead of a communication channel. Another reference (red pill) is here . F...

Has anyone tried to convert a Western-style calendar to either the Islamic or Hebrew calendar system? I've spent a bunch of time looking for a Pascal unit to do just that so I could include Muslim and Jewish holidays in my holiday class but haven't found any great resources. I finally found some C/C++ code that did the work and converted it over to Pascal. Keeping in mind that this is still a new conversion and that I didn't write the actual conversion logic, I'm publishing the code to help other would-be calendar converters. All of the conversion algorithms (and credit for them) are from Calendrical Calculations by Nachum Dershowitz and Edward Reingold. I added the Day and Month name strings from various Google searches on things like Hebrew Month Names and Islamic Month Names, etc. I've compared the resulting output to both published calendars and to other conversion tools that do not provide their source. So far, I haven't seen any discrepancies other than so...