[ranting] Take Command Plugin, Win32Ada and Ada.Directories

[ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Hello,

For a while I work on a Plugin [1] for 4NT [2] and Take Command. I got the
first release out. Yes it lives.

This is real great fun. First there is Win32Ada. Win32 itself is a pain -
but Win32Ada makes it even worse by using library level access types
everywhere - even when anonymous access or "in out" would be far more
appropriate.

But what really saddens me is the fact that Ada 2005 still uses String for
filenames. I just found out that Ada.Directories.Search chokes on filenames
with wide characters. Since Windows uses UTF-16 for filenames even a simple
Latin-1 "ￜ" is in that group.

Anyway, if you want to have a good laugh at code using Win32Ada you can
download the sources from:

http://code.google.com/p/mkutils/downloads/list

Martin

[1] http://www.jpsoftwiki.com/wiki/index.php?title=MkUtils_%28plugin%29
[2] http://www.jpsoft.com/
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Mon, 12 Nov 2007 20:53:10 +0100, Martin Krischik wrote:

> But what really saddens me is the fact that Ada 2005 still uses String for
> filenames. I just found out that Ada.Directories.Search chokes on filenames
> with wide characters. Since Windows uses UTF-16 for filenames even a simple
> Latin-1 "�" is in that group.

Actually Windows has xxxA and xxxW versions of the API calls. Does Win32Ada
reflect that? The bindings to the xxxW subprograms should use Wide_String.
(I guess that Windows is UCS-2, not UTF-16)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov schrieb:
> On Mon, 12 Nov 2007 20:53:10 +0100, Martin Krischik wrote:
> 
>> But what really saddens me is the fact that Ada 2005 still uses String for
>> filenames. I just found out that Ada.Directories.Search chokes on filenames
>> with wide characters. Since Windows uses UTF-16 for filenames even a simple
>> Latin-1 "Ä" is in that group.
> 
> Actually Windows has xxxA and xxxW versions of the API calls. Does Win32Ada
> reflect that? The bindings to the xxxW subprograms should use Wide_String.

Yes, Win32Ada reflect this. The types used are:

----------------------------------------------------------------------
   type wchar_t is new Wide_Character;
----------------------------------------------------------------------

----------------------------------------------------------------------
   subtype Wchar_T     is Interfaces.C.wchar_t;            --  ctype.h
   subtype WCHAR       is Wchar_T;                         --  winnt.h
   type    PWCH        is access all WCHAR;                --  winnt.h
   subtype LPWCH       is PWCH;                            --  winnt.h
   subtype PWCHAR      is PWCH;                            --  winnt.h
   subtype NWPSTR      is PWCH;                            --  winnt.h
   subtype LPWSTR      is PWCH;                            --  winnt.h
   subtype PWSTR       is PWCH;                            --  winnt.h
   type    PCWCH       is access constant WCHAR;           --  winnt.h
   subtype LPCWCH      is PCWCH;                           --  winnt.h
   subtype PCWSTR      is PCWCH;                           --  winnt.h
   subtype LPCWSTR     is PCWCH;                           --  winnt.h
   type    WCHAR_Array is array (Natural range <>) of aliased WCHAR;
   Wide_Nul : constant WCHAR := WCHAR'First;
----------------------------------------------------------------------

So I use Win32.Winbase.FindFirstFileW and Win32.Winbase.FindNextFileW
instead of Ada.Directories. For the plug-in that is OK since Take
Command is only available on Windows anyway.

The problematic part is that "Win32.LPCWSTR" is used where "in
WCHAR_Array" would be more appropriate.

> (I guess that Windows is UCS-2, not UTF-16)

I don't know, the MS documentation speaks of unicode leaving the rest
uncertain.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Pascal Obry]

Dmitry A. Kazakov a �crit :
> Actually Windows has xxxA and xxxW versions of the API calls. Does Win32Ada
> reflect that? The bindings to the xxxW subprograms should use Wide_String.
> (I guess that Windows is UCS-2, not UTF-16)

