Ann: Ada-Win32 bindings

Ann: Ada-Win32 bindings

[alby.gamper]

Dear Ada community

I am pleased to announce the initial release of ADA bindings for the Win32 API

Available at https://github.com/Alex-Gamper/Ada-Win32

These bindings where generated from the latest Windows SDK (version 17134)
on Windows 10 x64 and include the definitions that would be available from
the following C/C++ header file

#include <SDKDDKVer.h>
#if (_MSC_VER >= 1900)
    #ifdef _WIN64
        #if _WIN32_WINNT >= _WIN32_WINNT_WINBLUE
            #include <Windows.h>
            #include <ComSvcs.h>
            #include <roapi.h>
            #include <winstring.h>
            #include <roerrorapi.h>
        #endif
    #endif
#endif

It is intended that these binding for the basis of both the Ada-WinRT
and the planned/future Ada-NetFramework bindings

Note: Their is still a bit of work to do in these bindings, specifically
1) Callbacks / function profiles need to be addressed (currently mapped to System.Address)
2) Handle inline functions ??
3) Better handling of Pre-processor macros ??

Re: Ann: Ada-Win32 bindings

[Dmitry A. Kazakov]

On 2018-08-04 02:20, alby.gamper@gmail.com wrote:

> I am pleased to announce the initial release of ADA bindings for the Win32 API

Since Win32Ada is no more public that is a welcome substitute.

Alas, to late for me. I already migrated from Win32Ada to hand-written 
small portions of Win32 API for the projects that used Win32Ada.

> Note: Their is still a bit of work to do in these bindings, specifically
> 1) Callbacks / function profiles need to be addressed (currently mapped to System.Address)
> 2) Handle inline functions ??
> 3) Better handling of Pre-processor macros ??

Yes, some are missing, e.g. MAKELANGID.

4. A- and W-forms should not be exposed, IMO. E.g. not 
CreateFileMappingA and CreateFileMapping but two overloaded 
CreateFileMapping.

5. The stuff like LPCSTR should be handled more intelligently. I know it 
is difficult, but input nul-terminated strings should also allow 
char_array (or wide equivalent) argument instead of a raw pointer to char.

6. NTSTATUS constants

7. Some Ada convenience calls, e.g.

Conversions FILTETIME <-> Ada.Calendar.Time

    procedure Raise_From_LastError
              (  ID     : Exception_ID;
                 Prefix : String     := "";
                 Error  : Error_Code := GetLastError
              );

Conversions NTSTATUS <-> ERROR_CODE etc.

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

Re: Ann: Ada-Win32 bindings

[alby.gamper]

On Saturday, August 4, 2018 at 5:10:08 PM UTC+10, Dmitry A. Kazakov wrote:
> On 2018-08-04 02:20, alby.gamper@gmail.com wrote:
> 
> > I am pleased to announce the initial release of ADA bindings for the Win32 API
> 
> Since Win32Ada is no more public that is a welcome substitute.
> 
> Alas, to late for me. I already migrated from Win32Ada to hand-written 
> small portions of Win32 API for the projects that used Win32Ada.
> 
> > Note: Their is still a bit of work to do in these bindings, specifically
> > 1) Callbacks / function profiles need to be addressed (currently mapped to System.Address)
> > 2) Handle inline functions ??
> > 3) Better handling of Pre-processor macros ??
> 
> Yes, some are missing, e.g. MAKELANGID.
> 
> 4. A- and W-forms should not be exposed, IMO. E.g. not 
> CreateFileMappingA and CreateFileMapping but two overloaded 
> CreateFileMapping.
> 
> 5. The stuff like LPCSTR should be handled more intelligently. I know it 
> is difficult, but input nul-terminated strings should also allow 
> char_array (or wide equivalent) argument instead of a raw pointer to char.
> 
> 6. NTSTATUS constants
> 
> 7. Some Ada convenience calls, e.g.
> 
> Conversions FILTETIME <-> Ada.Calendar.Time
> 
>     procedure Raise_From_LastError
>               (  ID     : Exception_ID;
>                  Prefix : String     := "";
>                  Error  : Error_Code := GetLastError
>               );
> 
> Conversions NTSTATUS <-> ERROR_CODE etc.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Hi Dmitry

Thanks for your valued response, and I mostly agree with your points, and I will
try and address these points in future release's

Note some items may need to be Hand written, but point 6 and maybe 4 should be
very doable/straight forward. I'm thinking along the lines of using ANTLR to
parse the MACRO/PRE_PROCESSOR definitions/expansions ?

