Community

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.

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

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

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

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.

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

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.

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.

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

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