6 ms·

If you use UNC paths, it already happens. The issue is dealing with software that won't give absolute UNC (NT-native) path to an API. That said, it should be t

by p_l 5y ago

If you use UNC paths, it already happens. The issue is dealing with software that won't give absolute UNC (NT-native) path to an API. 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).

skissane 5y ago
> 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.)
- PaulDavisThe1st 5y ago
  Actually, colon (:) is allowed as part of a Windows file name. This changed at some point (presumably NT). However, almost all Windows tools will be incapable of dealing with a file name that includes a colon, even though the file exists on disk. 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.
  - skissane 5y ago
    > Actually, colon (:) is allowed as part of a Windows file name. This changed at some point (presumably NT). However, almost all Windows tools will be incapable of dealing with a file name that includes a colon, even though the file exists on disk. 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"
    - PaulDavisThe1st 5y ago
      Thanks for the clarification. 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.
      - skissane 5y ago
        The core Windows APIs don't have any problem with accessing the file stream "foo:bar". It is just some applications which apply their own file name validation and reject it before passing it to the underlying APIs. 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.
- p_l 5y ago
  The thing is, colon is NOT part of device name. It just separates device name from path, and is arguably the part of the mess that is derived from CP/M
  - skissane 5y ago
    Yes, it isn't strictly part of the device name, it is a separator. But it still works well for distinguishing device names from file names. For a character device, the path name has to be blank. "COM1:" is definitely a device not a file, as long as colons are not allowed in filenames. (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)
    - p_l 5y ago
      Unfortunately the API was that you used CreateFile without colon. I'd be more interesting on how the "ignore extension" part happened. Wouldn't be surprised to find some ancient option support there...
      - WorldMaker 5y ago
        Raymond Chen answers that: https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42073 https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42... 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.
      - skissane 5y ago
        > Unfortunately the API was that you used CreateFile without colon. 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?

by p_l 5y ago

skissane 5y ago

> 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.)

PaulDavisThe1st 5y ago
Actually, colon (:) is allowed as part of a Windows file name. This changed at some point (presumably NT). However, almost all Windows tools will be incapable of dealing with a file name that includes a colon, even though the file exists on disk. 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.
- skissane 5y ago
  > Actually, colon (:) is allowed as part of a Windows file name. This changed at some point (presumably NT). However, almost all Windows tools will be incapable of dealing with a file name that includes a colon, even though the file exists on disk. 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"
  - PaulDavisThe1st 5y ago
    Thanks for the clarification. 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.
    - skissane 5y ago
      The core Windows APIs don't have any problem with accessing the file stream "foo:bar". It is just some applications which apply their own file name validation and reject it before passing it to the underlying APIs. 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.
p_l 5y ago
The thing is, colon is NOT part of device name. It just separates device name from path, and is arguably the part of the mess that is derived from CP/M
- skissane 5y ago
  Yes, it isn't strictly part of the device name, it is a separator. But it still works well for distinguishing device names from file names. For a character device, the path name has to be blank. "COM1:" is definitely a device not a file, as long as colons are not allowed in filenames. (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)
  - p_l 5y ago
    Unfortunately the API was that you used CreateFile without colon. I'd be more interesting on how the "ignore extension" part happened. Wouldn't be surprised to find some ancient option support there...
    - WorldMaker 5y ago
      Raymond Chen answers that: https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42073 https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42... 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.
    - skissane 5y ago
      > Unfortunately the API was that you used CreateFile without colon. 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?