Alex

Re: Ann: Ada-Win32 bindings

[Dmitry A. Kazakov]

On 2018-08-04 11:58, alby.gamper@gmail.com wrote:

> I'm thinking along the lines of using ANTLR to
> parse the MACRO/PRE_PROCESSOR definitions/expansions ?

Parsing C preprocessor could be quite tricky especially because there is 
no information about the types. So I think in the end it would be much 
easier to do them manually. If not, I would rather use a hand-written 
recursive descent parser.

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

Re: Ada-Win32 bindings

[Randy Brukardt]

Something else to link. - Randy

<alby.gamper@gmail.com> wrote in message 
news:27b53953-36f2-4efe-b877-2e316b176d80@googlegroups.com...
> Dear Ada community
>
> I am pleased to announce the initial release of ADA bindings for the Win32 
> API
>
> Available at https://github.com/Alex-Gamper/Ada-Win32
>
> These bindings where generated from the latest Windows SDK (version 17134)
> on Windows 10 x64 and include the definitions that would be available from
> the following C/C++ header file
>
> #include <SDKDDKVer.h>
> #if (_MSC_VER >= 1900)
>    #ifdef _WIN64
>        #if _WIN32_WINNT >= _WIN32_WINNT_WINBLUE
>            #include <Windows.h>
>            #include <ComSvcs.h>
>            #include <roapi.h>
>            #include <winstring.h>
>            #include <roerrorapi.h>
>        #endif
>    #endif
> #endif
>
> It is intended that these binding for the basis of both the Ada-WinRT
> and the planned/future Ada-NetFramework bindings
>
> Note: Their is still a bit of work to do in these bindings, specifically
> 1) Callbacks / function profiles need to be addressed (currently mapped to 
> System.Address)
> 2) Handle inline functions ??
> 3) Better handling of Pre-processor macros ?? 

Re: Ada-Win32 bindings

[Randy Brukardt]

<alby.gamper@gmail.com> wrote in message 
news:27b53953-36f2-4efe-b877-2e316b176d80@googlegroups.com...
> Dear Ada community
>
> I am pleased to announce the initial release of ADA bindings for the Win32 
> API

It seems bizarre to anounce the "initial release" of something that's been 
available in various forms for more than 20 years. I realize it is the the 
"initial release" of your version of these, but the ways its put heere would 
imply to outsiders that none has existed before.

I tried to get a project going to make a "standard" version of Win32 
bindings in the middle 1990s. The problem with a direct translation is the 
difficulty in dealing with String and Boolean parameters, so I had suggested 
building MAWB (pronounced "mob") - Medium Ada Windows Binding. This was a 
rote translation of the Win32 functions with a number of improvements:
(1) Ada naming and overloading rather than camel-case and hungarian names;
(2) Use of procedures that raise exceptions rather than functions that 
simply return an error result;
(3) Use of String parameters rather than LPCStr;
(4) Use of Boolean parameters and results rather than Bool.
There probably were a few other things.

This didn't generate much excitement; I only got two other people to get 
involved at all. In the end, nothing much ever got created for Ada in 
general (we still ship a version of it as part of the Janus/Ada runtime, but 
that is substantially simplified because the Janus/Ada compiler does the 
parameter changes itself, as part of pragma Import).

Eventually, we gave up on it and moved on to Claw, which is a much thicker 
binding with no attempt to copy anything of Win32.

I find a direct low-level binding nearly useless, because one has to jump 
through such hoops to do anything with it. For Claw, we just bound the 
routines we needed them as we needed them, which has the advantage that they 
can use the types of the overlying thick binding where appropriate.

Dmitry's suggestions seem to be pushing you to reinvent MAWB. It seems 
unlikely to me that it would be any more interesting now than then (although 
it may not matter if you could actually build a tool to create it -- that 
was judged to be way too expensive in the 1990s -- the effort to bind the 
entire core of Win32 was thought to be half of that of building such a 
tool).

                                                     Randy.

Re: Ada-Win32 bindings

[alby.gamper]

