www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - phobos/tango on win32: please drop ANSI "support"

reply Lionello Lunesu <lio lunesu.remove.com> writes:
Both Phobos and Tango pretend utf8 is valid for calling ANSI methods 
from the Windows' API. Obviously, it's not. The correct way is to 
convert the utf8 string to the code-page expected by the call, or 
convert them to unicode.

I'd like to suggest the latter. Let's drop the ANSI support for Win32 
altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not 
mistaken) and converting utf8 to ANSI is more expensive than converting 
it utf8 to utf16 (which is what Windows 2000 and up convert to 
internally anyway). No more "bool UseWFuncs". And converting utf8 to 
utf16 using MultiByteToWideChar would also take care of the 0-terminator.

There, I've said it.

L.
Feb 14 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
Lionello Lunesu wrote:

 Both Phobos and Tango pretend utf8 is valid for calling ANSI methods 
 from the Windows' API. Obviously, it's not. The correct way is to 
 convert the utf8 string to the code-page expected by the call, or 
 convert them to unicode.
 
 I'd like to suggest the latter. Let's drop the ANSI support for Win32 
 altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not 
 mistaken) and converting utf8 to ANSI is more expensive than converting 
 it utf8 to utf16 (which is what Windows 2000 and up convert to 
 internally anyway). No more "bool UseWFuncs". And converting utf8 to 
 utf16 using MultiByteToWideChar would also take care of the 0-terminator.
 
 There, I've said it.
 
 L.


Do you mean ASCII?
Feb 14 2007
next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"BCS" <BCS pathlink.com> wrote in message 
news:eqvgkt$ubi$1 digitalmars.com...

 Lionello Lunesu wrote:

 Both Phobos and Tango pretend utf8 is valid for calling ANSI methods from 
 the Windows' API. Obviously, it's not. The correct way is to convert the 
 utf8 string to the code-page expected by the call, or convert them to 
 unicode.

 I'd like to suggest the latter. Let's drop the ANSI support for Win32 
 altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not 
 mistaken) and converting utf8 to ANSI is more expensive than converting 
 it utf8 to utf16 (which is what Windows 2000 and up convert to internally 
 anyway). No more "bool UseWFuncs". And converting utf8 to utf16 using 
 MultiByteToWideChar would also take care of the 0-terminator.

 There, I've said it.

 L.


 Do you mean ASCII?


No, definitely not ASCII.. What does the A stand for in RegisterClassA, 
CreateWindowA, CreateFileA, etc.  in the Windows API?  W = Wide, 'wchar', 
but what's A?

From MSDN:

...with the specific "A" (ANSI) or "W" (wide, Unicode)...

L.
Feb 14 2007
parent BCS <BCS pathlink.com> writes:
Lionello Lunesu wrote:

 "BCS" <BCS pathlink.com> wrote in message 

Do you mean ASCII?


 
 
 No, definitely not ASCII.. What does the A stand for in RegisterClassA, 
 CreateWindowA, CreateFileA, etc.  in the Windows API?  W = Wide, 'wchar', 
 but what's A?
 
 From MSDN:
 
 ....with the specific "A" (ANSI) or "W" (wide, Unicode)...
 
 L. 
 
 


Hm.. haven't heard of that before.
Feb 14 2007
prev sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
BCS wrote:

 Lionello Lunesu wrote:
 

 Both Phobos and Tango pretend utf8 is valid for calling ANSI methods 
 from the Windows' API. Obviously, it's not. The correct way is to 
 convert the utf8 string to the code-page expected by the call, or 
 convert them to unicode.

 I'd like to suggest the latter. Let's drop the ANSI support for Win32 
 altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not 
 mistaken) and converting utf8 to ANSI is more expensive than 
 converting it utf8 to utf16 (which is what Windows 2000 and up convert 
 to internally anyway). No more "bool UseWFuncs". And converting utf8 
 to utf16 using MultiByteToWideChar would also take care of the 
 0-terminator.

 There, I've said it.

 L.


 
 
 Do you mean ASCII?


Perhaps these would be edifying:

http://en.wikipedia.org/wiki/Windows_code_page
http://en.wikipedia.org/wiki/Windows-1252