AFAIK the xxxW version of the API is UTF-16.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Tue, 13 Nov 2007 22:08:17 +0100, Pascal Obry wrote:

> Dmitry A. Kazakov a �crit :

>> Actually Windows has xxxA and xxxW versions of the API calls. Does Win32Ada
>> reflect that? The bindings to the xxxW subprograms should use Wide_String.
>> (I guess that Windows is UCS-2, not UTF-16)
> 
> AFAIK the xxxW version of the API is UTF-16.

In that case I would drop the mess in Win32Ada and make a thin UTF-8 layer
above with plain String as parameters.

I would also explicitly require UTF-8 encoding for Full_Name and
Simple_Name in Ada.Directories.

(Introduction of Wide x n_String was so obvious mistake, IMO.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Pascal Obry schrieb:

> Dmitry A. Kazakov a écrit :

>> Actually Windows has xxxA and xxxW versions of the API calls. Does Win32Ada
>> reflect that? The bindings to the xxxW subprograms should use Wide_String.
>> (I guess that Windows is UCS-2, not UTF-16)

> AFAIK the xxxW version of the API is UTF-16.

Damm - that makes String <-> Wide_String conversion real fun in Windows
/ Win32Ada targets.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov schrieb:

> On Tue, 13 Nov 2007 22:08:17 +0100, Pascal Obry wrote:
> 
>> Dmitry A. Kazakov a écrit :
> 
>>> Actually Windows has xxxA and xxxW versions of the API calls. Does Win32Ada
>>> reflect that? The bindings to the xxxW subprograms should use Wide_String.
>>> (I guess that Windows is UCS-2, not UTF-16)
>> AFAIK the xxxW version of the API is UTF-16.
> 
> In that case I would drop the mess in Win32Ada and make a thin UTF-8 layer
> above with plain String as parameters.
> 
> I would also explicitly require UTF-8 encoding for Full_Name and
> Simple_Name in Ada.Directories.

Not just Ada.Directories - any package where a file name is needed.
And not just Win32 - any platform which supports UTF-8 file names.

> (Introduction of Wide x n_String was so obvious mistake, IMO.)

Introducing Wide_String but then *not* introducing it for file names was
the mistake. If only as an optional features for platforms which support
Wide_String (or Wide_Wide_Sting) file names.

In 95 it was understandable but in 2005 localised file name have become
standard and not supporting them a big mistake.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Georg Bauhaus]

Martin Krischik wrote:

> Introducing Wide_String but then *not* introducing it for file names was
> the mistake. If only as an optional features for platforms which support
> Wide_String (or Wide_Wide_Sting) file names.

package IConv is

    -- the missing link to, e.g.
    -- http://www.gnu.org/software/libiconv/

end IConv;


