Fri, 11 Jan 2008

Microsoft and the POSIX Standard.

POSIX defines a set of functions for retrieving information, such as file size, creation date, last modification date, ownership etc about files on disk. Two commonly used functions in this set are defined as follows: 


   int stat (const char *path, struct stat *buf) ;

   int fstat (int filedes, struct stat *buf) ;

The first operates on the filename, and the second operates on a pre-existing file descriptor. Both functions interrogate the file system and fill in a bunch of fields of a struct supplied by the caller.

Microsoft also provides these functions in its C run time library and even documents them here and here. However, stat, the function that is probably more commonly used than fstat, does not always work as expected. In particular, the following scenario:

On any sane system, the file length field of the struct filled in by stat and fstat calls in the above scenario should be the same. On windows however, they are not, fstat returns the correct value N, while stat returns zero.

With the help from a kind volunteer on the libsndfile-devel mailing list this broken-ness was confirmed on Win2k, WinXP and Vista.

Microsoft; bringing new and improved versions of the DeathStation 9000 to the desk and laptop bag of every programmer. From that wiki page:

DeathStation 9000 (often abbreviated DS9K) is a fictional computer architecture often used as part of a discussion about the portability of computer code (often C code). It is imagined to be as obstructive and unhelpful as possible, whilst still conforming to any relevant standards, deliberately acting unexpectedly whenever possible.

Posted at: 23:21 | Category: Windiots | Permalink

Tue, 04 Dec 2007

Microsoft and the 1999 ISO C Standard.

Any programmer with a better than passing familiarity with the C programming language would know that the current standard for C is the ISO/IEC 9899:1999 standard published in 1999. If they program on Linux systems or use the GNU C compiler they might also know that while GCC is not fully C99 compliant, it does however come pretty damn close. In particular, many of the things listed as broken on the status page are mostly working (Complex, math.h, stdint.h, inline etc) and the things listed as missing are missing because there is probably not a huge demand for them.

In the world of Microsoft however, Visual Studio still has no serious attempt at support for C99 even eight years after the standard was released. Microsoft claims conformance with the 1989 C standard but seems to show little to no interest in even attempting to pursue conformance with the later standard.

In particular, the Microsoft compiler has the following C99 issues:

These short comings of the Microsoft compiler can make compiling Free Software written in standards conforming C rather difficult with that compiler.

The one that hits me worst with respect to compiling libsndfile and libsamplerate on windows is the lack of C99 maths functions, in particular lrint and lrintf. My current solution for these functions are inline assembler functions. However, Microsoft has just recently joined the world of 64 bit operating systems and their compiler for that platform supports neither the lrint family of functions nor inline assembler functions. WTF?

However, just today, I found out that the GNU GCC, GNU Binutils and MinGW teams have just released MinGW for windows 64. That should make things a little easier.

Posted at: 21:54 | Category: Windiots | Permalink

Mon, 12 Feb 2007

The Windoze tmpfile Implementation.

During a discussion on the libsndfile-devel mailing list it was brought to my attention that although windows does have an implementation of the POSIX function tmpfile: 


    #include <stdio.h>

    FILE *tmpfile (void) ;

the temporary file created on windows is placed in the root directory of the C:\ drive. Couldn't possibly be true you think? Think again. From microsoft's own documentation

The tmpfile function creates a temporary file and returns a pointer to that stream. The temporary file is created in the root directory. To create a temporary file in a directory other than the root, use tmpnam or tempnam in conjunction with fopen.

So the global village idiots of microsoft implemented tmpfile so they could say that windows was POSIX compliant, but did so in a way that is so broken that nobody in their right mind would actually want to use it.

But its actually worse than that. According to microsoft, the tmpfile function is deprecated because it supposedly isn't secure. From the same page:

Creates a temporary file. This function is deprecated because a more secure version is available; see tmpfile_s.

(Note : I wonder if microsoft bothered to tell the people responsible for the POSIX Standards that microsoft has deprecated a function in their standard.)

The fact that the GNU libc version of tmpfile is secure means that it is possible to write a secure version of this function. That means that the only reason microsoft could have had for deprecating it was because their version was insecure. They deprecated a POSIX standard function to replace it with a their own non standard function tmpfile_s: 


    errno_t tmpfile (FILE** pFilePtr);

Now I for one, cannot see any reason why this version of the function is any more secure than the POSIX version. It also far easier to do the wrong thing with this function than it is with the original.

Once again, microsoft shows that it employs people who are probably too stupid to feed themselves or crap in a toilet without help, in spite of the fact that is also employs some really smart people.

Posted at: 12:53 | Category: Windiots | Permalink

Thu, 06 Jul 2006

Visual Studio : Debug and Release Builds II

Some people don't get why the stupidity of separate Debug and Release build settings is so bad. Let me spell it out.

The problem is that for any near sensible project, the Debug and Release build settings are mostly the same. It would therefore make much more sense if visual studio kept a single copy of the stuff thats the same and only kept separate versions of settings when the settings are genuinely different. To me this bleeding obvious, so why is this so hard for the Windiots at microsoft and the people who use their software? Why do microsoft's customers put up with crap like this?

I believe that using microsoft products exclusively makes people stupid.

Posted at: 15:05 | Category: Windiots | Permalink

Sun, 02 Jul 2006

Visual Studio : Debug and Release Builds

In my day job I do some stuff with microsoft's visual studio. This tool has so many flaws that I am amazed that anyone gets anything done with it.

My biggest gripe is the way it separates Debug and Release builds. Taking each of these alone, there are something like 40-50 compiler and linker settings which are designed to be set and modified via a dialog box.