In short, when someone says "ANSI" in reference to Windows or the 
Windows API, they mean the stuff in the above articles (which isn't 
actually an ANSI standard at all). Those are flat 8-bit encodings, and 
storing them in a UTF-8 datatype will only cause grief. As Lionello 
points out, modern versions of Windows use UTF-16 internally. (Although 
originally it was just UCS-2, and most Windows fonts don't know about 
anything beyond those two bytes.)

I agree with Lionello: UTF-8 is a terrible thing to call the Windows API 
with. When dealing with the Windows API in D, it is best to stick with 
wchar[].

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Feb 14 2007
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 Both Phobos and Tango pretend utf8 is valid for calling ANSI methods 
 from the Windows' API. Obviously, it's not. The correct way is to 
 convert the utf8 string to the code-page expected by the call, or 
 convert them to unicode.
 
 I'd like to suggest the latter. Let's drop the ANSI support for Win32 
 altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not 
 mistaken) and converting utf8 to ANSI is more expensive than converting 
 it utf8 to utf16 (which is what Windows 2000 and up convert to 
 internally anyway). No more "bool UseWFuncs". And converting utf8 to 
 utf16 using MultiByteToWideChar would also take care of the 0-terminator.


The "useWfuncs" only happens for Windows 9x (including Me). All Windows 
9x systems are 8 bit internally, and even if you use the W interface, 
they are internally converted to 8 bits anyway.
Feb 14 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 Lionello Lunesu wrote:

 Both Phobos and Tango pretend utf8 is valid for calling ANSI methods 
 from the Windows' API. Obviously, it's not. The correct way is to 
 convert the utf8 string to the code-page expected by the call, or 
 convert them to unicode.

 I'd like to suggest the latter. Let's drop the ANSI support for Win32 
 altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not 
 mistaken) and converting utf8 to ANSI is more expensive than 
 converting it utf8 to utf16 (which is what Windows 2000 and up convert 
 to internally anyway). No more "bool UseWFuncs". And converting utf8 
 to utf16 using MultiByteToWideChar would also take care of the 
 0-terminator.


 
 The "useWfuncs" only happens for Windows 9x (including Me). All Windows 
 9x systems are 8 bit internally, and even if you use the W interface, 
 they are internally converted to 8 bits anyway.


Yes, they will be converted to "8 bits", but not to utf8. They will be 
converted to whatever code-page the thread's currently using, which is 
what's supposed to be done. That's my point: both Phobos and Tango pass 
utf8 to ANSI (..A) versions of Windows' functions, which is not correct.

You should either convert the utf8 to the correct code-page for passing 
to WhatEverA(..), or convert it to utf16 and pass it to WhatEverW(..). 
The last one is much easier: a fixed, straightforward conversion (no 
need to know about code-pages) that also happens to be efficient for 
Windows 2000 and up.

As for UseWFuncs: I don't like it because the check is done at run-time. 
It's allover the place, practically doubles all Win32 code, not to 
mention the imports / obj-size. More importantly, for the reasons 
mentioned above, I don't think it's necessary.

L.
Feb 14 2007
next sibling parent reply kris <foo bar.com> writes:
Lionello Lunesu wrote:

 Walter Bright wrote:
 

 Lionello Lunesu wrote:


 Both Phobos and Tango pretend utf8 is valid for calling ANSI methods 
 from the Windows' API. Obviously, it's not. The correct way is to 
 convert the utf8 string to the code-page expected by the call, or 
 convert them to unicode.

 I'd like to suggest the latter. Let's drop the ANSI support for Win32 
 altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not 
 mistaken) and converting utf8 to ANSI is more expensive than 
 converting it utf8 to utf16 (which is what Windows 2000 and up 
 convert to internally anyway). No more "bool UseWFuncs". And 
 converting utf8 to utf16 using MultiByteToWideChar would also take 
 care of the 0-terminator.



 The "useWfuncs" only happens for Windows 9x (including Me). All 
 Windows 9x systems are 8 bit internally, and even if you use the W 
 interface, they are internally converted to 8 bits anyway.


 
 
 Yes, they will be converted to "8 bits", but not to utf8. They will be 
 converted to whatever code-page the thread's currently using, which is 
 what's supposed to be done. That's my point: both Phobos and Tango pass 
 utf8 to ANSI (..A) versions of Windows' functions, which is not correct.