(Interestingly, German DIN seems to be working on a
"solution" to the "problem" of having a two-letter UCase
representation LCase of sharp s, 'ß'. A stubborn occurrence
of wannabe optimisation IMHO.

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Wed, 14 Nov 2007 09:56:42 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov schrieb:
> 
>> On Tue, 13 Nov 2007 22:08:17 +0100, Pascal Obry wrote:
>> 
>>> Dmitry A. Kazakov a �crit :
>> 
>>>> Actually Windows has xxxA and xxxW versions of the API calls. Does Win32Ada
>>>> reflect that? The bindings to the xxxW subprograms should use Wide_String.
>>>> (I guess that Windows is UCS-2, not UTF-16)
>>> AFAIK the xxxW version of the API is UTF-16.
>> 
>> In that case I would drop the mess in Win32Ada and make a thin UTF-8 layer
>> above with plain String as parameters.
>> 
>> I would also explicitly require UTF-8 encoding for Full_Name and
>> Simple_Name in Ada.Directories.
> 
> Not just Ada.Directories - any package where a file name is needed.
> And not just Win32 - any platform which supports UTF-8 file names.

Sure.

One formal problem is that Character is specified as Latin-1. Actually
Character should be Universal_Integer as nobody knows how many characters
there exist. (Still hoping their number will be at least countable. (:-))
The String element should then be Octet rather than Character.

Though, practically, I doubt that anybody would much care.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Take Command Plugin, Win32Ada and Ada.Directories

[Vadim Godunko]

On Nov 14, 12:31 pm, Georg Bauhaus <rm.tsoh
+bauh...@maps.futureapps.de> wrote:
>
> package IConv is
>
>     -- the missing link to, e.g.
>     --http://www.gnu.org/software/libiconv/
>
> end IConv;
>
This sees as too complex solution for me. Long time we are using only
Wide_Character and Wide_String in our code and bindings to the
wcstombs(3)/mbstowcs(3) functions pair for conversion between locale
multibyte (char *) strings and wide (wchar_t *) strings. This work
well on most *nix systems, I don't known does or doesn't it work on
Windows.

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Georg Bauhaus schrieb:
> Martin Krischik wrote:
> 
>> Introducing Wide_String but then *not* introducing it for file names was
>> the mistake. If only as an optional features for platforms which support
>> Wide_String (or Wide_Wide_Sting) file names.
> 
> package IConv is
> 
>    -- the missing link to, e.g.
>    -- http://www.gnu.org/software/libiconv/
> 
> end IConv;

Not very helpful for a plug-in which is supposed to run under Windows.

First a plug-in should have a small memory food print and libgnat.dll is
 bad enough as it is.

And then libiconv is a Unix-like tool.

Currently I use Ada.Characters.Conversions - but that won't be all that
useful for UTF8 <-> UTF-16 conventions. Well Win32Ada has some functions
which can do the trick - Only they are Win32 functions and as such a
pain to use.

And

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Georg Bauhaus]

On Wed, 2007-11-14 at 14:15 +0100, Martin Krischik wrote:

> > package IConv is
> > 
> >    -- the missing link to, e.g.
> >    -- http://www.gnu.org/software/libiconv/
> > 
> > end IConv;
> 
> Not very helpful for a plug-in which is supposed to run under Windows.

http://gnuwin32.sourceforge.net/packages/libiconv.htm

With .lib, .def, .a, headers, etc.


> First a plug-in should have a small memory food print and libgnat.dll is
>  bad enough as it is.
> 
> And then libiconv is a Unix-like tool.

The library API should be easy to call in programs, given
Interfaces.C.*?

Re: Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Wed, 14 Nov 2007 11:19:44 -0000, Vadim Godunko wrote:

> On Nov 14, 12:31 pm, Georg Bauhaus <rm.tsoh
> +bauh...@maps.futureapps.de> wrote:
>>
>> package IConv is
>>
>>     -- the missing link to, e.g.
>>     --http://www.gnu.org/software/libiconv/
>>
>> end IConv;
>>
> This sees as too complex solution for me. Long time we are using only
> Wide_Character and Wide_String in our code and bindings to the
> wcstombs(3)/mbstowcs(3) functions pair for conversion between locale
> multibyte (char *) strings and wide (wchar_t *) strings. This work
> well on most *nix systems, I don't known does or doesn't it work on
> Windows.

MS Visual C++ has them. In API there is MultiByteToWideChar

   http://msdn2.microsoft.com/en-us/library/ms776413.aspx,

which does not what its name suggests (should be MultiByteToMultiWORD (:-))

The problem is that Windows since NT is UTF-16, rather than UCS-2. So to
use Wide_String just makes no any sense. It is not an array of characters
anyway. Thus one could use plain String instead.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Wed, 14 Nov 2007 14:31:08 +0100, Georg Bauhaus wrote:

> The library API should be easy to call in programs, given
> Interfaces.C.*?

Except that SetWindowText (Window, "Hello!"); would become about 20-30
lines long, it is easy to call...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Georg Bauhaus]

On Wed, 2007-11-14 at 15:36 +0100, Dmitry A. Kazakov wrote:
> On Wed, 14 Nov 2007 14:31:08 +0100, Georg Bauhaus wrote:
> 
> > The library API should be easy to call in programs, given
> > Interfaces.C.*?
> 
> Except that SetWindowText (Window, "Hello!"); would become about 20-30
> lines long, it is easy to call...

