Hacker News Reader

Comment by combatentropy | Hacker News Reader

I've run into this error many times for a decade, always when I make a CSV file of a table whose first column is "ID".

It seems to me that Microsoft by now could have improved its tests. If the first two letters are "ID", but if "there are no valid SYLK codes after the 'ID' characters," then maybe it was never meant to be an SYLK file. If the file's suffix is .csv, then maybe you should just treat it as a CSV file. If the file's suffix is .txt, then maybe you should treat it as a text file.

View on HN

I've run into this bug too and it was mystifying and (iirc) not overridden by manually loading the file using the Text Import wizard. But this...

"If the file's suffix is .csv, then maybe you should just treat it as a CSV file"

doesn't make me any happier, because there are a lot of slight variations on CSV files or a lot of different ways you might want to load a CSV file (perhaps you'd like to specify the character set, or set columns to be text or date format, or not have leading zeroes stripped or numbers in brackets turned into negative values), and if I absentmindedly name them .csv then again I can't use the full loader, because Excel knows best.

And if you want to read a CSV file with a VB macro it's even worse, because you can specify all the parameters but it just silently overrides them all with the CSV defaults just because the file extension is CSV. Hours of debugging spent on that...

Yes, I always use .txt when exporting/importing CVS from/to Excel. Fun!

If you're a fan of this sort of thing, try the following in CMD. (It helps if you read it in the voice of a 90's rapping cartoon cat.)

echo MZ is my name my name is MZ. I'm the hippest loader bug from the sea to the sea! >foo.txt

.\foo.txt

What does this do? I don't have access to a windows machine.

For historical reasons, the MZ is interpreted as the header of a 16-bit executable. When you run something under CMD (hopefully I'm getting this right, it's been a few years) it first runs it using the CreateProcess API, which just tries to run the file as an executable, regardless of extension, then it falls back to ShellExecute if it doesn't have an MZ header, which dispatches based on extension.

Basically you get a dialog saying the text file isn't a compatible executable. If you change the MZ to anything else, it opens in notepad.

Windows 7 64 bit here - it just has the error message box, and the same text in the cmd window, it doesn't open the file though :)

"This version of foo.txt is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."

That's because it's treating it as a 16-bit DOS executable (since it has the 'MZ' magic number but not the rest of the PE header that tells Windows that it's 32 or 64-bit). 64-bit Windows can't run 16-bit executables at all.

32-bit Windows should fail a little later in the execution process; it can run 16-bit software, but your text file is missing the rest of the MZ-format header.

Well, you are trying to execute the text file (with ShellExecute as a fallback). Windows does what you ordered it to.

Alrighty, then, on Linux, just for you.

[fred@dejah launch]$ chmod +x foo.txt [fred@dejah launch]$ ./foo.txt fixme:winediag:start_process Wine Staging 1.9.12 is a testing version containing experimental patches. fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. winevdm: Cannot start DOS application E:\launch\foo.txt because the DOS memory range is unavailable. You should install DOSBox. [fred@dejah launch]$

I have Wine installed. Same defect as Windows, which is either good or bad -- this is hard to determine.

At least, the hint of installing DOSBox is reasonable. So, let's do that:

[fred@dejah launch]$ sudo dnf install dosbox

and try it again:

[fred@dejah launch]$ ./foo.txt fixme:winediag:start_process Wine Staging 1.9.12 is a testing version containing experimental patches. fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. DOSBox version 0.74 Copyright 2002-2010 DOSBox Team, published under GNU GPL. --- ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

CONFIG: Generating default configuration. Writing it to /home/fred/.dosbox/dosbox-0.74.conf CONFIG:Loading primary settings from config file /home/fred/.dosbox/dosbox-0.74.conf CONFIG:Loading additional settings from config file /home/fred/.wine/dosdevices/c:/users/fred/Temp/cfgcbaf.tmp MIXER:Can't open audio: No available audio device , running in nosound mode. ALSA:Can't subscribe to MIDI port (65:0) nor (17:0) MIDI:Opened device:none [fred@dejah launch]$

Doesn't work on 64 bit, but I seem to recall something about the first 2 bytes of a PE header. :)

I have absolutely hit this bug before, multiple times. However, I never put it together that the 'ID' was causing it.

I can think if things breaking for each of those.

Reply on news.ycombinator.com