Regarding Tango, it uses the WindowsA functions only if 
-verion=Win32SansUnicode is configured. This switch is for supporting 
certain older environments, but does /not/ imply that code-pages are 
supported in Tango. There has never been an intent to do so.

For code-page support, we currently suggest using a library such as ICU 
to do the appropriate conversions.
Feb 14 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
kris wrote:

 Lionello Lunesu wrote:

 Walter Bright wrote:


 Lionello Lunesu wrote:


 Both Phobos and Tango pretend utf8 is valid for calling ANSI methods 
 from the Windows' API. Obviously, it's not. The correct way is to 
 convert the utf8 string to the code-page expected by the call, or 
 convert them to unicode.

 I'd like to suggest the latter. Let's drop the ANSI support for 
 Win32 altogether. Unicode is supported since Windows 95 OSR-2 (if 
 I'm not mistaken) and converting utf8 to ANSI is more expensive than 
 converting it utf8 to utf16 (which is what Windows 2000 and up 
 convert to internally anyway). No more "bool UseWFuncs". And 
 converting utf8 to utf16 using MultiByteToWideChar would also take 
 care of the 0-terminator.



 The "useWfuncs" only happens for Windows 9x (including Me). All 
 Windows 9x systems are 8 bit internally, and even if you use the W 
 interface, they are internally converted to 8 bits anyway.



 Yes, they will be converted to "8 bits", but not to utf8. They will be 
 converted to whatever code-page the thread's currently using, which is 
 what's supposed to be done. That's my point: both Phobos and Tango 
 pass utf8 to ANSI (..A) versions of Windows' functions, which is not 
 correct.


 
 Regarding Tango, it uses the WindowsA functions only if 
 -verion=Win32SansUnicode is configured. This switch is for supporting 
 certain older environments, but does /not/ imply that code-pages are 
 supported in Tango. There has never been an intent to do so.


Then it's not actually supporting those older environments at all.


 For code-page support, we currently suggest using a library such as ICU 
 to do the appropriate conversions.


On Windows, just convert to wchar[] (as you would on W2K and up) and 
then use WideCharToMultiByte.

L.
Feb 15 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Lionello Lunesu wrote:

 kris wrote:

 Regarding Tango, it uses the WindowsA functions only if 
 -verion=Win32SansUnicode is configured. This switch is for supporting 
 certain older environments, but does /not/ imply that code-pages are 
 supported in Tango. There has never been an intent to do so.


 
 Then it's not actually supporting those older environments at all.


Well, that's support, just not *full* support. Needing to stick to ASCII 
is still better than no support at all...
Feb 15 2007
parent Lionello Lunesu <lio lunesu.remove.com> writes:
Frits van Bommel wrote:

 Lionello Lunesu wrote:

 kris wrote:

 Regarding Tango, it uses the WindowsA functions only if 
 -verion=Win32SansUnicode is configured. This switch is for supporting 
 certain older environments, but does /not/ imply that code-pages are 
 supported in Tango. There has never been an intent to do so.


 Then it's not actually supporting those older environments at all.


 
 Well, that's support, just not *full* support. Needing to stick to ASCII 
 is still better than no support at all...


OK, then all it needs is a "ThrowIfContainsUpperAscii(str);" and we're 
set :)

L.
Feb 15 2007
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Lionello Lunesu wrote:


 kris wrote:

 
 Regarding Tango, it uses the WindowsA functions only if
 -verion=Win32SansUnicode is configured. This switch is for supporting
 certain older environments, but does /not/ imply that code-pages are
 supported in Tango. There has never been an intent to do so.


 
 Then it's not actually supporting those older environments at all.


Would depend on the nature of said environments, no?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango
Feb 15 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Lars Ivar Igesund wrote:

 Lionello Lunesu wrote:
 

 kris wrote:

 Regarding Tango, it uses the WindowsA functions only if
 -verion=Win32SansUnicode is configured. This switch is for supporting
 certain older environments, but does /not/ imply that code-pages are
 supported in Tango. There has never been an intent to do so.


 Then it's not actually supporting those older environments at all.


 
 Would depend on the nature of said environments, no?


