Mind you that I had used ProDelphi less than a week before this error came up.

My initial reaction was to follow the message’s direction and reinstall the program. That did not help -  the same error come back after I reinstalled the program.

Strange, I can’t remember when was the last time I had such an issue with an NTFS formatted drive.

I started to look into this issue and I finally figured that this error message was a result of the corporate anti-virus software – Symantec Endpoint Protection – getting a new virus definition update and deciding that ProDelphi as infected. Annoying to say the very least.

The solution was to add ProDelphi’s executable (profiler.exe) as an user-defined Exception and reboot.   After that ProDelphi was running again without incidents.

The article is an overview of Lazarus/FPC and cross platform development. It explores Lazarus/FPC cross platform capabilities and dices into some of the IDE features. The cool aspect of this article is that is being presented in a non Delphi venue that is dedicating it’s pages to cross platform development. This exposing a Pascal IDE  to a “new” audience.

Most certainly, Lazarus brings to the table cross platform development in a way that is more native to your target than .NET et al. Lazarus produces native code for Windows, Macs and Linux. I can only imagine where we could have been if Borland would have gotten Kilyx right… In any case, I have played with Lazarus and FPC for the past couple of years and I am to a point that I am willing to start a small cross platform project solely using Lazarus and FPC.

Here is a link to the article – unfortunately one has to be a subscriber to read. If you are not a subscriber, you can go to your local newsstand or book store and read the article.

The Investigation – Part I
The issue was that the service failed to obtain the proper local setting for decimal separator when running on a Spanish Mexican Windows Server 2003. In other words, the service would not correctly store numeric data in the database’s string fields. The issue presented itself only when the service started as part of the normal boot up process. When the service was restarted it would get the proper decimal separator. Strange behavior indeed.

I verified that the code was indeed written to obtain localization information from the OS. During the Service startup the program issued a call to the Windows function GetLocaleInfoA to obtain localized information – in this case LOCALE_SDECIMAL (0xE). This call uses locale ID information obtained on a prior call to the Windows function GetThreadLocale. So far so god.

So after looking into the issue I was able to determine that the problem happened only when I booted up the computer and that the problem would fix itself if the service was restarted. In light of that discovery the Project Manager in charge thanked me and assigned the issue to some other person – a Windows OS specialist.

Their plan was to either delay the service startup or to restart the service after the computer was up and running. I argued that his approach was not a proper way to fix the issue, specially because we did not have a complete understanding of why the issue was happening.  Nevertheless I was told to go back to my prior assignment. So I did.

The Investigation – Part II
About a month ago I was approached yet again by the Project Manager because none of their quick solutions seemed to work. So I resumed my investigation.

After some digging around to try to isolate the issue I was able to determine that the problem lied in the Windows user that the service is using to start. The service is normally installed and set to use the Windows Local System account. When the service was started with the Local Administrator account the service performed as expected, and it did pick up the proper localization information.

The Investigation – Conclusion
Based on these facts I must conclude that Windows handles the locale information for the Local System account in a different way than it does for regular users. So my recommended fix for the issue was to have the services account information changed to run under a user account with enough privileges. In my view a much cleaner solution than restart services or delay service startup.

Links
Service Security and Access Rights
Local System Account

For the presentation I created a Virtual Machine for both Windows and Ubuntu to demo  the installation and I was asked to share it with the group. I figure other people could make use of it as well. So I decided to post it on my site. Off course that the Windows virtual machine can not be posted so don’t expect to find it here – sorry.

The Ubuntu VM is a using a VMWare virtual machine version 6.5 that can be run on Vmware’s Workstation,  Player, and VirtualBox  in both Windows or Linux. Two things to keep in mind when using VirtualBox is to “Enable IO APIC” on the General->Advanced tab, and to uninstall VMware AddIns before using it with VBox (Thanks Christoph!).

The VM contains the latest Lazarus IDE  running on Ubuntu 8.10. On the desktop of the VM you will find the script (Laz) that I used to install Lazarus. The user name is axf and the password is lazarus.

The file containing this VM can be found here. Be forewarned that the download is a hefty 1.8 GB – so go grab a cup of coffee, finish that project, clean up the garage… you get the idea.

