Nikolay Pavlov

I decided to start a column where I will point my finger at repulsive coding and software engineering cases, which happened to be released to the unsuspecting public too hastily and / or without good thinking.  Someone will say it’s easy to criticize.  I don’t care.  Someone has to tell the plain facts and the sooner we raise our voices, and the louder, the better.  Demand for programmers has spawned numberless hordes of dim-witted script-scribblers, who claim themselves programmers, and who spill out hideous crap to the innocent audience out there.

The choice for my first rant is PHP’s function strpos().  Actually, PHP itself deserves a scorching rant, and maybe I will come to it eventually.  Right now, I will only focus on this specific function.

But what’s wrong with strpos()?  It is a simple routine, available in a basic library for virtually any language out there.  It merely checks the occurrence of a substring in a string.  And so it does.  Except for this very peculiar unique behavior, stated in the official documentation:

Returns the position as an integer. If needle is not found, strpos() will return boolean FALSE.

If you know that strings in PHP are zero-based and the frivolous nature of PHP when it comes to type-safety you will be already on your toes.  It is a realm for unspeakable bugs out there.  The warning in the official documentation, and the vast number of user comments in the official documentation page are a living proof of the disaster.  Please read these notes, really.  They would be hilarious, if the fact that something like this made it to the broad audience weren’t so sad.

I really wonder why the hell a simple function like this should possibly return values in more than one type, and for no apparent reason.  Just tell me the added value, please! 

Sadder, no one ever bothered to fix this ill behavior.  Yeah, I know compatibility will suffer.  And compatibility is important.  But when you have something that broken, hell, deprecate it!  State clearly that there is a replacement, and that this freak should no longer be used!  Instead, PHP guys got themselves busy with implementing half-assed OOP features in the language, and useless exception support.  Maybe I should just say “Go, Open Source!”.

Further study of the problem on platform target enlightened me that the cause is by using assemblies, compiled with x86 target.  As indicated by Stilgar, these can be any wrappers around 32-bit native code, or COM interops to 32 native COM objects, or any assembly, compiled to target x86.  Examples I know include Managed DirectX assemblies, XNA Framework.  

Similarly, trying to run a x64 assembly on 32-bit Windows will also fail.  Mixing 32-bit and 64-bit code in one application is a “no-no”.

In my case I was referencing a COM object, created in Borland Delphi (obviously native 32-bit code, Delphi still can’t compile 64-bit native).

In short, when you migrate your code to x64, or you want to be sure it will run on 64-bit Windows, please check carefully your dependancies, and pick your platform target accordingly.

Further problems you can have when moving to 64-bit code is the size of datatypes (for example, IntPtr is now 8 bytes instead of 4).  I suggest you read this article at MSDN.

Recently I tried to run a WinForms project, developed for NET Framework 2.0, but in Visual Studio 2008, under Vista Ultimate 64-bit.  To my surprise, it failed with “Win32 error - Bad executable format”.

The project was configured for “Any CPU” platform, which comes by default.  However, the EXE would not start on 64-bit Vista, but would run just fine on any 32 XP or Vista around.  Rebuilding the project under Vista 64 did no good.

Finally, I built it explicitly for x86 platform and it ran without a glitch!

I still have to inestigate why this happened, and what native 32-bit components is the project loading, or is it some misconfiguration.

For the time being, just take the warning - don’t put your life in the hands of “Any CPU” option.  If you want compatibility accross both 32 and 64-bit worlds, just state x86 explicitly.