On Tuesday, August 7, 2018 at 8:11:38 AM UTC+10, Randy Brukardt wrote:
> <alby.gamper@gmail.com> wrote in message 
> news:27b53953-36f2-4efe-b877-2e316b176d80@googlegroups.com...
> > Dear Ada community
> >
> > I am pleased to announce the initial release of ADA bindings for the Win32 
> > API
> 
> It seems bizarre to anounce the "initial release" of something that's been 
> available in various forms for more than 20 years. I realize it is the the 
> "initial release" of your version of these, but the ways its put heere would 
> imply to outsiders that none has existed before.
> 
> I tried to get a project going to make a "standard" version of Win32 
> bindings in the middle 1990s. The problem with a direct translation is the 
> difficulty in dealing with String and Boolean parameters, so I had suggested 
> building MAWB (pronounced "mob") - Medium Ada Windows Binding. This was a 
> rote translation of the Win32 functions with a number of improvements:
> (1) Ada naming and overloading rather than camel-case and hungarian names;
> (2) Use of procedures that raise exceptions rather than functions that 
> simply return an error result;
> (3) Use of String parameters rather than LPCStr;
> (4) Use of Boolean parameters and results rather than Bool.
> There probably were a few other things.
> 
> This didn't generate much excitement; I only got two other people to get 
> involved at all. In the end, nothing much ever got created for Ada in 
> general (we still ship a version of it as part of the Janus/Ada runtime, but 
> that is substantially simplified because the Janus/Ada compiler does the 
> parameter changes itself, as part of pragma Import).
> 
> Eventually, we gave up on it and moved on to Claw, which is a much thicker 
> binding with no attempt to copy anything of Win32.
> 
> I find a direct low-level binding nearly useless, because one has to jump 
> through such hoops to do anything with it. For Claw, we just bound the 
> routines we needed them as we needed them, which has the advantage that they 
> can use the types of the overlying thick binding where appropriate.
> 
> Dmitry's suggestions seem to be pushing you to reinvent MAWB. It seems 
> unlikely to me that it would be any more interesting now than then (although 
> it may not matter if you could actually build a tool to create it -- that 
> was judged to be way too expensive in the 1990s -- the effort to bind the 
> entire core of Win32 was thought to be half of that of building such a 
> tool).
> 
>                                                      Randy.

Hi Randy

It was never intended to imply that their are no other Win32 bindings available
Developers in the Win32 space (or use Win32) are mostly aware of the AdaCore
bindings (very much outdated) and of course Claw. The "initial" release was
intended to convey the fact that its the first release, and that upcoming
additions/changes are to be expected (note the mention of Improvements in the
original post as testaments to this) Apologies for causing misunderstandings

That aside I welcomed your input and fully understand your viewpoint, but I don't
believe a direct low-level binding is nearly useless. If anything at worst case
it can form the base of thicker bindings or be used as a reference to the current
SDK version, as the other currently available bindings all seem to be outdated
and we all understand that the Win32 SDK/API will and has evolved over time

With respect to your last comment/paragraph I get the impression that you think
these bindings were NOT built by a tool? In fact they were, and the underlying
technology behind it makes it feasible to implement some if not all of your
and Dmitry's suggestions/points. My only concern with this (if fully implemented)
would be the resulting size of the bindings blowing out from 100K lines of code
to something much bigger (and the impact of usage from clients of the bindings)

Again, thanks for your and Dmitry's input, and I would like more of the Ada
community to the same and assist those with less Ada specific expertise, who
are trying to make a contribution to make "Ada cross the Chasm" thru providing
bindings like Win32, WinRT and software like Visual Studio integration.

Alex

Re: Ada-Win32 bindings