Not if there will be an EAStirngs revival for Win32.
Your example should then read something like
 SetWindowText (Window, +"Hello!");

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Wed, 14 Nov 2007 16:13:05 +0100, Georg Bauhaus wrote:

> On Wed, 2007-11-14 at 15:36 +0100, Dmitry A. Kazakov wrote:
>> On Wed, 14 Nov 2007 14:31:08 +0100, Georg Bauhaus wrote:
>> 
>>> The library API should be easy to call in programs, given
>>> Interfaces.C.*?
>> 
>> Except that SetWindowText (Window, "Hello!"); would become about 20-30
>> lines long, it is easy to call...
> 
> Not if there will be an EAStirngs revival for Win32.
> Your example should then read something like
>  SetWindowText (Window, +"Hello!");

SetWindowTextW is a function that returns BOOL, instead of raising
exception. Secondly MultiByteToWideChar is again a function that returns
naturally not what you call it for. That has to be allocated first, of
unknown in advance length, of course, and then passed to
MultiByteToWideChar among other 6(!) parameters. So ugly prefix "+" does
not much help. And if we designed Win32Ada bindings from scratch it would
not be needed anyway.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Georg Bauhaus]

On Wed, 2007-11-14 at 16:35 +0100, Dmitry A. Kazakov wrote:

> >> Except that SetWindowText (Window, "Hello!"); would become about 20-30
> >> lines long, it is easy to call...
> > 
> > Not if there will be an EAStirngs revival for Win32.
> > Your example should then read something like
> >  SetWindowText (Window, +"Hello!");
> 
> SetWindowTextW 

(Windows 95/98/Me: SetWindowTextW) ?

I was assuming that "+", renaming a function from EAStrings,
would produce an object of suitable type LPCTSTR, so that the Ada
program would be calling SetWindowText (Window, +"Hello!");
The MSDN description announces SetWindowText as Unicode aware,
but then, you know more than I as to what this means.

Everything needed to produce the proper object is hidden in EAStrings
for Win32, which, on Win32, could well make use of the larger,
supported, and welcome cooperative effort, iconv. (The author does
mention iconv.)

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov wrote:

>> Not just Ada.Directories - any package where a file name is needed.
>> And not just Win32 - any platform which supports UTF-8 file names.
> 
> Sure.
> 
> One formal problem is that Character is specified as Latin-1.

Sure - but then there is allways the BOM [1] 16#EFBBBF# would mark the
string UTF-8. But I guess it would be an enormous effort to support two
file name string types - one Latin-1 and another UTF-8 - and to find out
which one you got you need the check the first 3 characters.

Martin


[1] http://en.wikipedia.org/wiki/Byte_Order_Mark
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Wed, 14 Nov 2007 14:31:08 +0100, Georg Bauhaus wrote:
> 
>> The library API should be easy to call in programs, given
>> Interfaces.C.*?
> 
> Except that SetWindowText (Window, "Hello!"); would become about 20-30
> lines long, it is easy to call...

No, not relay. With my little plug-in project it's not that bad. In fact -
out of the top of my head and current experience with Win32Ada it would be:

SetWindowTextW (Window, "Hello!" & Win32.Wide_Nul);

Have a look at the sources from the project to see how it works:

http://code.google.com/p/mkutils/

Or have a look at the Wiki;

http://www.jpsoftwiki.com/wiki/index.php?title=Plugin/Wildcard_Search

I think a similar robust C implementation would only be 20% shorter - if you
have a C compiler with alloca support - otherwise memory management will
eat up any advantage C might have hat.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Georg Bauhaus wrote:

> On Wed, 2007-11-14 at 15:36 +0100, Dmitry A. Kazakov wrote:
>> On Wed, 14 Nov 2007 14:31:08 +0100, Georg Bauhaus wrote:
>> 
>> > The library API should be easy to call in programs, given
>> > Interfaces.C.*?
>> 
>> Except that SetWindowText (Window, "Hello!"); would become about 20-30
>> lines long, it is easy to call...
> 
> Not if there will be an EAStirngs revival for Win32.
> Your example should then read something like
>  SetWindowText (Window, +"Hello!");

