Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #120928 > unrolled thread
| Started by | wij <wyniijj5@gmail.com> |
|---|---|
| First post | 2024-11-20 11:02 +0800 |
| Last post | 2025-02-15 16:21 -0800 |
| Articles | 20 on this page of 92 — 19 participants |
Back to article view | Back to comp.lang.c++
Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 11:02 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-20 09:22 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 08:27 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:47 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 15:05 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 15:45 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 16:41 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 13:37 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 22:11 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 14:33 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 23:03 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:57 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:58 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:43 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-21 16:07 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 17:55 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-22 09:30 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-22 11:10 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@dastardlyhq.com - 2024-11-23 11:36 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:26 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-22 12:49 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-22 23:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-23 13:07 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 13:55 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 20:57 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-22 09:55 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:21 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:57 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:31 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:36 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 16:53 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-24 12:57 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:03 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-26 12:21 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 16:23 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-27 08:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 18:48 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 15:39 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:54 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 17:24 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 16:12 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-27 13:00 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:23 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:06 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 08:08 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:58 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 19:46 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:03 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 12:15 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:36 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 14:12 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 07:50 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:19 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:12 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 17:36 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-28 16:43 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:59 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-28 10:19 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 22:41 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 00:21 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-29 00:59 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 01:20 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-28 17:18 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 19:01 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:22 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 11:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:57 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:54 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:27 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 15:30 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 18:32 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-25 14:15 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 21:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:26 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:20 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-20 17:32 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? red floyd <no.spam.here@its.invalid> - 2024-11-20 22:56 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:51 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:44 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 22:57 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-20 17:23 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:09 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-21 22:45 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-25 22:20 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-11-26 10:20 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-30 16:52 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Andrey Tarasevich <noone@noone.net> - 2025-02-15 16:21 -0800
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2024-11-27 16:12 +0000 |
| Message-ID | <vi7gdo$2t76$1@dont-email.me> |
| In reply to | #121036 |
On Wed, 27 Nov 2024 17:24:05 +0200 Michael S <already5chosen@yahoo.com> wibbled: >On Wed, 27 Nov 2024 13:54:04 -0000 (UTC) >Muttley@DastardlyHQ.org wrote: > >> On Wed, 27 Nov 2024 15:39:51 +0200 >> Paavo Helde <eesnimi@osa.pri.ee> wibbled: >> >On 27.11.2024 12:48, wij wrote: >> >> >> >> A clue for you: What should be in a 'portabe' program if >> >> ::fopen(..) failed? >> >NULL >> >> or nullptr? What about "if(::fopen(..)"? >> > >> >In a portable program one cannot just use fopen() as it does not >> >work reliably with Unicode characters in Windows paths. One needs to >> >use some kind of helper library for having portable code. In >> >principle std::filesystem::path ought to work, but I have no >> >experience with it. >> >> So how does file access work in plain C in Windows then? I'm pretty >> sure fopen() works fine given its a core C API function. >> > >It works, but badly rather than fine. >Specifically, it works only with ASCII paths. Which, on Windows, happen >to be 2nd class. The biggest problem with ASCII paths on Windows is How can ascii paths be 2nd class (whatever that means) given that ascii is a subset of utf-8?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-11-27 13:00 -0500 |
| Message-ID | <4b500554db95b2ace413fdaddbdda2459e9f6e7a@i2pn2.org> |
| In reply to | #121038 |
On 11/27/24 11:12 AM, Muttley@DastardlyHQ.org wrote: > On Wed, 27 Nov 2024 17:24:05 +0200 > Michael S <already5chosen@yahoo.com> wibbled: >> On Wed, 27 Nov 2024 13:54:04 -0000 (UTC) >> Muttley@DastardlyHQ.org wrote: >> >>> On Wed, 27 Nov 2024 15:39:51 +0200 >>> Paavo Helde <eesnimi@osa.pri.ee> wibbled: >>>> On 27.11.2024 12:48, wij wrote: >>>>> >>>>> A clue for you: What should be in a 'portabe' program if >>>>> ::fopen(..) failed? >>>> NULL >>>>> or nullptr? What about "if(::fopen(..)"? >>>> >>>> In a portable program one cannot just use fopen() as it does not >>>> work reliably with Unicode characters in Windows paths. One needs to >>>> use some kind of helper library for having portable code. In >>>> principle std::filesystem::path ought to work, but I have no >>>> experience with it. >>> >>> So how does file access work in plain C in Windows then? I'm pretty >>> sure fopen() works fine given its a core C API function. >>> >> >> It works, but badly rather than fine. >> Specifically, it works only with ASCII paths. Which, on Windows, happen >> to be 2nd class. The biggest problem with ASCII paths on Windows is > > How can ascii paths be 2nd class (whatever that means) given that ascii > is a subset of utf-8? > > Because the windows file system is based on UTF-16 file names? The UTF-8 interface is just more limited.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2024-11-28 08:23 +0000 |
| Message-ID | <vi99aq$faie$1@dont-email.me> |
| In reply to | #121040 |
On Wed, 27 Nov 2024 13:00:17 -0500 Richard Damon <richard@damon-family.org> wibbled: >On 11/27/24 11:12 AM, Muttley@DastardlyHQ.org wrote: >> How can ascii paths be 2nd class (whatever that means) given that ascii >> is a subset of utf-8? >> >> > >Because the windows file system is based on UTF-16 file names? Oh. Its always nice to have yet more reasons never to go near Windows development again.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-28 15:06 +0200 |
| Message-ID | <20241128150601.000038b8@yahoo.com> |
| In reply to | #121040 |
On Wed, 27 Nov 2024 13:00:17 -0500 Richard Damon <richard@damon-family.org> wrote: > On 11/27/24 11:12 AM, Muttley@DastardlyHQ.org wrote: > > On Wed, 27 Nov 2024 17:24:05 +0200 > > Michael S <already5chosen@yahoo.com> wibbled: > >> On Wed, 27 Nov 2024 13:54:04 -0000 (UTC) > >> Muttley@DastardlyHQ.org wrote: > >> > >>> On Wed, 27 Nov 2024 15:39:51 +0200 > >>> Paavo Helde <eesnimi@osa.pri.ee> wibbled: > >>>> On 27.11.2024 12:48, wij wrote: > >>>>> > >>>>> A clue for you: What should be in a 'portabe' program if > >>>>> ::fopen(..) failed? > >>>> NULL > >>>>> or nullptr? What about "if(::fopen(..)"? > >>>> > >>>> In a portable program one cannot just use fopen() as it does not > >>>> work reliably with Unicode characters in Windows paths. One > >>>> needs to use some kind of helper library for having portable > >>>> code. In principle std::filesystem::path ought to work, but I > >>>> have no experience with it. > >>> > >>> So how does file access work in plain C in Windows then? I'm > >>> pretty sure fopen() works fine given its a core C API function. > >>> > >> > >> It works, but badly rather than fine. > >> Specifically, it works only with ASCII paths. Which, on Windows, > >> happen to be 2nd class. The biggest problem with ASCII paths on > >> Windows is > > > > How can ascii paths be 2nd class (whatever that means) given that > > ascii is a subset of utf-8? > > > > > > Because the windows file system is based on UTF-16 file names? > > The UTF-8 interface is just more limited. Actually, I can not think about good reason for 260-char limit of maximal path length in ASCII variant of Windows files APIs. It's probably somehow related to compatibility with Wn16, but I don't see how exactly. I am also not sure that [for names started with "\\?\" prefix] the limit still present in the newer editions of the OS. Up to date docs are less clear about it than the older docs that I seems to recollect. Most of the docs are written as if longer paths should work in ASCII. But in one place there is the following line "Note that Unicode APIs should be used to make sure the "\\?\" prefix allows you to exceed the MAX_PATH." https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file This line seems to contradict the following page: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea Unfortunately, right now I have no time for deeper investigation.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-11-28 08:08 -0500 |
| Message-ID | <8176b490f7b423eafa5701da2abeda8c07e022d4@i2pn2.org> |
| In reply to | #121053 |
On 11/28/24 8:06 AM, Michael S wrote: > On Wed, 27 Nov 2024 13:00:17 -0500 > Richard Damon <richard@damon-family.org> wrote: > >> On 11/27/24 11:12 AM, Muttley@DastardlyHQ.org wrote: >>> On Wed, 27 Nov 2024 17:24:05 +0200 >>> Michael S <already5chosen@yahoo.com> wibbled: >>>> On Wed, 27 Nov 2024 13:54:04 -0000 (UTC) >>>> Muttley@DastardlyHQ.org wrote: >>>> >>>>> On Wed, 27 Nov 2024 15:39:51 +0200 >>>>> Paavo Helde <eesnimi@osa.pri.ee> wibbled: >>>>>> On 27.11.2024 12:48, wij wrote: >>>>>>> >>>>>>> A clue for you: What should be in a 'portabe' program if >>>>>>> ::fopen(..) failed? >>>>>> NULL >>>>>>> or nullptr? What about "if(::fopen(..)"? >>>>>> >>>>>> In a portable program one cannot just use fopen() as it does not >>>>>> work reliably with Unicode characters in Windows paths. One >>>>>> needs to use some kind of helper library for having portable >>>>>> code. In principle std::filesystem::path ought to work, but I >>>>>> have no experience with it. >>>>> >>>>> So how does file access work in plain C in Windows then? I'm >>>>> pretty sure fopen() works fine given its a core C API function. >>>>> >>>> >>>> It works, but badly rather than fine. >>>> Specifically, it works only with ASCII paths. Which, on Windows, >>>> happen to be 2nd class. The biggest problem with ASCII paths on >>>> Windows is >>> >>> How can ascii paths be 2nd class (whatever that means) given that >>> ascii is a subset of utf-8? >>> >>> >> >> Because the windows file system is based on UTF-16 file names? >> >> The UTF-8 interface is just more limited. > > Actually, I can not think about good reason for 260-char limit of > maximal path length in ASCII variant of Windows files APIs. > It's probably somehow related to compatibility with Wn16, but I don't > see how exactly. > > I am also not sure that [for names started with "\\?\" prefix] the > limit still present in the newer editions of the OS. Up to date docs > are less clear about it than the older docs that I seems to recollect. > Most of the docs are written as if longer paths should work in ASCII. > But in one place there is the following line "Note that Unicode APIs > should be used to make sure the "\\?\" prefix allows you to exceed the > MAX_PATH." > https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file > > This line seems to contradict the following page: > https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea > > Unfortunately, right now I have no time for deeper investigation. > My guess is that at some point the code needs to convert the 8 bit character encoding into the 16 character encoding that the actual file system uses, and that uses fixed length buffers.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-11-27 14:58 -0500 |
| Message-ID | <vi7tkq$4ur3$3@dont-email.me> |
| In reply to | #121038 |
On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: > On Wed, 27 Nov 2024 17:24:05 +0200 > Michael S <already5chosen@yahoo.com> wibbled: ... >> It works, but badly rather than fine. >> Specifically, it works only with ASCII paths. Which, on Windows, happen >> to be 2nd class. The biggest problem with ASCII paths on Windows is > > How can ascii paths be 2nd class (whatever that means) given that ascii > is a subset of utf-8? Because ascii is a subset of utf-8, any path name that contains a character not in that subset cannot be represented, which is what makes them 2nd class.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-27 19:46 -0800 |
| Message-ID | <V_acncrrkpw8etr6nZ2dnZfqnPWdnZ2d@giganews.com> |
| In reply to | #121044 |
On 11/27/2024 11:58 AM, James Kuyper wrote: > On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: >> On Wed, 27 Nov 2024 17:24:05 +0200 >> Michael S <already5chosen@yahoo.com> wibbled: > ... >>> It works, but badly rather than fine. >>> Specifically, it works only with ASCII paths. Which, on Windows, happen >>> to be 2nd class. The biggest problem with ASCII paths on Windows is >> >> How can ascii paths be 2nd class (whatever that means) given that ascii >> is a subset of utf-8? > > Because ascii is a subset of utf-8, any path name that contains a > character not in that subset cannot be represented, which is what makes > them 2nd class. > > Of course there are structured path names that encode upper-plane characters in ASCII in Windows UNC file paths, yet it's sort of like the various approaches to escapes and encoding in e-mail what's usually enough Unicode but could be any code-page with regards to its glyph-map usually, yet that most escape schemes don't also include directives with regards to original form, or that encoding and decoding character data among codepages and encodings isn't necessarily round-trip or idempotent. I.e. "cannot be represented without using the rather heavyweight encoding schemes they have themselves, 'first-class'", where "first-class" merely means "on the order of the first order" and anything else just is not, that it merely means "equi-interpretable" in the model of it, "isomorphic" as it were, that a "first-class" concept has its own type, while "first-class" in coverage of specification or feature just means "in parity", with whatever else is considered "first-class". If you think about something like ICU/ICU4J, and all the codepages in Windows, and all the all the codepages historically, and all the codepages, then if you've ever looked at those with regards to parity among each other and to Unicode, which of course is great, that Unicode 1, 2, 3, 4 are pretty great, most people find it simplified when "utf-8 everywhere". Then it's "a no-op" any usual concern, except there's often enough byte length versus character length or BLEN and CLEN, "utf-8 everywhere", whether it's not so much "first-class" as "bog-standard".
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2024-11-28 08:26 +0000 |
| Message-ID | <vi99eq$fb2o$1@dont-email.me> |
| In reply to | #121044 |
On Wed, 27 Nov 2024 14:58:18 -0500 James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: >> On Wed, 27 Nov 2024 17:24:05 +0200 >> Michael S <already5chosen@yahoo.com> wibbled: >.... >>> It works, but badly rather than fine. >>> Specifically, it works only with ASCII paths. Which, on Windows, happen >>> to be 2nd class. The biggest problem with ASCII paths on Windows is >> >> How can ascii paths be 2nd class (whatever that means) given that ascii >> is a subset of utf-8? > >Because ascii is a subset of utf-8, any path name that contains a >character not in that subset cannot be represented, which is what makes >them 2nd class. Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd class. The only issue comes when some idiot tries to mix utf-8 with 8 bit ascii code pages.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-11-28 13:03 +0200 |
| Message-ID | <vi9ilo$givc$1@dont-email.me> |
| In reply to | #121048 |
On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: > On Wed, 27 Nov 2024 14:58:18 -0500 > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: >>> On Wed, 27 Nov 2024 17:24:05 +0200 >>> Michael S <already5chosen@yahoo.com> wibbled: >> .... >>>> It works, but badly rather than fine. >>>> Specifically, it works only with ASCII paths. Which, on Windows, happen >>>> to be 2nd class. The biggest problem with ASCII paths on Windows is >>> >>> How can ascii paths be 2nd class (whatever that means) given that ascii >>> is a subset of utf-8? >> >> Because ascii is a subset of utf-8, any path name that contains a >> character not in that subset cannot be represented, which is what makes >> them 2nd class. > > Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd class. > The only issue comes when some idiot tries to mix utf-8 with 8 bit ascii > code pages. You are right, ASCII is not 2nd class because it is part of UTF-8. It is 2nd class on Windows because MS have historically decided to not support UTF-8 properly on Windows, in an attempt of a futile vendor lock-in. Though this is changing now, I just ran a quick test and apparently calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string fopen() and they work properly. So there is progress!
[toc] | [prev] | [next] | [standalone]
| From | Ralf Fassel <ralfixx@gmx.de> |
|---|---|
| Date | 2024-11-28 12:15 +0100 |
| Message-ID | <ygar06vwqwm.fsf@akutech.de> |
| In reply to | #121049 |
* Paavo Helde <eesnimi@osa.pri.ee> | On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: | > On Wed, 27 Nov 2024 14:58:18 -0500 | > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: | >> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: | >>> On Wed, 27 Nov 2024 17:24:05 +0200 | >>> Michael S <already5chosen@yahoo.com> wibbled: | >> .... | >>>> It works, but badly rather than fine. | >>>> Specifically, it works only with ASCII paths. Which, on Windows, happen | >>>> to be 2nd class. The biggest problem with ASCII paths on Windows is --<snip-snip>-- > | Though this is changing now, I just ran a quick test and apparently | calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with | VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string | fopen() and they work properly. So there is progress! Does fopen() also work with filenames where the UTF-8 is not part of your et_EE.UTF-8 codepage (e.g. filenames containing japanese characters)? I think that with these only the _wfopen() will work... R'
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-11-28 13:36 +0200 |
| Message-ID | <vi9kk4$givc$2@dont-email.me> |
| In reply to | #121050 |
On 28.11.2024 13:15, Ralf Fassel wrote:
> * Paavo Helde <eesnimi@osa.pri.ee>
> | On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote:
> | > On Wed, 27 Nov 2024 14:58:18 -0500
> | > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
> | >> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote:
> | >>> On Wed, 27 Nov 2024 17:24:05 +0200
> | >>> Michael S <already5chosen@yahoo.com> wibbled:
> | >> ....
> | >>>> It works, but badly rather than fine.
> | >>>> Specifically, it works only with ASCII paths. Which, on Windows, happen
> | >>>> to be 2nd class. The biggest problem with ASCII paths on Windows is
> --<snip-snip>--
>>
> | Though this is changing now, I just ran a quick test and apparently
> | calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with
> | VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string
> | fopen() and they work properly. So there is progress!
>
> Does fopen() also work with filenames where the UTF-8 is not part of
> your et_EE.UTF-8 codepage (e.g. filenames containing japanese
> characters)? I think that with these only the _wfopen() will work...
Any UTF-8 locale should support all UTF-8 characters, so it should not
matter what I write before that. But I can test the Japanese characters
easily, this is an example testing "CJK Unified Ideograph-6F22"
(https://www.compart.com/en/unicode/U+6F22).
#define _CRT_SECURE_NO_WARNINGS
#include <iostream>
#include <string>
int main() {
char* loc = setlocale(LC_ALL, "et_EE.UTF-8");
if (!loc) {
std::cerr << "Failed to set locale" << std::endl;
}
std::string filename = "C:\\Tmp\\Japan\xE6\xBC\xA2.txt";
if (FILE* f = ::fopen(filename.c_str(), "w")) {
std::cout << "File opened" << std::endl;
fprintf(f, "This is file: %s\n", filename.c_str());
::fclose(f);
} else {
std::cerr << "Failed to open file" << std::endl;
}
}
The file is created fine, what I see in File Explorer: Japan漢.txt
The content of the file is OK as well, but this is less surprising.
[toc] | [prev] | [next] | [standalone]
| From | Ralf Fassel <ralfixx@gmx.de> |
|---|---|
| Date | 2024-11-28 14:12 +0100 |
| Message-ID | <ygamshjwlhq.fsf@akutech.de> |
| In reply to | #121051 |
* Paavo Helde <eesnimi@osa.pri.ee>
| Any UTF-8 locale should support all UTF-8 characters, so it should not
| matter what I write before that. But I can test the Japanese
| characters
| easily, this is an example testing "CJK Unified Ideograph-6F22"
| (https://www.compart.com/en/unicode/U+6F22).
>
| #define _CRT_SECURE_NO_WARNINGS
| #include <iostream>
| #include <string>
| int main() {
| char* loc = setlocale(LC_ALL, "et_EE.UTF-8");
| if (!loc) {
| std::cerr << "Failed to set locale" << std::endl;
| }
| std::string filename = "C:\\Tmp\\Japan\xE6\xBC\xA2.txt";
| if (FILE* f = ::fopen(filename.c_str(), "w")) {
| std::cout << "File opened" << std::endl;
| fprintf(f, "This is file: %s\n", filename.c_str());
| ::fclose(f);
| } else {
| std::cerr << "Failed to open file" << std::endl;
| }
| }
>
| The file is created fine, what I see in File Explorer: Japan漢.txt
>
| The content of the file is OK as well, but this is less surprising.
Great, thanks for the clarification (though of course waaaay off-topic
in the meantime :-)!
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170
section "UTF-8 support" also confirms it:
After calling setlocale(LC_ALL, ".UTF8"), you may pass "😊" to
mbtowcs and it will be properly translated to a wchar_t
string. Previously, there wasn't a locale setting available to do
this translation.
Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C
Runtime supports using a UTF-8 code page. The change means that char
strings passed to C runtime functions can expect strings in the
UTF-8 encoding.
--<snip-snip>--
UTF-8 mode is also enabled for functions that have historically
translated char strings using the default Windows ANSI code page
(ACP). For example, calling _mkdir("😊") while using a UTF-8 code
page will correctly produce a directory with that emoji as the
folder name, instead of requiring the ACP to be changed to UTF-8
before running your program.
The other end of the problem is how these filenames enter your program
through main(int argc, char *argv[]). If you start in a regular cmd.exe
with a regular windows code page (no utf-8 magic), you get "Japan?.txt"
for the above file name. Only in _wmain(int argc, wchar_t *argv[]) you
get the correct filename. Haven't played with chcp 65001 (=utf-8) yet...
R'
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-11-28 07:50 -0500 |
| Message-ID | <729c8f84178b5eaa0f18cea6b18f3b1fd673f937@i2pn2.org> |
| In reply to | #121049 |
On 11/28/24 6:03 AM, Paavo Helde wrote: > On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: >> On Wed, 27 Nov 2024 14:58:18 -0500 >> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >>> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: >>>> On Wed, 27 Nov 2024 17:24:05 +0200 >>>> Michael S <already5chosen@yahoo.com> wibbled: >>> .... >>>>> It works, but badly rather than fine. >>>>> Specifically, it works only with ASCII paths. Which, on Windows, >>>>> happen >>>>> to be 2nd class. The biggest problem with ASCII paths on Windows is >>>> >>>> How can ascii paths be 2nd class (whatever that means) given that ascii >>>> is a subset of utf-8? >>> >>> Because ascii is a subset of utf-8, any path name that contains a >>> character not in that subset cannot be represented, which is what makes >>> them 2nd class. >> >> Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd class. >> The only issue comes when some idiot tries to mix utf-8 with 8 bit ascii >> code pages. > > You are right, ASCII is not 2nd class because it is part of UTF-8. It is > 2nd class on Windows because MS have historically decided to not support > UTF-8 properly on Windows, in an attempt of a futile vendor lock-in. > > Though this is changing now, I just ran a quick test and apparently > calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with VS2022 > on Windows 10 and I can pass UTF-8 filenames to narrow-string fopen() > and they work properly. So there is progress! > > To be fair to Microsoft, what happened was less devious, they decided that the answer to global operation was to just store filename in the universal coding of the time, UCS-2, which was supposed to handle every character in the world. The problem with being an early adopter of that standard, was that the Unicode Consortium realized there weren't enough code points in UCS-2, so Unicode expanded to more bits, 21 being what could be simply encoded into UTF-16, what UCS-2 would morph into.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-28 15:19 +0200 |
| Message-ID | <20241128151943.000035ec@yahoo.com> |
| In reply to | #121049 |
On Thu, 28 Nov 2024 13:03:20 +0200 Paavo Helde <eesnimi@osa.pri.ee> wrote: > On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: > > On Wed, 27 Nov 2024 14:58:18 -0500 > > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: > >> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: > >>> On Wed, 27 Nov 2024 17:24:05 +0200 > >>> Michael S <already5chosen@yahoo.com> wibbled: > >> .... > >>>> It works, but badly rather than fine. > >>>> Specifically, it works only with ASCII paths. Which, on Windows, > >>>> happen to be 2nd class. The biggest problem with ASCII paths on > >>>> Windows is > >>> > >>> How can ascii paths be 2nd class (whatever that means) given that > >>> ascii is a subset of utf-8? > >> > >> Because ascii is a subset of utf-8, any path name that contains a > >> character not in that subset cannot be represented, which is what > >> makes them 2nd class. > > > > Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd > > class. The only issue comes when some idiot tries to mix utf-8 with > > 8 bit ascii code pages. > > You are right, ASCII is not 2nd class because it is part of UTF-8. It > is 2nd class on Windows because MS have historically decided to not > support UTF-8 properly on Windows, in an attempt of a futile vendor > lock-in. > Not sure that it was about lock in. At time Win32 was conceived, UTF8 didn't exist. At time WinNt was shipped, it still was less than a year old. Back then choosing UTF16 looked reasonable. Up to ~15 years ago it was not clear that UTF8 not just won, but won decisively, so siting on the fence, waiting for the outcome of the battle and rooting for legacy was not totally unreasonable. For what happened after that, you could not underestimated a factor of laziness. > Though this is changing now, I just ran a quick test and apparently > calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with > VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string > fopen() and they work properly. So there is progress! > Can you try it with paths that are longer than 260 characters? Both prefixed with "\\?\" and non-prefixed?
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2024-11-28 15:12 +0000 |
| Message-ID | <via19i$j9on$1@dont-email.me> |
| In reply to | #121056 |
On Thu, 28 Nov 2024 15:19:43 +0200 Michael S <already5chosen@yahoo.com> wibbled: >Not sure that it was about lock in. At time Win32 was conceived, UTF8 >didn't exist. At time WinNt was shipped, it still was less than a >year old. Back then choosing UTF16 looked reasonable. >Up to ~15 years ago it was not clear that UTF8 not just won, but won >decisively, so siting on the fence, waiting for the outcome of the >battle and rooting for legacy was not totally unreasonable. For what >happened after that, you could not underestimated a factor of laziness. > >> Though this is changing now, I just ran a quick test and apparently >> calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with >> VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string >> fopen() and they work properly. So there is progress! >> > >Can you try it with paths that are longer than 260 characters? Both >prefixed with "\\?\" and non-prefixed? Of course if MS had simply treated filenames as a sequence of 8 bit bytes regardless of what they did or didn't encode - as per *nix - then all this nonsense could have been avoided. It would simply have been left to the "dir" command or Explorer to decode it appropriately.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-28 17:36 +0200 |
| Message-ID | <20241128173629.00007eba@yahoo.com> |
| In reply to | #121058 |
On Thu, 28 Nov 2024 15:12:50 -0000 (UTC) Muttley@DastardlyHQ.org wrote: > > Of course if MS had simply treated filenames as a sequence of 8 bit > bytes regardless of what they did or didn't encode - as per *nix - > then all this nonsense could have been avoided. It would simply have > been left to the "dir" command or Explorer to decode it appropriately. > It's not that simple. The OS still has to properly recognize backslash as a directory separators. In case of Windows, colon also has a special meaning. And in most APIs backslash can be substituted by forward slash. So, counting '\0' as well, you have at least four special characters dependent on encoding. May be, there are more, that I don't remember. Simplicity of handling of file names in Unices is greatly helped by UTF-8 encoding they had chosen. They were lucky being late adapters of the Unicode. OTOH, UTF-8 didn't exist yet when most of Win32 definitions took place (supposedly 1990-1991). Of course none of the said above justifies MS's hard limiting of ASCII file paths to 260 characters. That is, if limits are still there. May be, they are lifted when I didn't pay attention.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-11-28 16:43 +0100 |
| Message-ID | <via324$je18$1@dont-email.me> |
| In reply to | #121058 |
On 28/11/2024 16:12, Muttley@DastardlyHQ.org wrote: > On Thu, 28 Nov 2024 15:19:43 +0200 > Michael S <already5chosen@yahoo.com> wibbled: >> Not sure that it was about lock in. At time Win32 was conceived, UTF8 >> didn't exist. At time WinNt was shipped, it still was less than a >> year old. Back then choosing UTF16 looked reasonable. >> Up to ~15 years ago it was not clear that UTF8 not just won, but won >> decisively, so siting on the fence, waiting for the outcome of the >> battle and rooting for legacy was not totally unreasonable. For what >> happened after that, you could not underestimated a factor of laziness. >> >>> Though this is changing now, I just ran a quick test and apparently >>> calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with >>> VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string >>> fopen() and they work properly. So there is progress! >>> >> >> Can you try it with paths that are longer than 260 characters? Both >> prefixed with "\\?\" and non-prefixed? > > Of course if MS had simply treated filenames as a sequence of 8 bit bytes > regardless of what they did or didn't encode - as per *nix - then all this > nonsense could have been avoided. It would simply have been left to the > "dir" command or Explorer to decode it appropriately. > Sure. But they were hindered by backwards compatibility, going back to early MSDOS days. Early Unix made the decision that it was not going to care about filenames, except for a NUL character terminator and the forward slash character. Special files (devices, pipes, etc.) would be indicated by information stored in the file system. Different filesystems could be mounted all within the same root system. Early MSDOS made the decision that a filesystem was for storing files and directories, and device drivers would be something different. Different filesystems would have drive letters. This made the filesystems noticeably simpler, made it clear to users when files were on diskettes, harddrives, network drivers, etc. To help compatibility and porting, they made a few specific device drivers available via specially named files, which were handled as exceptions in the file handling systems. All this was perfectly reasonable for a small single-user single-tasking OS on limited hardware, and more efficient on the PC than the Unix system would have been. Fast-forward to today, and it's easy to see that the Unix philosophy here turned out to be far better for the hardware we have now. But MS's decisions were not bad choices at the time they were made. Just like the use of UCS2, it was not about lock-in or incompetence, it was a failure to think far enough ahead while being hindered by backwards compatibility.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2024-11-28 15:59 +0000 |
| Message-ID | <via407$jogt$1@dont-email.me> |
| In reply to | #121060 |
On Thu, 28 Nov 2024 16:43:00 +0100 David Brown <david.brown@hesbynett.no> wibbled: >On 28/11/2024 16:12, Muttley@DastardlyHQ.org wrote: >handling systems. All this was perfectly reasonable for a small >single-user single-tasking OS on limited hardware, and more efficient on >the PC than the Unix system would have been. Sure, no argument there, but once NTFS came along they should really have sorted things out. There could have been a backwards compat mode in order to present a single rooted file system as a multi rooted one for older apps and convert filenames etc.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-28 10:19 -0800 |
| Message-ID | <n-KcnZkpYqGDKdX6nZ2dnZfqn_qdnZ2d@giganews.com> |
| In reply to | #121061 |
On 11/28/2024 07:59 AM, Muttley@DastardlyHQ.org wrote: > On Thu, 28 Nov 2024 16:43:00 +0100 > David Brown <david.brown@hesbynett.no> wibbled: >> On 28/11/2024 16:12, Muttley@DastardlyHQ.org wrote: >> handling systems. All this was perfectly reasonable for a small >> single-user single-tasking OS on limited hardware, and more efficient on >> the PC than the Unix system would have been. > > Sure, no argument there, but once NTFS came along they should really have > sorted things out. There could have been a backwards compat mode in order to > present a single rooted file system as a multi rooted one for older apps and > convert filenames etc. > Random-access in variable-byte-length encodings is not a thing. Alignment after "wide" characters and with regards to the usual little-endian organization of access, then besides "the filesystem", among single-byte, multiple-byte, and variable-byte encodings, have that Windows had support for all the Windows codepages and then Unicode rather simply, that being one of its few claims of "first-class" features, NT then as with regards to Orange Book, there was IOCP's, yet mostly a layer over the hardware, simply. Are there any other features of Windows that really stand out as "first-class", themselves? I don't consider the whole WMI bit and anything else above that as relevant to mostly usual "server" or "personal" workstations, nodes. The character support in Windows was pretty first-class and reflects why the whole IBM PC world went to it, and its layout reflects to hardware and a usually character encoding/decoding. Windows is/was written in C/C++ if once there was a lot in Pascal, whence the conventions later Hungarian, then that usual sorts portability layers have their own task to handle such particulars of otherwise the bog-standard defined by hardware.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-11-28 22:41 +0200 |
| Message-ID | <viaki7$mp6p$1@dont-email.me> |
| In reply to | #121056 |
On 28.11.2024 15:19, Michael S wrote: > On Thu, 28 Nov 2024 13:03:20 +0200 > Paavo Helde <eesnimi@osa.pri.ee> wrote: > >> On 28.11.2024 10:26, Muttley@DastardlyHQ.org wrote: >>> On Wed, 27 Nov 2024 14:58:18 -0500 >>> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >>>> On 11/27/24 11:12, Muttley@DastardlyHQ.org wrote: >>>>> On Wed, 27 Nov 2024 17:24:05 +0200 >>>>> Michael S <already5chosen@yahoo.com> wibbled: >>>> .... >>>>>> It works, but badly rather than fine. >>>>>> Specifically, it works only with ASCII paths. Which, on Windows, >>>>>> happen to be 2nd class. The biggest problem with ASCII paths on >>>>>> Windows is >>>>> >>>>> How can ascii paths be 2nd class (whatever that means) given that >>>>> ascii is a subset of utf-8? >>>> >>>> Because ascii is a subset of utf-8, any path name that contains a >>>> character not in that subset cannot be represented, which is what >>>> makes them 2nd class. >>> >>> Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd >>> class. The only issue comes when some idiot tries to mix utf-8 with >>> 8 bit ascii code pages. >> >> You are right, ASCII is not 2nd class because it is part of UTF-8. It >> is 2nd class on Windows because MS have historically decided to not >> support UTF-8 properly on Windows, in an attempt of a futile vendor >> lock-in. >> > > Not sure that it was about lock in. At time Win32 was conceived, UTF8 > didn't exist. At time WinNt was shipped, it still was less than a > year old. Back then choosing UTF16 looked reasonable. > Up to ~15 years ago it was not clear that UTF8 not just won, but won > decisively, so siting on the fence, waiting for the outcome of the > battle and rooting for legacy was not totally unreasonable. For what > happened after that, you could not underestimated a factor of laziness. > >> Though this is changing now, I just ran a quick test and apparently >> calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with >> VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string >> fopen() and they work properly. So there is progress! >> > > Can you try it with paths that are longer than 260 characters? Both > prefixed with "\\?\" and non-prefixed? > Non-prefixed, _mkdir() succeeds with a path of 247 unicode characters (406 bytes) and fails with 307 unicode chars (506 bytes). Prefixed with "\\?\" _mkdir() and fopen() appeared to work fine, tried up to 1275 unicode chars (2114 bytes), the largest path was: \\?\C:\Tmp\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää.txt Alas, the File Explorer left-hand tree failed to descend into so deep directory tree (double-click in right-hand pane worked, but left-hand tree was truncated at some point). When opened in Notepad or Notepad++, the too long paths were changed into tilde-style "short names", stripping the unicode chars: C:\tmp\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1.TXT
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web