For system apps like cmd.exe or explorer.exe, a registry key would be a better solution. That way the end user or sys admin can turn it on or off, whereas the exe manifest is fixed at build time.
"2011-10-05T14:48:00.000Z" - Excel: I have no idea what this is.
Excel: when's that?
Ctrl+A then Alt H N T E enter to make the whole spreadsheet "Text" by default instead of "General". (Or Ctrl+A Alt H N A enter to default everything to "Accounting" if you are just going to be typing in a bunch of dollar amounts, etc.)
The tools are there to "opt out" of "I'm too lazy to set a data type so guess for me" mode and always have been.
I never, EVER, want to see another number in scientific notation unless I tell it too.
We don't get data _that_ often. But when we do, there's 75% chance it's got this problem somewhere. So much so we've created stock template guides.
I'm sick of it. So sick of it.
Sure. I can go through the document one cell at a time and fix the issues. But I don't want to. It's a waste of my week.
If I could count the man hours I've wasted on this over my 10 years at this company....
I definitely appreciate both sides of the frustration: "General" exists for a lot of good reasons that people are lazy and don't want to learn how to operate the software they use every day correctly, they just want it to read their minds.
For similar, but different reasons, because it is hard to train people everyone else builds elaborate work arounds (renaming genes, coming up with silly naming conventions and separators that won't be confused with dates or numbers, always passing spreadsheets over to "that IT guy who knows how to fix it/clean it up" before doing anything critical with them, etc). It's funny how many of those workarounds become so much more work (as they get concretized into bureaucratic processes) overall than learning to hit the one big Number Format dropdown at the top of the screen sometimes.
Both problems exist because people are inherently lazy and don't want to learn how to use their tools properly, and no one is really at fault on either side ("General" has a right to exist and has existed since Visicalc; People are free to live/die by the illusion that processes are cheaper than education), but a lot of us get stuck uncomfortably in the middle both knowing the tools and being unable to get people to use them right.
No. That's definitely not it. We deal with people who know excel inside and out. They are human. They might not notice a cell on row 11593 has an issue. They might forget. It's Excel's fault for not understanding that it is software for humans.
That said, it should be theoretically possible, but I believe any approach other than hooking into high level IO call will be problematic, and you'd probably lose access to many things like serial/parallel ports etc. (as applications wouldn't know the names you renamed them under).
The big problem here is bare device names, and device names with an extension – e.g. "COM1", "COM1.TXT". Device names with a colon, e.g. "COM1:", are not such a big problem, because colon is not an allowed character in file names on Windows (it is reserved as syntax to specify a drive or stream.) And while colon is a valid character in Unix file names, it is rarely used in practice, so Windows not supporting it is less of a problem than Windows not supporting files named "aux" or "con" is. So if they still recognised the device names with a colon, that would work fine for some programs that already use the colon, and for those that don't it should be an easy fix to just add it before updating the EXE manifest to opt-in to this feature.
Actually there is another fix – in Win32 programming you are recommended to prefix device names with "\\.\" anyway. That is actually mandatory when dealing with more than 9 serial ports (e.g there are multiport serial cards with more than 10 ports, or you might have two 8-port serial cards in your system). If you want to access COM10, you have to prefix it with "\\.\". And it is best practice to use those prefixes even with COM1-9. So programs already following that best practice would need no change. (And few programs directly use serial or parallel ports nowadays anyway.)
We ran into this recently when a bug in Ardour ended up creating files on disk named like "recorder:N". They were created correctly on the disk, and in the Ardour instance that had created them and thus had file handles for them, they could be read without issues. But ... close the program and restart it ... errors about not being able to find the files.
Fortunately, Notepad (I think) is one of the few applications that can handle these names (I have no idea why), and so it could be used to open and save the files under a "better" name.
ps. after 35 years in computing, I have not used Windows for more than 30 minutes in total. This account is based on being a developer of a cross-platform application who reads bug reports and interacts with users.
I think you are getting confused by stream names. If you try to create a file called "foo1.txt:bar", some Windows tools let you. But that is not an example of a file name containing a colon. The filename is "foo1.txt". In Windows NT (and its successors), a file can be composed of multiple named streams, and ":" separates the file name from the stream name. So "foo1.txt:bar" is actually the the stream named "bar" of the file named "foo1.txt", not a file named "foo1.txt:bar"
So let me rephrase. An application can attempt to create a file using the name "foo:bar" and this will result in a new entity in the filesystem that can sometimes be successfully accessed using the name "foo:bar", but generally not.
That is seen even in some programs shipped with Windows. For example, cmd.exe. Some of the built-in commands in cmd.exe, for example "del", "type" and "copy", refuse to work with file streams. But that's because cmd.exe's code is detecting the colon and rejecting it as bad filename syntax. If Microsoft would just comment that validation code out, and pass the name including the colon down to the core Windows APIs, those commands would work. But that said, other parts of the cmd.exe code can handle them. The "dir" built-in command even has an option to display file streams, "dir /r". You can also read/write streams using redirection in cmd.exe, e.g. "echo foo > bar:baz" will write the string "foo" to the file stream "bar:baz". And "more < bar:baz" can be used as a workaround for the fact that "type bar:baz" doesn't work. Even though "copy" doesn't understand streams, "copy foo bar" will copy "foo" with its streams intact (assuming both target and destination are on filesystems that support streams), since even though "copy" doesn't understand streams the underlying Windows file copy API it calls does.
Microsoft is unlikely to fix the limitations in cmd.exe since cmd.exe is now considered a legacy component. New features all go in PowerShell. And PowerShell has much better support for streams, it can do everything with them.
So the "generally not" really depends on which applications you are using.
(Well, strictly speaking you might argue it could be the default unnamed data stream of a file called "COM1". But almost nobody ever refers to the unnamed data stream explicitly like that, just using the bare file name to do so; and if one must, the canonical name for it is to include the stream type, giving the default unnamed stream of the file "COM1" a name of "COM1::$DATA". That's obviously not a reference to the "COM1" device, since it violates the "path name must be blank" rule)
I'd be more interesting on how the "ignore extension" part happened. Wouldn't be surprised to find some ancient option support there...
DOS required extensions and most early DOS apps just always appended their own extensions automatically and only took in the base name. The system ignoring the file extension made it easier to use the devices in every DOS app, not just ones aware of the devices.
I don't have time to do any detailed testing of this right now, but I believe that `CreateFileA("COM1",...)` and `CreateFileA("COM1:",...)` are equivalent, and both work identically. Am I wrong about that?
I wonder if they should only exist for command line apps although I wonder if there aren't still GUI apps that control industrial machinery by opening "COM1" as a file.
You can even demonstrate this with cmd.exe (which uses the Win32 API, it doesn't directly access the NT API)
`mkdir c:\con` will not work, says `The directory name is invalid.`
`mkdir \\?\c:\con` does work. But then to delete you have to use the \\?\ prefix again. And `cd \\?\c:\con\` doesn't work, you get the `CMD does not support UNC paths as current directories` error. (Win32 does, this is a cmd.exe limitation only)
My proposal was to have a way of getting the `\\?\` behaviour without having to explicitly provide that prefix.
Actually, not quite. There is one aspect of `\\?\` which is undesirable. The NT API only supports backslash as a directory separator. The Win32 API supports forward slash as well, it automatically converts forward slash to backslash. But `\\?\` turns that conversion off. I think you'd still want the forward to backslash conversion on, to maximise compatibility with Unix.
The less obvious part is that for a very long time, it has been a contract for all Win32 functions that return PATHs, that the maximum size of the returned path is MAX_PATH. So there are a lot of apps that basically allocate a buffer of that size and assume that it'll always be enough. So functions like GetFullPathName can't just start returning longer names, because it would break those apps. Instead, they rely on the presence of "\\?\" prefix in the input path as an indicator that the calling app understands those longer paths, and is ready to accept them as outputs as well.
You are talking about (1), and I agree it has some problems, yet Microsoft already has an EXE manifest option to bypass maximum path length without \\?\.
Whereas, I am proposing (2), which could exist without (1). They could add an EXE manifest option and/or registry key to tell the Win32 API to ignore bare device names, or device names with extensions, when converting Win32-to-NT paths, even while keeping the MAX_PATH limitation. So you wouldn't need \\?\ to access a file/directory with a reserved device name. But you might still need it to access a long path. The two issues are orthogonal and could be controlled by different settings.
WIN32_FIND_DATA only returns a file name, not a full path, and the "\\?\" prefix does not remove any limits for individual path components.
If anybody knows of anyone using those special files in programs running on modern Windows, I'd love to hear about it.