You forgot the null terminator - and as soon as you use "& Win32.Wide_Nul"
the compiler knows which character type is needed.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Wed, 14 Nov 2007 16:13:05 +0100, Georg Bauhaus wrote:
> 
>> On Wed, 2007-11-14 at 15:36 +0100, Dmitry A. Kazakov wrote:
>>> On Wed, 14 Nov 2007 14:31:08 +0100, Georg Bauhaus wrote:
>>> 
>>>> The library API should be easy to call in programs, given
>>>> Interfaces.C.*?
>>> 
>>> Except that SetWindowText (Window, "Hello!"); would become about 20-30
>>> lines long, it is easy to call...
>> 
>> Not if there will be an EAStirngs revival for Win32.
>> Your example should then read something like
>>  SetWindowText (Window, +"Hello!");
> 
> SetWindowTextW is a function that returns BOOL, instead of raising
> exception. Secondly MultiByteToWideChar is again a function that returns
> naturally not what you call it for. 

I know about MultiByteToWideChar - it's damn ugly indeed. But it is not
needed if you use Wide_Character to start with. Like in
Win32.WCHAR_Array'("Hello!"). You forgot about qualified expressions - they
work well with Wide_Strings.

But forgot something in my other post - most likely you need an addres  - so
it would be:

SetWindowTextW (Window, Win32.Addr ("Hello!" & Win32.Wide_Nul));

It works but if you find it wacky you can use:

Hello :  aliased constant Win32.WCHAR_Array := "Hello!" & Win32.Wide_Nul;

SetWindowTextW (Window, Win32.Addr (Hello));

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Georg Bauhaus]

On Wed, 2007-11-14 at 20:23 +0100, Martin Krischik wrote:

> > Not if there will be an EAStirngs revival for Win32.
> > Your example should then read something like
> >  SetWindowText (Window, +"Hello!");
> 
> You forgot the null terminator - and as soon as you use "& Win32.Wide_Nul"
> the compiler knows which character type is needed.

Making the string suitable for SetWindowText is the
presumed purpose of the "+" function.
But yes, "&" will do :-)

Re: Take Command Plugin, Win32Ada and Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov wrote:

> The problem is that Windows since NT is UTF-16, rather than UCS-2. So to
> use Wide_String just makes no any sense. It is not an array of characters
> anyway. Thus one could use plain String instead.

Not quite - for interfacing with C you need an null character at the end of
the string - and for UTF-16 that is easier to handle using Wide_Character
to append to a Wide_String.

Not that is would be impossible with String. Anyway - I found that
Wide_String and Wide_Character work quite well for a Win32 application.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[John W. Kennedy]

Martin Krischik wrote:
> Dmitry A. Kazakov wrote:
> 
>>> Not just Ada.Directories - any package where a file name is needed.
>>> And not just Win32 - any platform which supports UTF-8 file names.
>> Sure.
>>
>> One formal problem is that Character is specified as Latin-1.
> 
> Sure - but then there is allways the BOM [1] 16#EFBBBF# would mark the
> string UTF-8.

That's a Microsoftism. The only standard BOMs are the UTF-16 ones.
-- 
John W. Kennedy
"...when you're trying to build a house of cards, the last thing you 
should do is blow hard and wave your hands like a madman."
   --  Rupert Goodwins

Re: Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Wed, 14 Nov 2007 21:15:43 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> The problem is that Windows since NT is UTF-16, rather than UCS-2. So to
>> use Wide_String just makes no any sense. It is not an array of characters
>> anyway. Thus one could use plain String instead.
> 
> Not quite - for interfacing with C you need an null character at the end of
> the string - and for UTF-16 that is easier to handle using Wide_Character
> to append to a Wide_String.