[Dan'l Miller]

On Tuesday, August 7, 2018 at 4:45:38 AM UTC-5, Alex Gamper wrote:
> On Tuesday, August 7, 2018 at 8:11:38 AM UTC+10, Randy Brukardt wrote:
> > Alex Gamper wrote in message 
> > news:27b53953-36f2-4efe-b877-2e316b176d80@googlegroups.com...
> > > Dear Ada community
> > >
> > > I am pleased to announce the initial release of ADA bindings for the Win32 
> > > API
> > 
> > It seems bizarre to anounce the "initial release" of something that's been 
> > available in various forms for more than 20 years. I realize it is the the 
> > "initial release" of your version of these, but the ways its put heere would 
> > imply to outsiders that none has existed before.
> > 
> > I tried to get a project going to make a "standard" version of Win32 
> > bindings in the middle 1990s. The problem with a direct translation is the 
> > difficulty in dealing with String and Boolean parameters, so I had suggested 
> > building MAWB (pronounced "mob") - Medium Ada Windows Binding. This was a 
> > rote translation of the Win32 functions with a number of improvements:
> > (1) Ada naming and overloading rather than camel-case and hungarian names;
> > (2) Use of procedures that raise exceptions rather than functions that 
> > simply return an error result;
> > (3) Use of String parameters rather than LPCStr;
> > (4) Use of Boolean parameters and results rather than Bool.
> > There probably were a few other things.
> > 
> > This didn't generate much excitement; I only got two other people to get 
> > involved at all. In the end, nothing much ever got created for Ada in 
> > general (we still ship a version of it as part of the Janus/Ada runtime, but 
> > that is substantially simplified because the Janus/Ada compiler does the 
> > parameter changes itself, as part of pragma Import).
> > 
> > Eventually, we gave up on it and moved on to Claw, which is a much thicker 
> > binding with no attempt to copy anything of Win32.
> > 
> > I find a direct low-level binding nearly useless, because one has to jump 
> > through such hoops to do anything with it. For Claw, we just bound the 
> > routines we needed them as we needed them, which has the advantage that they 
> > can use the types of the overlying thick binding where appropriate.
> > 
> > Dmitry's suggestions seem to be pushing you to reinvent MAWB. It seems 
> > unlikely to me that it would be any more interesting now than then (although 
> > it may not matter if you could actually build a tool to create it -- that 
> > was judged to be way too expensive in the 1990s -- the effort to bind the 
> > entire core of Win32 was thought to be half of that of building such a 
> > tool).
> > 
> >                                                      Randy.
> 
> Hi Randy
> 
> It was never intended to imply that their are no other Win32 bindings available
> Developers in the Win32 space (or use Win32) are mostly aware of the AdaCore
> bindings (very much outdated) and of course Claw. The "initial" release was
> intended to convey the fact that its the first release, and that upcoming
> additions/changes are to be expected (note the mention of Improvements in the
> original post as testaments to this) Apologies for causing misunderstandings
> 
> That aside I welcomed your input and fully understand your viewpoint, but I don't
> believe a direct low-level binding is nearly useless. If anything at worst case
> it can form the base of thicker bindings or be used as a reference to the current
> SDK version, as the other currently available bindings all seem to be outdated
> and we all understand that the Win32 SDK/API will and has evolved over time
> 
> With respect to your last comment/paragraph I get the impression that you think
> these bindings were NOT built by a tool? In fact they were, and the underlying
> technology behind it makes it feasible to implement some if not all of your
> and Dmitry's suggestions/points. My only concern with this (if fully implemented)
> would be the resulting size of the bindings blowing out from 100K lines of code
> to something much bigger (and the impact of usage from clients of the bindings)
> 
> Again, thanks for your and Dmitry's input, and I would like more of the Ada
> community to the same and assist those with less Ada specific expertise, who
> are trying to make a contribution to make "Ada cross the Chasm" thru providing
> bindings like Win32, WinRT and software like Visual Studio integration.
> 
> Alex

Alex, do what •you• think is best.  I am a strong believer in multiple competing alternatives, producing a Darwinian survival-of-the-fittest outcome.  (And by that I mean survival of the fittest ideas/designs within a library/framework/code-generator, not the brandname itself nor the deployed package itself nor the vendor itself.)  For example, what is best for a handcrafted UI/UX library/framework might be completely different than what is best for a code-generated UI/UX library/framework.  Permissive licensing versus viral licensing alone might be a major survival-of-the-fittest differentiator.

I once worked for a company that always intentionally started 2 or 3 competing-but-different products (or different designs for substantially the nearly-the-same product).  About 2 years into the product, they would kill off all but the strongest single one, promote the victors' engineers, and merge in the killed-off product's engineers into not-seniormost positions in the victor.  It was a beautiful meritocracy to behold.

Re: Ada-Win32 bindings

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:2d07e544-8e98-458c-894c-cdd898f29440@googlegroups.com...
...
>Alex, do what .you. think is best.  I am a strong believer in multiple 
>competing
>alternatives, producing a Darwinian survival-of-the-fittest outcome.

For thicker bindings, that's probably good advice. For a low-level bindings, 
however, ones that aren't going to be very usable from Ada regardless of 
details, probably the best thing is to standardize on a single set and stick 
to it. The reason being that it is a a foundation that all of those thicker 
bindings are built on, and it's best if that's a portable solution that 
itself changes hardly ever.

(One could even argue that exposing low-level bindings at all just puts Ada 
in a bad light, since they're harder to use than in C, but provide no more 
safety. You need at least medium or better still thick bindings to make them 
usable in Ada and to provide that safety.)

                                                  Randy.

Re: Ada-Win32 bindings

[Randy Brukardt]

<alby.gamper@gmail.com> wrote in message 
news:5c836355-2938-4cde-a03f-f7ee9f3ff2ee@googlegroups.com...
...
> With respect to your last comment/paragraph I get the impression that you 
> think
> these bindings were NOT built by a tool?

I was commenting on MAWB (won't have needed help if spending months on a 
tool was a serious option - since such a thing requires essentially building 
half of a C compiler). I had no idea how you made your bindings.

> In fact they were, and the underlying
> technology behind it makes it feasible to implement some if not all of 
> your
> and Dmitry's suggestions/points. My only concern with this (if fully 
> implemented)
> would be the resulting size of the bindings blowing out from 100K lines of 
> code
> to something much bigger (and the impact of usage from clients of the 
> bindings)