These settings do get set to a sensible default when the project is created. However, for anything other than the most trivial projects, these defaults will need to be modified and they will get set when the developer is at his busiest. The developer will have visual studio working in Debug mode and he'll have just added some new functionality which needs an addition to the include path or a changed compiler flag. He'll be in the zone and he'll want to get on with what he's doing so he'll fix the Debug mode settings and forget about the Release mode.

Then a week or more later, when the developer finally has something that he/she is happy with in Debug mode they then switch to Release mode only to find that their project doesn't compile. This means more time is sunk into fixing their Release build while simultaneously making sure their Debug build doesn't get broken. So you ask, "where's the settings diff dialog box?". Well, there isn't one. The only way to do this is by flicking back and forth between Debug and Release modes remembering the settings in each. Brilliant!

Separating Debug compiler settings from Release compiler settings like this is just plain stupid. It goes completely against the concept of "Once and Only Once".

Personally I hope microsoft don't fix this. I say let the Windiots waste their time on crap like this while we in the Linux world use decent tools.

Posted at: 13:47 | Category: Windiots | Permalink

Tue, 20 Jun 2006

Acrobat Reader on Win32.

At work I have two machines, one running Linux and one running Windows XP. I would like to let the second one go, but I need it for some of the work I'm doing.

I also tend to read quite a few PDF documents. On Linux I use the excellent Evince PDF and Postscript reader while on windows I use Adobe Acrobat. Of course, since I'm running Acrobat on windows, I turn on the auto update feature to make sure the machine doesn't get owned by some haXor's malware.

So fine, this morning the Acrobat reader finds that there is an update available and I tell it to go ahead, download and install it. At the end of the process, it asks to reboot the machine. WTF??

I say no, reboot later. Now, every time I open a PDF document, Acrobat whines about the need to reboot. Acrobat is an application. Why does installing this bloody software need a reboot?

And the Windiots just don't get it. Reboot after installing an application? Thats normal.

Coming from the Linux world, this is nuts. If any software company released some piece of binary crapware application (ie specifically not device drivers) that required a reboot after installing it; Linux people would just not install the crapware.

In my opinion, the Windiots that use windows deserve everything they get because they're too stupid, too lazy or too attached to their windows games to move to Linux.

Posted at: 21:43 | Category: Windiots | Permalink

Sat, 17 Jun 2006

The DTS File Format.

Having hacked on libsndfile for many years I have become something of an expert on sound file formats. Over that time I have also passed my eye over a large number of software projects and become rather skilled (if I say so myself) at telling the difference between well designed and engineered software and the garbage that is so common on the windows side. Time and time again, these moron windows developers jump on the first bad idea they have and then pursue if without ever thinking if there is a better way.

The latest example of this kind of garbage is the DTS file format. I haven't been able to track down much information about this abomination but I have found some example files The first two files on the site are zip files containing a single WAV file each. Or rather, these files look like WAV files. Opening these files in audio file editors like Sweep or Audacity (both of which use libsndfile for file I/O BTW) results in a waveform that looks like this:

(Sweep screenshot)

When you play this thing it just sounds like white noise. Why is that?

According to the sndfile-info program that ships with libsndfile this file is a standard 16 bit stereo WAV file recorded at 44.1 kHz. Maybe its a bug in libsndfile. So, I tried playing this using Windows Media Player. Again, nothing but noise.

Now, WAV files are simple binary files. They contain a header which specifies the sample rate, channel count and data encoding followed by the audio data. Here's a hexdump: 

  00000000: 52494646 24004904  57415645 666D7420  RIFF$.I. WAVEfmt
  00000010: 10000000 01000200  44AC0000 10B10200  ........ D.......
  00000020: 04001000 64617461  00004904 FF1F00E8  ....data ..I.....
  00000030: F107DFFC 98FC00EC  EEE40900 DEFBEFFD  ........ ........
  00000040: FFFF80FF 3F006DFF  B6EDFFF6 FFFFFFFF  ....?.m. ........
  00000050: FFFFFFFF FFFFFFFF  FFFFFFFF 00F00000  ........ ........

which libsndfile decodes as: 

  RIFF : 71893028
  WAVE
  fmt  : 16
    Format        : 0x1 => WAVE_FORMAT_PCM
    Channels      : 2
    Sample Rate   : 44100
    Block Align   : 4
    Bit Width     : 16
    Bytes/sec     : 176400
  data : 71892992

So, in its simplest form, a WAV file has four bytes "RIFF", followed by four bytes containing the file length followed by "WAVE" and then "fmt " and then some binary data which is decoded as the sample rate and channels etc, followed by "data" and then the actual audio data. The interesting thing here is the format field which tells me that this file should contain PCM audio data. There's really not much to go wrong, so why does this file sound like white noise?

Well some idiot programmer (may Satan himself gnaw on their testicles) decided that even though they have set the format field to say that this file contains PCM data, they instead decide to put some other form of data in the data section. In one foul swoop they have created a file that is incompatible with every program in the universe that understands WAV files even though those programs think they know what to do with the file.

Now any idiot with an IQ above that of a cane toad should have been able to figure out that this was a bad idea and come up with a better alternative. Like maybe they could have changed the first four bytes of the file to "DTSF", or changed the "WAVE" string of the WAV file format or any one of about 826384768723587345 other possibilities. But no, in typical windiot fashion, they grabbed the first and most stupid idea that came into their heads and went with it.

I curse them 1000 times over. I specifically wish them ill.

Posted at: 23:18 | Category: Windiots | Permalink