While Windows installation is pretty straightforward – the usual download and install routine applies – the same can not be said about installing Lazarus on Linux.

I started by looking at the packages provided by the repositories and decided against because the packages where about a year old.  So I went to the Lazarus site and downloaded the Debian packages and ran into problems such as missing dependencies and the like.

After looking around I found a script that added the current lazarus repositories, dowloaded and installed lazarus.  The script is as follows:

#!/bin/sh
gpg –keyserver hkp://pgp.mit.edu:11371 –recv-keys 6A11800F
gpg –export 6A11800F | apt-key add -
echo “deb http://www.hu.freepascal.org/lazarus/ lazarus-stable universe” \
>/etc/apt/sources.list.d/lazarus.list
apt-get update
apt-get install lazarus

I also had to make changes on the Lazarus folder to allow my user to recompile and install components. So to correct permissions issues I created the user group Lazarus (or whatever name you like)  and added myself to the group. Changed permissions for the folder /usr/lib/lazarus by issuing the following command:

sudo chown -R :lazarus /usr/lib/lazarus

and the allowed the group to read, write and execute by issuing the following command:

sudo chmod -R g+xrw /usr/lib/lazarus.

I have also posted the presentation slides for the people that attended the presentation. The slides can be found here.

Please, let me know if you experience any problems with the VM.

Here is what I know:
- 6 + months duration
- SQL/Stored procedures
- Solid knowledge of Delphi – Action Manager, data grids, exceptions, OO stuff etc.
- pay rate 40-50/hr.

For more details drop Dan Chester a line. He can be reached at “dan at nityo dot com”.

DISCLAIMER – I do not claim that this index is an exact science and the results should be taken as, maybe, a relative indicator not as an absolute true. Also, because I am still working on this the results may change. You have been warned.

As you may have guessed not much has changed. Delphi is still commanding about 0.4 % of the market while the lion’s share goes to Java and C#.

Just as a reminder: this index is created by running a search for job posts that mention specific languages. These jobs are advertised during the last 7 days. I use the site http://www.Juju.com as a source for data and I try as much as I can to eliminate false positives. This site is restricted to the United States.

Your comments are welcome.

Wow! Clipper is still around. That brings back memories, Clipper, FoxPro, Turbo Pascal, Quick C, DOS, 640k/704k RAM, Novell…(I’m dating myself)

Have you run into other bizarre or unexpected things out there? Would you mind sharing with us?

In a couple of posts Jim McKeeth has pointed out that the Delphi language has been climbing in the TIOBE Index. He has also called the community to action in order to make sure that whenever we referenced Delphi on a post to do so using “Delphi programming”. That way these references can be properly accounted for in such index.

The TIOBE site states that “The TIOBE Programming Community index gives an indication of the popularity of programming languages.” Such index is derived from search engines and their popularity. More on how the TIOBE index is calculated can be found here.

So I started to think. What that index really means to me? Does it mean that Delphi is coming back? Does it mean that Delphi developers are chattier than their colleagues? Does it mean anything at all? Or is just another indicator that can be used to one’s advantage on a discussion or argument?

I figured that what I really want to know is how easy is to find a job that utilizes a specific language skill set. That to me is a relevant measure of popularity. A measure that really matters because more jobs should be available for the more popular languages, right?

So I went on a quest to figure how to derive this index. My plan was simple: I figure I needed to find a couple of sites that collected employment information from other sites and allowed me to use search queries with a combination of keywords and a time limit – say jobs posted in the last 7days or so.

Easier said than done. While I found a handful of sites that filled the first requirement I was only able to find one site that also allowed me to restrict my search to the last 7 days – http://www.Juju.com. Unfortunately this site is restricted to the United States. So I ask for your help; does anybody know of a site that is more global than this one? Or better yet, does anybody know of sites such as juju for your region/country? Please let me know.I will, time permitting, continue on my quest to figure better sites to pull out this information and try to do it on a regular basis so I can trend this data.

Anyway, I then proceeded to search jobs that required specific programming language skills. After fiddling with the queries I was able to get result with a relative small quantity of false positives.

