www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ansi vs Unicode API

reply "Denis Koroskin" <2korden gmail.com> writes:
I'd like to raise 2 issues for a discussion.

First, Phobos makes calls to different functions, based on the OS we are  
running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's  
*really* necessary, since Microsoft has a Unicode Layer for those  
Operating Systems.

All an application needs to do to call W API on those OS'es is link with  
unicows.lib (which could be a part of Phobos). It does nothing on Win2k+  
and only triggers on 9x OS family.

A very good overview of it is written here:
http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx

Second, "A" API accepts ansi strings as parameters, not UTF-8 strings. I  
think this should be reflected in the function signatures, since D  
encourages distinguishing between UTF-8 and ANSI strings and not store the  
latter as char[].

LPCSTR currently resolves to char*/const(char)*, but it could be better  
for it to be an alias to ubyte*/const(ubyte)* so that user couldn't pass  
unicode string to an API that doesn't expect one. The same is applicable  
to other APIs, too, for example, how does C stdlib co-operate with  
Unicode? I.e. is core.stdc.stdio.fopen() unicode-aware?

What are your thoughts on the subject?
Nov 16 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 I'd like to raise 2 issues for a discussion.
 
 First, Phobos makes calls to different functions, based on the OS we are 
 running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's 
 *really* necessary, since Microsoft has a Unicode Layer for those 
 Operating Systems.
 
 All an application needs to do to call W API on those OS'es is link with 
 unicows.lib (which could be a part of Phobos). It does nothing on Win2k+ 
 and only triggers on 9x OS family.
 
 A very good overview of it is written here:
 http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx
 
 Second, "A" API accepts ansi strings as parameters, not UTF-8 strings. I 
 think this should be reflected in the function signatures, since D 
 encourages distinguishing between UTF-8 and ANSI strings and not store 
 the latter as char[].
 
 LPCSTR currently resolves to char*/const(char)*, but it could be better 
 for it to be an alias to ubyte*/const(ubyte)* so that user couldn't pass 
 unicode string to an API that doesn't expect one. The same is applicable 
 to other APIs, too, for example, how does C stdlib co-operate with 
 Unicode? I.e. is core.stdc.stdio.fopen() unicode-aware?
 
 What are your thoughts on the subject?

I think it's a great idea. Can phobos redistribute the unicows.lib (cute name)? Andrei
Nov 16 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 11:56:24 +0300, Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 I'd like to raise 2 issues for a discussion.
  First, Phobos makes calls to different functions, based on the OS we=


 are running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it'=


 *really* necessary, since Microsoft has a Unicode Layer for those  =


 Operating Systems.
  All an application needs to do to call W API on those OS'es is link =


 with unicows.lib (which could be a part of Phobos). It does nothing o=


 Win2k+ and only triggers on 9x OS family.
  A very good overview of it is written here:
 http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx
  Second, "A" API accepts ansi strings as parameters, not UTF-8 string=


 I think this should be reflected in the function signatures, since D =


 encourages distinguishing between UTF-8 and ANSI strings and not stor=


 the latter as char[].
  LPCSTR currently resolves to char*/const(char)*, but it could be  =


 better for it to be an alias to ubyte*/const(ubyte)* so that user  =


 couldn't pass unicode string to an API that doesn't expect one. The  =


 same is applicable to other APIs, too, for example, how does C stdlib=


 co-operate with Unicode? I.e. is core.stdc.stdio.fopen() unicode-awar=


  What are your thoughts on the subject?

I think it's a great idea. Can phobos redistribute the unicows.lib (cu=

 name)?

 Andrei

