Archive for February 2009

“Logon Process Has Failed To Create The Security Options Dialog” Error

Despite my preference for non-Windows operating systems, I do keep some Windows versions and at least one Windows machine in my arsenal. Here in my home office I have a desktop running Mandriva (I’ll get into that at another time) with a laptop next to it running Vista. I know, I know…. “bad Dan.” Save it. I already know.

Anyway, in the last week or ten days, Vista locked up on me. It would slug itself along as if a process was using up 100% of the available CPU and memory. It’s not a top-shelf machine, it’s just a Dell Inspiron 6400 w/ Core2Duo CPU and 2GB RAM – my wife, Debs, and I have similar systems.

Vista would hang, nearly unresponsive, and 15 minutes or so after I hit CTRL+ALT+DEL (nearly immediately, due to my severe lack of patience with personal computers), I finally had a response, though still no task manager. Less helpful than most BSOD‘s, the dialog stated simply:

Logon process has failed to create the security options dialog
Failure – Security options


After poking around the Windows internals as best I could, while still being a good boy and not violating any possible terms of my license (yes, it’s a Genuine copy), I confirmed my suspicions: Vista still sucks.

However, after working around a few things, it was actually Microsoft’s “Safe” Mode (sic) bootup that helped me out. By trimming down the processes, I was able to debug the issue and narrowed-down the culprit: AcroRd32Info.exe. In fact, the whole Adobe Acrobat Reader installation was crapped-up. It turned out, every time I would load a multilayer PDF, it was causing a serious buffer overflow issue that was spiking CPU usage as high as 100%, memory usage to 99.6% of available RAM (spilling over into virtual memory) and maintain those levels until I hard-booted the machine. All total, between the three screwups, I lost about 3.5 full weeks of research for an AI neural network application I’ve been building, but nothing permanent. It’ll be like a drunken bender to the brain. It will survive.

Anyway, the lock-ups were primarily my fault, as should be expected. I was using an outdated version; I was using 8.1, whereas 9.x is the current version as of this writing. I installed the latest version and tried to reproduce the overflows — nothing. Keeping my fingers crossed, I think I can mark this as solved.

Some Interesting Metrics on PHP-vs-ASP-vs-[etc.]

Due in part to the fact that our mailing list software rejects Google search URL’s as SPAM, and also because it’s potentially of interested to someone out there, here’s a copy of an email I tried to send to Richard Heyes on the PHP General mailing list regard market penetration and usage of PHP versus other languages.

Keep in mind that it was all typed into an email body, and is in it’s original form. It hasn’t been edited or cleaned up or anything, so don’t blame me if there are errors. Blame Richard. Why? Beats the hell out of me, just do it.

On Sun, Feb 8, 2009 at 09:35, Richard Heyes wrote:
> Hi,
> Can anyone point out some general statistics on PHP usage compared to
> other server languages? I’ve tried Netcraft, but they only appear (or
> I’ve only found) to have statistics on the httpd server used.


Use Google’s ‘filetype’ parameter. That’ll give you a general
idea of market penetration. It doesn’t give you any scientific stats
on the number of developers, nor does it account for files using
aliased processing or masking methods, but gives you a very basic idea
of the general shape and format of today’s World-Wide Web.

For this example, I’m only going to use *.com results (to maintain
some semblance of sanity here), and only currently-indexed files as of
this writing. I’m also only going to use extensions that make sense
(for example, you’ll find some .php7 files on Google, but we know
they’re not legitimate results). Also, understand that there will
most definitely be a margin of error, but considering the major
programming language developer’s preference for one language over
another, I’d say extension-spoofing will be minor enough to be
obscured by factual results. This is also pages indexed, not
sites indexed, nor servers reporting the languages as available.
Also, I’ve found that Google – for whatever reason – gives different
results when using cAsE-sEnSiTiViTy for `filetype` searches (though
the results themselves don’t appear to change), so in situations where
the numbers differ, only the HIGHEST number for that search is used.
Note the case in the search URL given.

Total .com results in Google:
18.610 Billion (100%)

(971M + 14.7M + 35.1M + 1.98M + 1.62M + 4,260) = 1.024B (5.5%)

(1.54B + 803M) = 2.343B (12.6%)

(300M + 22.1M + 5,450) = 322.105M (1.73%)

CGI + PL (We’re aware that .cgi can be anything, but we’ll couple
it with Perl here):
(89M + 41.3M) = 130.3M (0.7%)

RB (Other Ruby[-on-Rails] searches were too minute to mention):
231,000 (0.0012%)

PY (Python):
4.46M (0.024%)

HTML (for good measure):
2.29B (12.31%)

6.114B (32.85%)

Perhaps surprisingly, according to this, ASP is in the lead —
even surpassing plain HTML.

Disclaimer: By the time I send this email, the numbers will have
no doubt changed – and your results may also vary based upon your
geographic location due to Google’s network and data distribution.
This isn’t by any means scientific, yada-yada-yada, I’m not a
statistician or mathematician or even a nice guy, Google doesn’t
sponsor my work, blah, blah, blah. You know the drill.

And there you have it.

Overriding PHP Settings

Getting the following error?

Invalid command ‘php_flag’, perhaps mis-spelled or defined by a module not included in the server configuration

Well, if your host and server configuration allow it, and should you so desire, you can override some of the php.ini settings for your site (and each subdirectory within your web directory). While you can’t override PHP_INI_SYSTEM settings, there’s still a host of other settings that can be overridden while still maintaining the rest of the configuration of the system – if your server is set up to allow it. And no, n00bZ, it won’t override php.ini for the rest of the box.

To grab your php.ini and copy it to the current directory, just run this command:

cp `/bin/env php -i | grep "Loaded Configuration File" | sed 's/.*=> //g'` .

Then just edit the php.ini and save it in place. Voila! No need to restart Apache or anything.

Finding the Maximum Number of Command Line Characters

Whilst idling in EFNet #php.doc, Kalle brought up the question about maximum input length from the command line on Linux. It’s acceptable to presume that the maximum length is ~65536, as you might expect ((32 * 8)2). But how can one be sure?

A bit of code:

while(test "X`echo $str`" = "X$str") > /dev/null 2>1 && res=`expr "X$str" : ".*" 2>&1` && len=$res; do
i=`expr $i + 1`;
echo "Maximum characters allowed via command line: $len";

That’ll do, pig. That’ll do.

Yeah, so don’t tell anyone….

…. but apparently I’m running a blog now. Justin will hate me, probably more than I hate myself, considering his loathing for the buzzword “blog.” Very similar to my disgust with the term “Web 2.0.”

Regardless, I’m putting this up for code samples and random ramblings, not to impress you.

So there.

P.S. – Want to know who is really to blame with this? Philip Olson from Ro-Sham-Bo. We’d been tinkering with his site, hosted on one my servers, and he’s running this hip-new-thing-like-ya’-heard-about called Serendipity. I had an extra domain (one I just picked up last month, actually) and some thoughts floating around in my cranium, bouncing off the inner walls, and decided that everything could culminate quite nicely in a voyeuristic fashion.

That, and perhaps I won’t forget some of this stuff six minutes after I think it up.