??

That would mean that a char[] in Tango is not always utf8 and could in 
fact be code-page specific encoding. This is quite nasty for somebody 
writing library functions in Tango.

L.
Feb 15 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Lionello Lunesu wrote:


 Lars Ivar Igesund wrote:

 Lionello Lunesu wrote:
 

 kris wrote:

 Regarding Tango, it uses the WindowsA functions only if
 -verion=Win32SansUnicode is configured. This switch is for supporting
 certain older environments, but does /not/ imply that code-pages are
 supported in Tango. There has never been an intent to do so.


 Then it's not actually supporting those older environments at all.


 
 Would depend on the nature of said environments, no?


 
 ??
 
 That would mean that a char[] in Tango is not always utf8 and could in
 fact be code-page specific encoding. This is quite nasty for somebody
 writing library functions in Tango.
 
 L.


No, as Kris mentions, code pages are not currently supported in Tango (they
are possible to support via the ICU bindings in Mango), but in environments
where ASCII is the only used subset (like on your typical old PC in the US
of A) would be supported by the functionality in question. This is not
compiled in by default in Tango, and as such you use it only if you are
aware that you don't use standard Unicode compliant Tango.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango
Feb 15 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 Walter Bright wrote:

 The "useWfuncs" only happens for Windows 9x (including Me). All 
 Windows 9x systems are 8 bit internally, and even if you use the W 
 interface, they are internally converted to 8 bits anyway.


 
 Yes, they will be converted to "8 bits", but not to utf8. They will be 
 converted to whatever code-page the thread's currently using, which is 
 what's supposed to be done. That's my point: both Phobos and Tango pass 
 utf8 to ANSI (..A) versions of Windows' functions, which is not correct.
 
 You should either convert the utf8 to the correct code-page for passing 
 to WhatEverA(..),


It does convert to the correct code-page. See std.windows.charset.toMBSz().


 or convert it to utf16 and pass it to WhatEverW(..). 
 The last one is much easier: a fixed, straightforward conversion (no 
 need to know about code-pages)


This just does not work under Win9x, because most of the 'W' functions 
are not supported. (Also, Win9x internally converts the few 'W' 
functions it does support right back to 'A'.)


 that also happens to be efficient for 
 Windows 2000 and up.


Under Windows NT, 2000, and up, the 'W' functions *are* called.


 As for UseWFuncs: I don't like it because the check is done at run-time.


It has to be done at runtime, because that's the only way to make it 
work between different Windows versions.


 It's allover the place, practically doubles all Win32 code, not to 
 mention the imports / obj-size. More importantly, for the reasons 
 mentioned above, I don't think it's necessary.


There's no hope for it unless all support for Win9x is dropped.
Feb 15 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 Lionello Lunesu wrote:

 Walter Bright wrote:

 The "useWfuncs" only happens for Windows 9x (including Me). All 
 Windows 9x systems are 8 bit internally, and even if you use the W 
 interface, they are internally converted to 8 bits anyway.


 Yes, they will be converted to "8 bits", but not to utf8. They will be 
 converted to whatever code-page the thread's currently using, which is 
 what's supposed to be done. That's my point: both Phobos and Tango 
 pass utf8 to ANSI (..A) versions of Windows' functions, which is not 
 correct.

 You should either convert the utf8 to the correct code-page for 
 passing to WhatEverA(..),


 
 It does convert to the correct code-page. See std.windows.charset.toMBSz().


The problem is that this function is not always called. And because, by 
default, the A-functions are the ones that get aliased to the 'normal 
form', many times the utf8 char[] is passed as if it were 'ansi'.

A quick grep reveals:

std\loader.d [5]
std\windows\registry.d [35]

I know these are easily solvable, but I was just wondering if it was 
worth the trouble.


 or convert it to utf16 and pass it to WhatEverW(..). The last one is 
 much easier: a fixed, straightforward conversion (no need to know 
 about code-pages)


 
 This just does not work under Win9x, because most of the 'W' functions 
 are not supported. (Also, Win9x internally converts the few 'W' 
 functions it does support right back to 'A'.)