90% of Microsoft's bindings are of little interest to anyone. They tend to 
introduce a new API frequently, often for purposes that never get any 
traction with anyone. So long as your bindings are well-organized, the sheer 
volume is rather irrelevant, since most users will stick with just a handful 
of packages.

For a low level binding like this (which is going to be used mainly as a 
foundation for better things), probably the most important feature is 
compatibility. That is, newer versions of the binding need to change as 
little as possible about existing APIs, because breaking things all the time 
will make one no friends. (Ask Dmitry about GTK versions. :-) That's likely 
to be a struggle with a tool-generated binding.

                                   Randy.

Re: Ann: Ada-Win32 bindings

[Aurele Vitali]

Good job, but A bit late. In an effort to get away from Win32ada, I wrote my own bindings. But everything does seems to check out!

Re: Ann: Ada-Win32 bindings

[alby.gamper]

On Wednesday, August 8, 2018 at 1:38:13 AM UTC+10, Aurele Vitali wrote:
> Good job, but A bit late. In an effort to get away from Win32ada, I wrote my own bindings. But everything does seems to check out!

Hi Aurele

Thanks for your response, It seems that Dmitry, yourself and I were equally
frustrated with the lack of a feature rich API binding to Win32 and ended
up writing our own (via cherry picking off the features we needed for our
specific needs/purposes)

This is somewhat why this project originated! In that I was frustrated with
having to manually go thru MS C/C++ header files to get the correct definition
of an enum/record/function/procedure etc... and translating that to Ada, I
wanted / needed a better solution!

I fully acknowledge everyone has different needs (wrt usage of the Win32 API)
and that a binding either thin or thick should not focus on a specific area
of the API such as the GUI components. and try and provide the core functions
that the Win32 API provides (along with providing type safety thru a thicker
binding ! as Randy has already mentioned) To this end, I believe this binding
is the first step in achieving that goal.

Thanks Alex

Re: Ann: Ada-Win32 bindings

[Aurele Vitali]

As you suspected Alex, the thin binding I wrote is but a subset of the full Windows API and its mainly based on the Windows 7 and/or 8.   So to you I say, good job if you were able to capture the complete Windows API.   
 
For my Windows GUI needs, my thin binding is limited to these API specs:
 
Win32.ads, Windef.ads, Winuser.ads, Wingdi.ads, Winnt.ads, Commctrl.ads, Commdlg.ads, PrSht.ads, Shellapi.ads, Winbase.ads, Wincon.ads, Winreg.ads and others.

Each are complete in themselves and they do I need. As a note, I found the real test of a binding is when you actually start using it. 

Cheers Alex o/

Re: Ann: Ada-Win32 bindings

[Jere]

On Friday, August 3, 2018 at 8:20:26 PM UTC-4, alby....@gmail.com wrote:
> Dear Ada community
> 
> I am pleased to announce the initial release of ADA bindings for the Win32 API
> 
> Available at https://github.com/Alex-Gamper/Ada-Win32
> 
> These bindings where generated from the latest Windows SDK (version 17134)
> on Windows 10 x64 and include the definitions that would be available from
> the following C/C++ header file
> 
> #include <SDKDDKVer.h>
> #if (_MSC_VER >= 1900)
>     #ifdef _WIN64
>         #if _WIN32_WINNT >= _WIN32_WINNT_WINBLUE
>             #include <Windows.h>
>             #include <ComSvcs.h>
>             #include <roapi.h>
>             #include <winstring.h>
>             #include <roerrorapi.h>
>         #endif
>     #endif
> #endif
> 
> It is intended that these binding for the basis of both the Ada-WinRT
> and the planned/future Ada-NetFramework bindings
> 
> Note: Their is still a bit of work to do in these bindings, specifically
> 1) Callbacks / function profiles need to be addressed (currently mapped to System.Address)
> 2) Handle inline functions ??
> 3) Better handling of Pre-processor macros ??

Thanks for making this and providing it to the community!