Version 1.10 on SQL Server

MediaWiki 1.10 is out. That's my cue to start trying to get my changes integrated into the shared source code. I've started on that with a Bugzilla, Bug # 9767 I pretty much have 1.10 all working, except the thumbnail functionality stopped working. In my configuration, ImageMagick 6.3.2-5 is used to generate the thumbnails. Now, instead of thumbnails, I get "Error creating thumbnail: The input line is too long". The first part of this message, up to the colon, is generated by the PHP code. The second part, however, appears to come from ImageMagick itself. In my modified MediaWiki version 1.9.3, this had been working -- so I need to figure out what's changed. (... a little time goes by ...) OK, It's not ImageMagick's fault. The problem had to do with the documented (http://news.php.net/php.internals/21796) flaw with PHP's invocation of cmd.exe. My implementation of the wfShellExec function in GlobalFunctions.php now contains this:

...
   } elseif (php_uname( 's' ) == 'Windows NT' ) {
      # This is a hack to work around PHP's flawed invocation of cmd.exe
      # http://news.php.net/php.internals/21796
      $cmd = 'cmd /C ' . '"' . str_replace( '/', '\\', $cmd) . '"';
   }
   wfDebug ( "wfShellExec: $cmd\n" );

   $output = array();
   $retval = 1; // error by default?
   exec( $cmd, $output, $retval ); // returns the last line of output.
   return implode( "\n", $output);
}

Note that this differs in two ways from the distributed version of GlobalFunctions.php:

1. Prefixes the command with "cmd /C"
2. Replaces all occurrences of slash with backslash

I did the first, as I remember, to get Batik to work (for processing SVGs), which is driven by a batch file. I did the second to get some consistency in the direction the slashes are facing. The MediaWiki code is a little bit unclear when it decides to stick slashes into strings that represent filenames, and sometimes uses pieces of a URL (forward slash) to append subdirectory names to existing directories (backward slash). All I do is format the result as though it's a filename (which it will always be in this situation, since we're trying to execute something). Naturally, there will be a problem if there ever arises a situation in which the slashes are being used for something else, but I haven't seen this happen. Presumably they would show up uuencoded if they were being used (say) as part of an argument to a command.