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'=




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 o=




n  =


 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=




s.  =


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




 =


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




e  =


 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=




e?

  What are your thoughts on the subject?


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


te  =


 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'=




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 o=




n  =


 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=




s.  =


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




 =


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




e  =


 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=




e?

  What are your thoughts on the subject?


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


te  =


 name)?

 Andrei


A quote, first:


 MSLU comes with licensing terms that are highly unfriendly to Open Sou=


rce

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



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


no

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


n

 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=


ode

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 next 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
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 parent reply 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
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 "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
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 "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.


  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.


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


  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.


 
 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.


  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.


 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 "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
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 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 parent Sean Kelly <sean invisibleduck.org> writes:
Denis Koroskin Wrote:

 
 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?


Maybe we need a typedef! ;-)
Nov 16 2009