Here are the results of my hour of work on a Sunday morning trying to answer my questions about indexes.

But before I do so here is a DISCLAIMER – I do not claim that this index is an exact science and the results should be taken as, maybe, a relative indicator not as an absolute true. Also, because I am still working on this the results may change. You have been warned.

These results do not show a very favorable picture. Still, I will continue to run these queries on a regular basis to be able to come up with trended data for each language.

So without any further ado here are the results: Java came in first with 2889 hits, followed by C# with 1369 hits. Delphi was in the 14th place with 34 hits.

Here is the complete list of the programming languages that I researched and their position:

Position	Language	Hits
1	Java	2889
2	C#	1369
3	Perl	720
4	PHP	566
5	C++	549
6	C	497
7	Basic	472
8	Python	247
9	Cobol	243
10	ActionScript	221
11	Ruby	189
12	SAS	187
13	ABAP	95
14	Delphi	34
15	ADA	31
16	Fortran	24
17	Lua	9
18	LISP	9

Please let me know if you have any suggestions, languages or better ideas on how to make a good assessment of the popularity of a language.

I have been looking everywhere I know where to look: Craigslist, Monster, Dice, NW classifieds, etc…. But nothing has turned up yet. I have even considered to expand my search to other states and even other countries.

Do you experience the same issues when looking for a new Delphi position?

Where do you look? How far would you consider moving for the right job?

What is your experience when searching for a Delphi job?

Would you care to share your experiences and thoughts with us?

Or at least participate on the poll on the top right of the page.

I added this after original post -> And just to make sure I make myself clear: I am looking for my next Delphi job! I will relocate anywhere if the position is right.

I tried using the Windows event log as a target but found the Windows Event Viewer to be at least irritating to use. I then switched to using the Windows method OutputDebugString to send messages about the program’s state. I used Delphi’s Event Log facilities when possible to receive the messages. Otherwise, I used  Sysinternals’ Debugview to receiver the messages.

This was indeed a better solution but not perfect  as some of the systems that I inherited grew in complexity and services became distributed across multiple computers. I currently maintain a Windows service that has six threads that interact with as many as 132 devices over a network and stores collected data on a SQL database. This caused bugs to get trickier to resolve. I decided to change my debugging strategy to include an IP component.

I chose UDP/IP for the lower overhead and the “send it and forget it” operation – that meant that the debugged programs would not be affected by the debug message recipient not being on-line. I also chose the destination address to always be 127.0.0.1.  That way I could ship products with some debugging enabled without affecting the users’ network at all.

I know, this may not seem much different that using OutputDebugString. But the twist was that I created a “forwarder service” that forwarded all the UDP/IP messages to an external computer where an UDP/IP client was up and running.  That allowed me to control when debug traffic got outside the host and where it went.

The UDP/IP client is able to display messages received in real time as well as automatically store messages in text files that can be easily imported to Microsoft’s Excel or OpenOffice’s SpreadSheet where you can filter and sort messages to your heart’s content.

The UDP/Client is also able to receive messages from multiple sources and that give one the ability of seeing how different components interact and contribute to create an issue. This becomes an advantage in solving issues generated by concurrent programs running on a system.

My current solution has the following parts:

• LibEventLog.pas – This unit contains the TMsgLogger object declaration as well as an initialization section that instantiates the Object. This object is responsible for sending the messages either through  OutputDebugString and/or UDP/IP. It also has the ability to redirect assertions. In order to use the the EventLog object all one has to do is to include this unit in the use clause of the units that need to send messages.
• UDPFwrdr.exe – This is a Windows service that intercepts and forwards the UDP/IP messages.
• UDPConfig.cpl -  This is a Control Panel applet that allows the Forwarder’s destination address to be changed.
• UDPMonitor.exe – This is the UDP/IP client that receives messages generated by the application using LibEventLog and forwarded by UDPFwrdr. UDPMonitor receives, displays and saves all messages received.

LibEventLog is currently using Indy 10 and I tested it in Delphi 7, 2006 and 2007.

I have included the source code here so you can download it and use it. Please let me know what you think.

If you make any improvements I would ask you to submit those back to me.