I don't see any problem, just add NUL twice, if you convert anything
manually.

> I found that
> Wide_String and Wide_Character work quite well for a Win32 application.

Yes, this is why I thought it is UCS-2. But there exist some x % of
potential cases where it will stop working.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Wed, 14 Nov 2007 20:32:28 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Wed, 14 Nov 2007 16:13:05 +0100, Georg Bauhaus wrote:
>> 
>>> On Wed, 2007-11-14 at 15:36 +0100, Dmitry A. Kazakov wrote:
>>>> On Wed, 14 Nov 2007 14:31:08 +0100, Georg Bauhaus wrote:
>>>> 
>>>>> The library API should be easy to call in programs, given
>>>>> Interfaces.C.*?
>>>> 
>>>> Except that SetWindowText (Window, "Hello!"); would become about 20-30
>>>> lines long, it is easy to call...
>>> 
>>> Not if there will be an EAStirngs revival for Win32.
>>> Your example should then read something like
>>>  SetWindowText (Window, +"Hello!");
>> 
>> SetWindowTextW is a function that returns BOOL, instead of raising
>> exception. Secondly MultiByteToWideChar is again a function that returns
>> naturally not what you call it for. 
> 
> I know about MultiByteToWideChar - it's damn ugly indeed. But it is not
> needed if you use Wide_Character to start with.

No, the point is that this were illegal because Wide_String is UCS-2 [*].
It certainly works for the text "Hello!" (and GNAT on x86), but it would
not if the text contained any characters which cannot be represented in
UCS-2.

So the options are:

1. Wide_Wide_String
2. Wide_String encoded as UTF-16
3. String encoded as UFT-8 or else as UTF-16

The first needs conversions beyond just adding NUL. The last two are just
not Ada strings. Among these three evils the third one in UTF-8 is IMO the
least one.

-----------------------
* Which is also in question, because there is an issue of the endianness of
WCHAR vs Wide_Character.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Dmitry A. Kazakov]

On Wed, 14 Nov 2007 19:38:32 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>>> Not just Ada.Directories - any package where a file name is needed.
>>> And not just Win32 - any platform which supports UTF-8 file names.
>> 
>> Sure.
>> 
>> One formal problem is that Character is specified as Latin-1.
> 
> Sure - but then there is allways the BOM [1] 16#EFBBBF# would mark the
> string UTF-8. But I guess it would be an enormous effort to support two
> file name string types - one Latin-1 and another UTF-8 - and to find out
> which one you got you need the check the first 3 characters.

I would just drop Latin-1 and return back to 7-bit ASCII, requiring that
all Strings passed to or received from outside were UTF-8. For legacy
programs Latin-1 versions of Ada.Text_IO and Ada.Directories could be
provided as Ada.Latin_1.Text_IO etc.

(There is an issue with literals like '�'. I would make them all
Wide_Character only and provide built-in conversions from Wide to String.
Clearly all string types are convertible subtypes of some Universal_String
with unlimited-length characters.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: [ranting] Take Command Plugin, Win32Ada and Ada.Directories

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1vw3m8dqxjoo6$.10mycldk5j8pq.dlg@40tude.net...
...
> So the options are:
>
> 1. Wide_Wide_String
> 2. Wide_String encoded as UTF-16
> 3. String encoded as UFT-8 or else as UTF-16
>
> The first needs conversions beyond just adding NUL. The last two are just
> not Ada strings. Among these three evils the third one in UTF-8 is IMO the
> least one.

My recollection was that the ARG decided that the most sensible way to
handle localized file names was with UTF-8 strings (that is, Dmitry's choice
3). In that case, there is no need for new functionality and thus only
"String" is supported for file names. I recall arguing that in that case we
should provide some Wide_String <=> UTF-8 string converters, but for
whatever reason few others thought that was important.

One could imagine a UTF_8_String type, but since it would work identically
to String in all cases, it didn't seem worth the vast changes. (I felt that
way about Really_Wide_String or Wide**2_String or whatever it's called ;-0
too, but no joy there.)

                                    Randy.