Yes, but it would be done by Windows. Instead of:

if (UseWFuncs)
   WhatEverA( str.toMBSz );
else
   WhatEverW( str.toUTF16z );

You'd do only:

   WhatEverW( str.toUTF16z );

and Windows' unicode layer for Win9x would convert the string back to 
the proper code-page. Hey, which is exactly what's going on in 
std.windows.charset! But at least I don't have to worry about 
"UseWFuncs" in my own code anymore...


 that also happens to be efficient for Windows 2000 and up.


 
 Under Windows NT, 2000, and up, the 'W' functions *are* called.


Only is you'd bother to check UseWFuncs. You probably would, but many don't.


 As for UseWFuncs: I don't like it because the check is done at run-time.


 
 It has to be done at runtime, because that's the only way to make it 
 work between different Windows versions.


You could provide link-time support only, using version blocks?


 It's allover the place, practically doubles all Win32 code, not to 
 mention the imports / obj-size. More importantly, for the reasons 
 mentioned above, I don't think it's necessary.


 
 There's no hope for it unless all support for Win9x is dropped.


See previous question.

L.
Feb 15 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 Walter Bright wrote:

 It does convert to the correct code-page. See 
 std.windows.charset.toMBSz().


 The problem is that this function is not always called. And because, by 
 default, the A-functions are the ones that get aliased to the 'normal 
 form', many times the utf8 char[] is passed as if it were 'ansi'.
 
 A quick grep reveals:
 
 std\loader.d [5]
 std\windows\registry.d [35]


Those would be bugs. All the ones using useWfuncs are correctly done 
(see std.file).


 This just does not work under Win9x, because most of the 'W' functions 
 are not supported. (Also, Win9x internally converts the few 'W' 
 functions it does support right back to 'A'.)


 
 Yes, but it would be done by Windows. Instead of:
 
 if (UseWFuncs)
   WhatEverA( str.toMBSz );
 else
   WhatEverW( str.toUTF16z );
 
 You'd do only:
 
   WhatEverW( str.toUTF16z );
 
 and Windows' unicode layer for Win9x would convert the string back to 
 the proper code-page. Hey, which is exactly what's going on in 
 std.windows.charset! But at least I don't have to worry about 
 "UseWFuncs" in my own code anymore...


unicode layer for Windows is not part of Win9x, it's a separate add-on. 
This means that in order to use a D executable, the user would have to 
find and install MSLU. This is unacceptable - I don't want to deal with 
the constant "bug reports" about this.


 that also happens to be efficient for Windows 2000 and up.


 Under Windows NT, 2000, and up, the 'W' functions *are* called.


 
 Only is you'd bother to check UseWFuncs. You probably would, but many 
 don't.
 

 As for UseWFuncs: I don't like it because the check is done at run-time.


 It has to be done at runtime, because that's the only way to make it 
 work between different Windows versions.


 
 You could provide link-time support only, using version blocks?


Then there'd be two Phobos libraries, and the D programmer would have to 
ship two different executables. This is not worth it.
Feb 15 2007
parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 unicode layer for Windows is not part of Win9x, it's a separate add-on. 
 This means that in order to use a D executable, the user would have to 
 find and install MSLU. This is unacceptable - I don't want to deal with 
 the constant "bug reports" about this.


Supporting 9x in general is a huge pain.  There are a lot of important 
library features that it doesn't provide.


Sean
Feb 15 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 unicode layer for Windows is not part of Win9x, it's a separate 
 add-on. This means that in order to use a D executable, the user would 
 have to find and install MSLU. This is unacceptable - I don't want to 
 deal with the constant "bug reports" about this.


 
 Supporting 9x in general is a huge pain.  There are a lot of important 
 library features that it doesn't provide.


Couldn't that be just dropped? MS itself dropped support for them six 
months ago:

http://support.microsoft.com/gp/lifean18


Andrei
Feb 15 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 unicode layer for Windows is not part of Win9x, it's a separate 
 add-on. This means that in order to use a D executable, the user would 
 have to find and install MSLU. This is unacceptable - I don't want to 
 deal with the constant "bug reports" about this.


 
 Supporting 9x in general is a huge pain.  There are a lot of important 
 library features that it doesn't provide.


