December 01, 2006
Don Clugston wrote:
> There's a horrible effect in C++ Windows where there's lots of code which has #ifdef __MSVC__, even though it works on many other compilers.
> So vendors like CodePlay and Metrowerks fraudulently define __MSVC__.

That's just the start. I often find #ifdef WINDOWS when it's a compiler dependency, not a Windows dependency. Same for linux/__GNUC__

> I hope we can avoid this in D.

So do I.

> I've already seen some uses of
> DigitalMars_Inline_Asm
> because GDC doesn't support the full set of x86 opcodes. I think failure to implement the spec should always be tested with a positive. Certainly code should never have a list of compilers which meet the spec!
> 
> And if a vendor knows that they're not implementing part of the spec, they should provide an identifier indicating that fact. That way, the vendor can fix the problem without breaking existing code.

Yes.
December 02, 2006
Tomas Lindquist Olsen wrote:

> I've been looking at unicode support for MinWin in Windows.
> 
> From minwin/todo:
> * mswindows
>  - A vs W for string inputs - convert to wchar
> 
> It seems that sticking with char[] and only doing the toUTF16z conversions under the hood is the most feasible.
> 
> I have attached a patch (made with tortoiseSVN) that makes minwin/button.d work with unicode. It adds a few W functions to minwin/mswindows.d as well.
> 
> Is there a better way?
> Feedback is much appreciated, I think MinWin should support unicode
> properly, and it's not that much work with this approach.
> 
> Does unicode work with GTK/Motif?
> 
> -- Tomas

Not sure whether the MinWin forum or this newsgroup is the right place for the discussion, but I'm looking for feedback on this:

http://www.dsource.org/forums/viewtopic.php?t=2096

-- Tomas

December 02, 2006
Tomas Lindquist Olsen wrote:
> Tomas Lindquist Olsen wrote:
> 
> 
>>I've been looking at unicode support for MinWin in Windows.
>>
>>From minwin/todo:
>>* mswindows
>> - A vs W for string inputs - convert to wchar
>>
>>It seems that sticking with char[] and only doing the toUTF16z
>>conversions under the hood is the most feasible.
>>
>>I have attached a patch (made with tortoiseSVN) that makes
>>minwin/button.d work with unicode. It adds a few W functions to
>>minwin/mswindows.d as well.
>>
>>Is there a better way?
>>Feedback is much appreciated, I think MinWin should support unicode
>>properly, and it's not that much work with this approach.
>>
>>Does unicode work with GTK/Motif?
>>
>>-- Tomas
> 
> 
> Not sure whether the MinWin forum or this newsgroup is the right place
> for the discussion, but I'm looking for feedback on this:
> 
> http://www.dsource.org/forums/viewtopic.php?t=2096
> 
> -- Tomas
> 

Do you care about Win95?  If so then I recall there are some limitations to using unicode there, and you need something called unicows.dll to make it work at all.  I think unicows only supports a subset of the win32 api.

Personally I don't care about Win95, but apparently a lot of people still do.

If you don't care about Win95, then I believe you're right that the -W functions are the way to go.

[btw I'm not a big fan of forums... but I also realize it doesn't make sense to have dozens of project-specific threads going on here -- especially when 'here' is the "announce" newsgroup ;-)  Can DSource host mailing lists?  Could Walter host project-specific newsgroups?]

--bb
December 02, 2006
> Do you care about Win95?  If so then I recall there are some limitations to using unicode there, and you need something called unicows.dll to make it work at all.  I think unicows only supports a subset of the win32 api.
>
> Personally I don't care about Win95, but apparently a lot of people still do.
>
> If you don't care about Win95, then I believe you're right that the -W functions are the way to go.

It also applies to Windows 95 and ME, which I believe still have a chunk of users. MSLU is an option but is a dependency.
December 03, 2006
Chris Miller wrote:
>> Do you care about Win95?  If so then I recall there are some limitations to using unicode there, and you need something called unicows.dll to make it work at all.  I think unicows only supports a subset of the win32 api.
>>
>> Personally I don't care about Win95, but apparently a lot of people still do.
>>
>> If you don't care about Win95, then I believe you're right that the -W functions are the way to go.
> 
> It also applies to Windows 95 and ME, which I believe still have a chunk of users. MSLU is an option but is a dependency.

