[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[patch #4598] filesystemRepresentation on Win32 is DANGEROUS as implemen
[patch #4598] filesystemRepresentation on Win32 is DANGEROUS as implemented
Sun, 6 Nov 2005 06:27:07 +0000
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050911 Firefox/1.0.6 (Debian package 1.0.6-5)
Update of patch #4598 (project gnustep):
Status: None => Wont Do
Open/Closed: Open => Closed
Follow-up Comment #2:
Sorry to be slow responding to this ... but I spent saturday and part of
friday with my machine running windows (as part of the ongoing effort to get
mingw support to a similar state as unix) ... so didn't have my GNUmail
client running to pick up my emails.
This patch can't be applied because a few bits of it are already in place,
other bits are inappropriate, but also it reintroduces complexities we are
trying to get rid of.
Responding to your original points ...
> filesystemRepresentation is declared as returning char* when it actually
I already changed that to be dependent on the __MINGW32__ preprocessor
constant, once I'd rationalised the system to use a single consistent
constant throughout. In any case, the behavior of the method is *clearly*
> Even gnustep-base itself has uses of filesystemRepresentation that are not
That shouldn't be the case ... but porting to mingw32 is a work in
progress... While there shouldn't be any non-unicode mingw32 calls in use,
we do need to keep checking and replacing them where we find them (I'm
intending to fix the timezone stuff in the registrly, though since all the
relevant registry keys are ascii, that's more for consistency than
necessity). I believe there are also places where inefficient posix
compatibility functions are used and it would be better to use native win32
> Unicode is NOT the native filesystem encoding for the Win32 API. Win32
actually has 2 "native" encodings.
I think you mean it has two APIs (it certainly supports more than two
encodings) and are referring to the variants of the functions in the win32
API for 8bit and 16bit characters. However, the existence of two variants of
functions is clearly a transitional backward compatibility issue, since
modern windows systems are built to the new 16bit api and implement the old
api as wrappers round it (and windows CE drops the old 8bit api, only having
the new one).
The base library needs to stick to the KISS principle and support one API
... we should not be adding methods in order to support two windows APIs,
when one of them is obsolete, and when there are mechanisms in both windows
and GNUstep for doing character conversion for the case where a windows
programmer wants to use the old win32 functions rather than the new ones.
Reply to this item at:
Message sent via/by Savannah