A quote, first: libunicows =E2=80=94 provides an MIT-licensed version of only the UNICOW= S.LIB = link-library, but still requires the Microsoft-provided UNICOWS.DLL or t= he = Mozilla OPENCOW.DLL. opencow (previously MZLU) =E2=80=94 reimplements both the DLL and LIB li= nk-library = as MPL 1.1/GPL 2.0/LGPL 2.1, originally for the Mozilla project.
Nov 16 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 11:56:24 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 I'd like to raise 2 issues for a discussion.
  First, Phobos makes calls to different functions, based on the OS we=


 are running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it'=


 *really* necessary, since Microsoft has a Unicode Layer for those  =


 Operating Systems.
  All an application needs to do to call W API on those OS'es is link =


 with unicows.lib (which could be a part of Phobos). It does nothing o=


 Win2k+ and only triggers on 9x OS family.
  A very good overview of it is written here:
 http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx
  Second, "A" API accepts ansi strings as parameters, not UTF-8 string=


 I think this should be reflected in the function signatures, since D =


 encourages distinguishing between UTF-8 and ANSI strings and not stor=


 the latter as char[].
  LPCSTR currently resolves to char*/const(char)*, but it could be  =


 better for it to be an alias to ubyte*/const(ubyte)* so that user  =


 couldn't pass unicode string to an API that doesn't expect one. The  =


 same is applicable to other APIs, too, for example, how does C stdlib=


 co-operate with Unicode? I.e. is core.stdc.stdio.fopen() unicode-awar=


  What are your thoughts on the subject?

I think it's a great idea. Can phobos redistribute the unicows.lib (cu=

 name)?

 Andrei

A quote, first:
 MSLU comes with licensing terms that are highly unfriendly to Open Sou=

 applications: although you can freely distribute unicows.dll with your=

 application, your licensing terms must meet certain > conditions that =

 Open Source license can. Namely, you must forbid further redistributio=

 and the license must be an EULA accepted by the user either in writing=

 or using click-through or shrink-wrap mechanism.
 To overcome this obstancle, the Mozilla project began reimplementing
 similar solution under Open Source terms: Opencow: Open Layer for Unic=