Don't use MSLU to support 95 and ME. Look into how std.file does it, that's the right way for D.
December 03, 2006
Walter Bright wrote:
> 
> Don't use MSLU to support 95 and ME. Look into how std.file does it, that's the right way for D.

Thanx for the tip Walter.

I'm redoing the patch this way. With a few wrappers though or the code gets very ugly...

-- 

December 03, 2006
On Sat, 02 Dec 2006 20:09:41 -0500, Walter Bright <newshound@digitalmars.com> wrote:

> Chris Miller wrote:
>>> Do you care about Win95?  If so then I recall there are some limitations to using unicode there, and you need something called unicows.dll to make it work at all.  I think unicows only supports a subset of the win32 api.
>>>
>>> Personally I don't care about Win95, but apparently a lot of people still do.
>>>
>>> If you don't care about Win95, then I believe you're right that the -W functions are the way to go.
>>  It also applies to Windows 95 and ME, which I believe still have a chunk of users. MSLU is an option but is a dependency.
>
> Don't use MSLU to support 95 and ME. Look into how std.file does it, that's the right way for D.

I meant to say 98 and ME, and I agree that how std.file does it is better, it's how I usually do it, e.g. in DFL. However, if a library has less interest in supporting win9x/ME, and more interest in simplifying unicode, it may be easier to just use MSLU, even though I personally probably still wouldn't, but it's still an option.
December 03, 2006
Chris Miller wrote:
> I meant to say 98 and ME, and I agree that how std.file does it is better, it's how I usually do it, e.g. in DFL. However, if a library has less interest in supporting win9x/ME, and more interest in simplifying unicode, it may be easier to just use MSLU, even though I personally probably still wouldn't, but it's still an option.

It's an option, but a poor one. MSLU doesn't actually add unicode support. It just provides translations just like std.file does. And worse, it requires you to ship the MSLU dll with your product, which makes it a nuisance for customers.
December 03, 2006
Walter Bright wrote:

> Chris Miller wrote:
> > > Do you care about Win95?  If so then I recall there are some limitations to using unicode there, and you need something called unicows.dll to make it work at all.  I think unicows only supports a  subset of the win32 api.
> > > 
> > > Personally I don't care about Win95, but apparently a lot of people  still do.
> > > 
> > > If you don't care about Win95, then I believe you're right that the -W  functions are the way to go.
> > 
> > It also applies to Windows 95 and ME, which I believe still have a chunk  of users. MSLU is an option but is a dependency.
> 
> Don't use MSLU to support 95 and ME. Look into how std.file does it, that's the right way for D.

I have committed the Unicode update for Windows to SVN :) Thanx again for pointing out how it should be done!

-- 

December 03, 2006
Tomas Lindquist Olsen wrote:
> Walter Bright wrote:
> 
> 
>>Chris Miller wrote:
>>
>>>>Do you care about Win95?  If so then I recall there are some
>>>>limitations to using unicode there, and you need something called
>>>>unicows.dll to make it work at all.  I think unicows only
>>>>supports a  subset of the win32 api.
>>>>
>>>>Personally I don't care about Win95, but apparently a lot of
>>>>people  still do.
>>>>
>>>>If you don't care about Win95, then I believe you're right that
>>>>the -W  functions are the way to go.
>>>
>>>It also applies to Windows 95 and ME, which I believe still have a
>>>chunk  of users. MSLU is an option but is a dependency.
>>
>>Don't use MSLU to support 95 and ME. Look into how std.file does it,
>>that's the right way for D.
> 
> 
> I have committed the Unicode update for Windows to SVN :)
> Thanx again for pointing out how it should be done!
> 

And I can confirm that Japanese works now!  Yea!
 (though without in-place IME support, but that's a separate kettle o fish)

--bb