The basic stuff, like file I/O, does work, and must work.
Feb 15 2007
parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 unicode layer for Windows is not part of Win9x, it's a separate 
 add-on. This means that in order to use a D executable, the user 
 would have to find and install MSLU. This is unacceptable - I don't 
 want to deal with the constant "bug reports" about this.


 Supporting 9x in general is a huge pain.  There are a lot of important 
 library features that it doesn't provide.


 
 The basic stuff, like file I/O, does work, and must work.


Well sure, but their socket library and threading support are somewhat 
weak.  I'll admit that my opinion is skewed towards my own particular 
areas of interest.


Sean
Feb 15 2007
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:er24ru$171o$1 digitalmars.com...

 Walter Bright wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 unicode layer for Windows is not part of Win9x, it's a separate add-on. 
 This means that in order to use a D executable, the user would have to 
 find and install MSLU. This is unacceptable - I don't want to deal with 
 the constant "bug reports" about this.


 Supporting 9x in general is a huge pain.  There are a lot of important 
 library features that it doesn't provide.


 The basic stuff, like file I/O, does work, and must work.


 Well sure, but their socket library and threading support are somewhat 
 weak.  I'll admit that my opinion is skewed towards my own particular 
 areas of interest.


You make a great point: isn't Phobos using winsock2? This is also an add-on 
for the older windows systems.

L
Feb 15 2007
parent Don Clugston <dac nospam.com.au> writes:
Lionello Lunesu wrote:

 "Sean Kelly" <sean f4.ca> wrote in message 
 news:er24ru$171o$1 digitalmars.com...

 Walter Bright wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 unicode layer for Windows is not part of Win9x, it's a separate add-on. 
 This means that in order to use a D executable, the user would have to 
 find and install MSLU. This is unacceptable - I don't want to deal with 
 the constant "bug reports" about this.


 Supporting 9x in general is a huge pain.  There are a lot of important 
 library features that it doesn't provide.


 The basic stuff, like file I/O, does work, and must work.


 Well sure, but their socket library and threading support are somewhat 
 weak.  I'll admit that my opinion is skewed towards my own particular 
 areas of interest.


 
 You make a great point: isn't Phobos using winsock2? This is also an add-on 
 for the older windows systems.


It shipped with the second revision of Win95. There must be very few 
Win9x systems that don't have it, and those that don't would not be 
using sockets. It's pretty safe to assume it's installed.
Feb 20 2007
prev sibling parent reply "Todor Totev" <umbra.tenebris list.ru> writes:
 I'd like to suggest the latter. Let's drop the ANSI support for Win32  
 altogether. Unicode is supported since Windows 95 OSR-2 (if I'm not  
 mistaken) and converting utf8 to ANSI is more expensive than converting  
 it utf8 to utf16 (which is what Windows 2000 and up convert to  
 internally anyway). No more "bool UseWFuncs". And converting utf8 to  
 utf16 using MultiByteToWideChar would also take care of the 0-terminator.


Actually Microsoft are heading this way themselves.
See this blog post:  
http://blogs.msdn.com/michkap/archive/2005/10/02/476213.aspx
In short - Microsoft are not developing W/A APIs anymore.
Also, if you look at their latest software you'll notice that they are  
using
MSLU (Microsoft layer for UNICODE) so that their UNICODE programs can run  
on 9x.

My personal experience is that our customers don't even use Windows 2000.
Everyone is using XP for desktops and x64 for servers.
So what is your opinion? Do you need to support a 9x version of a program
for living?
Todor
Feb 15 2007
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todor Totev schrieb am 2007-02-15:
[snip]

 My personal experience is that our customers don't even use Windows 2000.
 Everyone is using XP for desktops and x64 for servers.
 So what is your opinion? Do you need to support a 9x version of a program
 for living?


Yes. 9x is still used because the communication software for engineering
hardware are still 16bit. (closed source and undocumented protocols ...)

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFF1D5ILK5blCcjpWoRAgo5AJ4rP678+vko2yaU/sZorPN1vVxyxwCeI9Hi
jQ2gbuZ3GMr1PQQYvFpZIBU=
=V4rC
-----END PGP SIGNATURE-----
Feb 15 2007