Overall, there are 2 Open Source alternatives available: 1) libunicows (http://libunicows.sourceforge.net/) =E2=80=94 provides an= = MIT-licensed version of only the UNICOWS.LIB link-library. Still require= s = the Microsoft-provided UNICOWS.DLL or the Mozilla OPENCOW.DLL, but has n= o = redistribution restrictions (since no Microsoft code redistributed) 2) opencow (previously MZLU) (http://opencow.sourceforge.net/) =E2=80=94= = reimplements both the DLL and LIB link-library as MPL 1.1/GPL 2.0/LGPL = 2.1, originally for the Mozilla project
Nov 16 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 I'd like to raise 2 issues for a discussion.
 
 First, Phobos makes calls to different functions, based on the OS we are 
 running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's 
 *really* necessary, since Microsoft has a Unicode Layer for those 
 Operating Systems.
 
 All an application needs to do to call W API on those OS'es is link with 
 unicows.lib (which could be a part of Phobos). It does nothing on Win2k+ 
 and only triggers on 9x OS family.
 
 A very good overview of it is written here:
 http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx

The unicows doesn't do anything more than what Phobos does in attempting to translate unicode into the local code page. All that using unicows would do is cause confusion and installation problems as the user would have to get a copy of unicows and install it. unicows doesn't exist on default Windows 9x installations. There is simply no advantage to unicows.
 Second, "A" API accepts ansi strings as parameters, not UTF-8 strings. I 
 think this should be reflected in the function signatures, since D 
 encourages distinguishing between UTF-8 and ANSI strings and not store 
 the latter as char[].
 
 LPCSTR currently resolves to char*/const(char)*, but it could be better 
 for it to be an alias to ubyte*/const(ubyte)* so that user couldn't pass 
 unicode string to an API that doesn't expect one. The same is applicable 
 to other APIs, too, for example, how does C stdlib co-operate with 
 Unicode? I.e. is core.stdc.stdio.fopen() unicode-aware?

Calling C functions means one needs to pass them what the host C system expects. C itself doesn't define what character set char* is. If you use the Phobos functions, those are required to work with unicode.
Nov 16 2009
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Mon, 16 Nov 2009 01:36:30 -0800, Walter Bright
<newshound1 digitalmars.com> wrote:

Denis Koroskin wrote:
 I'd like to raise 2 issues for a discussion.
 
 First, Phobos makes calls to different functions, based on the OS we are 
 running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's 
 *really* necessary, since Microsoft has a Unicode Layer for those 
 Operating Systems.
 
 All an application needs to do to call W API on those OS'es is link with 
 unicows.lib (which could be a part of Phobos). It does nothing on Win2k+ 
 and only triggers on 9x OS family.
 
 A very good overview of it is written here:
 http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx

The unicows doesn't do anything more than what Phobos does in attempting to translate unicode into the local code page. All that using unicows would do is cause confusion and installation problems as the user would have to get a copy of unicows and install it. unicows doesn't exist on default Windows 9x installations.

You so readily abandon support for Mac OS X 10.5 but keep catering for the convenience of users of the outdated Windows 9x. Don't you see anything wrong with this approach?
Nov 16 2009
next sibling parent reply Trass3r <mrmocool gmx.de> writes:
Max Samukha schrieb:
 
 You so readily abandon support for Mac OS X 10.5 but keep catering for
 the convenience of users of the outdated Windows 9x. Don't you see
 anything wrong with this approach?

OWNED. There's no point in supporting Win9x. Win98 support is already dropped by M$ (maybe even WinME as well already?) and you really can't use ME anymore, it's much too error prone.
Nov 16 2009
parent reply Trass3r <mrmocool gmx.de> writes:
Bill Baxter schrieb:
 The OS may not be "supported" in the sense of being able to get
 technical support, but you can still build programs that run on Win98
 using Visual Studio 2010.
 

Yeah, but the whole point of creating D has been to get rid of any kind of legacy that unnecessarily complicates stuff.
Nov 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Trass3r wrote:
 Yeah, but the whole point of creating D has been to get rid of any kind 
 of legacy that unnecessarily complicates stuff.

The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it.
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Trass3r wrote:
 Yeah, but the whole point of creating D has been to get rid of any 
 kind of legacy that unnecessarily complicates stuff.

The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it.

How about TLS? I understand Win95 doesn't have it. Andrei
Nov 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Trass3r wrote:
 Yeah, but the whole point of creating D has been to get rid of any 
 kind of legacy that unnecessarily complicates stuff.

The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it.

How about TLS? I understand Win95 doesn't have it.

My copy of "Advanced Windows" by Richter says it does have it.
Nov 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Trass3r wrote:
 Yeah, but the whole point of creating D has been to get rid of any 
 kind of legacy that unnecessarily complicates stuff.

The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it.

How about TLS? I understand Win95 doesn't have it.

My copy of "Advanced Windows" by Richter says it does have it.

I recall you told me there is a problem with the way it works that causes dmd trouble. Andrei
Nov 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Trass3r wrote:
 Yeah, but the whole point of creating D has been to get rid of any 
 kind of legacy that unnecessarily complicates stuff.

The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it.

How about TLS? I understand Win95 doesn't have it.

My copy of "Advanced Windows" by Richter says it does have it.

I recall you told me there is a problem with the way it works that causes dmd trouble.

Do you mean: http://d.puremagic.com/issues/show_bug.cgi?id=3342
Nov 16 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Trass3r wrote:
 Yeah, but the whole point of creating D has been to get rid of any 
 kind of legacy that unnecessarily complicates stuff.

The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it.

How about TLS? I understand Win95 doesn't have it.

My copy of "Advanced Windows" by Richter says it does have it.

I recall you told me there is a problem with the way it works that causes dmd trouble.

Do you mean: http://d.puremagic.com/issues/show_bug.cgi?id=3342

I would guess so. Andrei
Nov 16 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:
 You so readily abandon support for Mac OS X 10.5 but keep catering for
 the convenience of users of the outdated Windows 9x. Don't you see
 anything wrong with this approach?

Microsoft doesn't break support for older Windows when it comes out with newer ones. Supporting the full range of Windows is essentially trivial. With Apple, if you take "hello world" in C, compile it with the default settings on 10.5, the generated executable will "bus error" on 10.4. This is with the dev tools Apple provides. Not even linux is as good with compatibility as Microsoft is. That said, there is nothing I have done with the 10.6 support that should break running on 10.5. I'm not going to gratuitously break it. I will support workarounds if they are provided. Nobody has reported here if it works on 10.5 or not. If you are running 10.5, please let us know!
Nov 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Microsoft doesn't break support for older Windows when it comes out 
 with newer ones. Supporting the full range of Windows is essentially 
 trivial.

For the compiler, yes. For library code, not so much. If you want to use newer features of the MS libraries, you must abandon support older Windows.

True, but that's an app issue, not a dev tools issue.
 One example:  Tango's Process class tries to avoid popping up a console 
 window when running a script, but it uses a flag to CreateProcess that 
 is not supported on Windows 98 or earlier.  The decision was made to 
 just simply not support Windows 98 or earlier because it wasn't worth 
 throwing out that feature simply to support users of Windows 98 (who 
 frankly, should retire their likely now-paperweights).  This is probably 
 a milder case which causes no harm on a win98 box.  However, calling a 
 new function would make the lib not compile or fail to run.

I don't see any problem with not going to extra effort to support Win9x. I just see a problem with gratuitously breaking it.
Nov 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 15:05:48 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 Microsoft doesn't break support for older Windows when it comes out 
 with newer ones. Supporting the full range of Windows is essentially 
 trivial.

to use newer features of the MS libraries, you must abandon support older Windows.

True, but that's an app issue, not a dev tools issue.

If Phobos depends on functionality not supported in Windows 98, then dmd is pretty useless on win98 unless you provide a compatible standard library. Most normal users consider the standard library to be an essential part of the compiler.

Phobos doesn't currently have any compatibility problems with Win95. If a new feature of Phobos did have such an issue, I would expect to document it for that feature.
 I was just 
 arguing your point about how Windows always provides backwards 
 compatibility.

Backward compatibility doesn't mean that the old systems have to support new features. It just means that the old features continue to work on the new systems. I have a lot of software built for Win95 that still works fine <g>. Even the DOS programs still work.
Nov 16 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 15:05:48 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 Microsoft doesn't break support for older Windows when it comes out 
 with newer ones. Supporting the full range of Windows is 
 essentially trivial.

to use newer features of the MS libraries, you must abandon support older Windows.

True, but that's an app issue, not a dev tools issue.

If Phobos depends on functionality not supported in Windows 98, then dmd is pretty useless on win98 unless you provide a compatible standard library. Most normal users consider the standard library to be an essential part of the compiler.

Phobos doesn't currently have any compatibility problems with Win95. If a new feature of Phobos did have such an issue, I would expect to document it for that feature.

Wouldn't it have with static data? I know I introduced at least one static variable in a Phobos function. Andrei
Nov 16 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Wouldn't it have with static data? I know I introduced at least one 
 static variable in a Phobos function.

No, Win95 supports static and TLS data.
Nov 16 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 16:07:56 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Backward compatibility doesn't mean that the old systems have to 
 support new features. It just means that the old features continue to 
 work on the new systems. I have a lot of software built for Win95 that 
 still works fine <g>. Even the DOS programs still work.

Your argument was about building programs on MacOS 10.5 that crash on 10.4. That's like building programs on Windows XP and expecting them to run flawlessly on Windows 98. Although, I will say, having a Hello World executable throw a bus error is a little over the top in breaking backwards compatibility :) -Steve

Apple is a bit over the top. It really seems they don't give a damn about backwards compatibility. Yet they've stayed in business. I think there's a lesson in that.
Nov 17 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-17 03:19:39 -0500, Don <nospam nospam.com> said:

 Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 16:07:56 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Backward compatibility doesn't mean that the old systems have to 
 support new features. It just means that the old features continue to 
 work on the new systems. I have a lot of software built for Win95 that 
 still works fine <g>. Even the DOS programs still work.

Your argument was about building programs on MacOS 10.5 that crash on 10.4. That's like building programs on Windows XP and expecting them to run flawlessly on Windows 98. Although, I will say, having a Hello World executable throw a bus error is a little over the top in breaking backwards compatibility :) -Steve

Apple is a bit over the top. It really seems they don't give a damn about backwards compatibility. Yet they've stayed in business. I think there's a lesson in that.

I'm not sure to what extent that's true. I can still compile my apps for Mac OS X 10.1 in the latest Xcode by setting MACOSX_DEPLOYMENT_TARGET to 10.1. This prevents the resulting binary from using linker features not available in 10.1. To ensure availability for each symbol, Apple headers use macros (MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED, mapped to compiler flags −mmacosx-version-min=X and −mmacosx-version-max=X) to hide APIs not available for a given target OS version, and the compiler can then issue errors if you try to use them. Or it can weak-link symbols, allowing you to check at runtime for their availability. In the latest Mac OS X (10.4 forward), those two macros also control renaming at compile time of some symbols in the standard C library. This is because they changed things for UNIX conformance but didn't want to change the behavior for previously compiled programs. So if you don't set correctly MAC_OS_X_VERSION_MIN_REQUIRED at compile time you might also get a non-working executable in older Mac OS X versions. For instance, here's the declaration for fdopen on Mac OS X 10.6: #if defined(__DARWIN_10_6_AND_LATER) && (defined(_DARWIN_UNLIMITED_STREAMS) || defined(_DARWIN_C_SOURCE)) FILE *fdopen(int, const char *) __DARWIN_EXTSN(fdopen); #else /* < 10.6 || !_DARWIN_UNLIMITED_STREAMS && !_DARWIN_C_SOURCE */ FILE *fdopen(int, const char *) __DARWIN_10_6_AND_LATER_ALIAS(__DARWIN_ALIAS(fdopen)); #endif /* >= 10.6 &&_(DARWIN_UNLIMITED_STREAMS || _DARWIN_C_SOURCE) */ If you dig the macros a little, you see it can remap the function to symbol "_fdopen$DARWIN_EXTSN", "_fdopen$UNIX2003" or keep the original name, all depending on what the MAC_OS_X_VERSION_MIN_REQUIRED macro and others are set to. Compiling a hello world with the MACOSX_DEPLOYMENT_TARGET environment variable set to 10.4 and both MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED set to 1040 should result in a binary compatible with 10.4. Or you can compile against the Mac OS X 10.4 SDK to get the same result. It's true that backward compatibility isn't the default setting when compiling a program in Mac OS X: you must explicitly ask for it. But I don't think it's fair to say that Apple doesn't give a damn, otherwise all this complicated stuff wouldn't exist. Here are some more details (although some things in this article are outdated): <http://developer.apple.com/mac/library/technotes/tn2002/tn2064.html> And this one is documenting symbol renaming: <http://developer.apple.com/mac/library/releasenotes/Darwin/SymbolVariantsRelNotes/index.html> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 17 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 12:36:30 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:
 I'd like to raise 2 issues for a discussion.
  First, Phobos makes calls to different functions, based on the OS we  
 are running on (e.g. CreateFileA vs. CreateFileW) and I wonder if it's  
 *really* necessary, since Microsoft has a Unicode Layer for those  
 Operating Systems.
  All an application needs to do to call W API on those OS'es is link  
 with unicows.lib (which could be a part of Phobos). It does nothing on  
 Win2k+ and only triggers on 9x OS family.
  A very good overview of it is written here:
 http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx

The unicows doesn't do anything more than what Phobos does in attempting to translate unicode into the local code page. All that using unicows would do is cause confusion and installation problems as the user would have to get a copy of unicows and install it. unicows doesn't exist on default Windows 9x installations. There is simply no advantage to unicows.

End-users don't have to worry about it at all. They will just use W functions all the time and unicows will trigger and translate UTF16 strings into ANSI strings automatically on those operating systems. The change would be transparent for them. There is also a redistributable version of unicows, so those users who want to deploy their software on Win9x could use it and don't force manual install of the .dll. I was about to propose a drop of Win9x support initially, but thought it might get hostile reception...
 Second, "A" API accepts ansi strings as parameters, not UTF-8 strings.  
 I think this should be reflected in the function signatures, since D  
 encourages distinguishing between UTF-8 and ANSI strings and not store  
 the latter as char[].
  LPCSTR currently resolves to char*/const(char)*, but it could be  
 better for it to be an alias to ubyte*/const(ubyte)* so that user  
 couldn't pass unicode string to an API that doesn't expect one. The  
 same is applicable to other APIs, too, for example, how does C stdlib  
 co-operate with Unicode? I.e. is core.stdc.stdio.fopen() unicode-aware?

Calling C functions means one needs to pass them what the host C system expects. C itself doesn't define what character set char* is. If you use the Phobos functions, those are required to work with unicode.

Since char*/char[] denotes a sequence of Unicode characters in D, I see no reason for the API that works with ANSI characters to accept it. For example, there is a std.windows.charset.toMBSz() function that returns an ANSI variant of a Unicode string. I think it might be preferred for it to return ubyte sequence instead of char sequence. Ideally, I'd like to see all the function that aren't guarantied to work with UTF-8 strings to accept ubyte*/ubyte[] instead.
Nov 16 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 End-users don't have to worry about it at all. They will just use W 
 functions all the time and unicows will trigger and translate UTF16 
 strings into ANSI strings automatically on those operating systems. The 
 change would be transparent for them. There is also a redistributable 
 version of unicows, so those users who want to deploy their software on 
 Win9x could use it and don't force manual install of the .dll.

The current Phobos works fine with Win9x and does not require the user to find or install another dll. Even worse, the users have to have *their* users get and successfully install that dll. I see absolutely no advantage to requiring an extra dll.
Nov 16 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 16 Nov 2009 16:20:15 +0300, Trass3r <mrmocool gmx.de> wrote:

 Max Samukha schrieb:
  You so readily abandon support for Mac OS X 10.5 but keep catering for
 the convenience of users of the outdated Windows 9x. Don't you see
 anything wrong with this approach?

OWNED. There's no point in supporting Win9x. Win98 support is already dropped by M$ (maybe even WinME as well already?) and you really can't use ME anymore, it's much too error prone.

Windows 98, Windows 98 SE, and Windows Me Support ended on 11 July 2006 (http://support.microsoft.com/gp/lifean18)
Nov 16 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Nov 16, 2009 at 5:20 AM, Trass3r <mrmocool gmx.de> wrote:
 Max Samukha schrieb:
 You so readily abandon support for Mac OS X 10.5 but keep catering for
 the convenience of users of the outdated Windows 9x. Don't you see
 anything wrong with this approach?

OWNED. There's no point in supporting Win9x. Win98 support is already dropped by M$ (maybe even WinME as well already?) and you really can't use ME anymore, it's much too error prone.

The OS may not be "supported" in the sense of being able to get technical support, but you can still build programs that run on Win98 using Visual Studio 2010. I think the big difference here is that Microsoft takes backwards compatibility very seriously, Apple, apparently, doesn't. So I don't see anything wrong with DMD taking support for older platforms more seriously on Windows than on Mac. --bb
Nov 16 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Microsoft doesn't break support for older Windows when it comes out with  
 newer ones. Supporting the full range of Windows is essentially trivial.

For the compiler, yes. For library code, not so much. If you want to use newer features of the MS libraries, you must abandon support older Windows. One example: Tango's Process class tries to avoid popping up a console window when running a script, but it uses a flag to CreateProcess that is not supported on Windows 98 or earlier. The decision was made to just simply not support Windows 98 or earlier because it wasn't worth throwing out that feature simply to support users of Windows 98 (who frankly, should retire their likely now-paperweights). This is probably a milder case which causes no harm on a win98 box. However, calling a new function would make the lib not compile or fail to run. -Steve
Nov 16 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 16 Nov 2009 15:05:48 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Microsoft doesn't break support for older Windows when it comes out  
 with newer ones. Supporting the full range of Windows is essentially  
 trivial.

use newer features of the MS libraries, you must abandon support older Windows.

True, but that's an app issue, not a dev tools issue.

If Phobos depends on functionality not supported in Windows 98, then dmd is pretty useless on win98 unless you provide a compatible standard library. Most normal users consider the standard library to be an essential part of the compiler.
 One example:  Tango's Process class tries to avoid popping up a console  
 window when running a script, but it uses a flag to CreateProcess that  
 is not supported on Windows 98 or earlier.  The decision was made to  
 just simply not support Windows 98 or earlier because it wasn't worth  
 throwing out that feature simply to support users of Windows 98 (who  
 frankly, should retire their likely now-paperweights).  This is  
 probably a milder case which causes no harm on a win98 box.  However,  
 calling a new function would make the lib not compile or fail to run.

I don't see any problem with not going to extra effort to support Win9x. I just see a problem with gratuitously breaking it.

If its for the sake of functionality (i.e. you can't get the functionality without it) then I think gratuitous breaking is warranted. However, I don't care too much about Unicode, I work mostly in English and pretty much only in ANSI-compatible utf8. From your description, it sounds like this is not one of those cases (i.e. you *can* get the functionality without breaking compatibility). I was just arguing your point about how Windows always provides backwards compatibility. -Steve
Nov 16 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 16 Nov 2009 16:07:56 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Backward compatibility doesn't mean that the old systems have to support  
 new features. It just means that the old features continue to work on  
 the new systems. I have a lot of software built for Win95 that still  
 works fine <g>. Even the DOS programs still work.

Your argument was about building programs on MacOS 10.5 that crash on 10.4. That's like building programs on Windows XP and expecting them to run flawlessly on Windows 98. Although, I will say, having a Hello World executable throw a bus error is a little over the top in breaking backwards compatibility :) -Steve
Nov 16 2009