Ada interacting with Windows 8.1+ GUI

Ada interacting with Windows 8.1+ GUI

[Donar]

Hi all,

how would I show a window on Windows 8.1 on 64 bit Intels, and how would I process the message loop? 

Regards,
Donae

Re: Ada interacting with Windows 8.1+ GUI

[gautier_niouzes]

> how would I show a window on Windows 8.1 on 64 bit Intels, and how would I process the message loop? 

Are you using GNAT? Then GWindows is what you need.

https://sourceforge.net/projects/gnavi/

Enjoy!
Gautier

Re: Ada interacting with Windows 8.1+ GUI

[herbert.glarner]

> https://sourceforge.net/projects/gnavi/

Thanks Gautier,

however, judging from the documentation it seems that Gnavi is pretty dated: I see a lot of 32 bit and 95/NT references.

Also, the foot line on 
http://www.gnavi.org/index.php?Command=classes&Title=The+GNAVI+Project
reads:
(c) 1999-2004

Thus I doubt that Gnavi is still maintained, or do I err?

I am just beginning to dvelve into Ada and am working through Barnes' "Programming in Ada 2012", but target systems are 64 bitters using Win 8.1+, so I need a "modern access". 

How would I access Windows API functions on their own?



(Gruess us Schaffuse)

Re: Ada interacting with Windows 8.1+ GUI

[G. B.]

<herbert.glarner@bluewin.ch> wrote:

> I am just beginning to dvelve into Ada and am working through Barnes'
> "Programming in Ada 2012", but target systems are 64 bitters using Win
> 8.1+, so I need a "modern access". 
> 
> How would I access Windows API functions on their own?

One modern way of writing Windows programs im Ada is using .NET. So, one
could consider GNAT for .NET. Its name is A#.

Re: Ada interacting with Windows 8.1+ GUI

[gautier_niouzes]

> > https://sourceforge.net/projects/gnavi/

> Thus I doubt that Gnavi is still maintained, or do I err?

The GWindows framework is maintained (by me :-) ), only the *gnavi.org* site is (very) outdated.
If you download the installer (or get the code from SVN or Git) you have the latest status, with documentation.
If you compile your applications with a 64-bit-targetting GNAT, it will produce 64-bit executables.
It works on Windows 10 too. Basically you can span everything from Windows 95 to Windows 10, and for 32 and 64 bit (for the Windows versions supporting 64 bit).

Re: Ada interacting with Windows 8.1+ GUI

[rabbibotton]

I'll be updated the site soon to point to the active project.

Re: Ada interacting with Windows 8.1+ GUI

[rabbibotton]

> I'll be updated the site soon to point to the active project.

done

Re: Ada interacting with Windows 8.1+ GUI

[Björn Lundin]

On 2018-10-11 16:42, gautier_niouzes@hotmail.com wrote:
>>> https://sourceforge.net/projects/gnavi/
> 
>> Thus I doubt that Gnavi is still maintained, or do I err?
> 
> The GWindows framework is maintained (by me :-) ), only the *gnavi.org* site is (very) outdated.
> If you download the installer (or get the code from SVN or Git) you have the latest status, with documentation.
> If you compile your applications with a 64-bit-targetting GNAT, it will produce 64-bit executables.
> It works on Windows 10 too. Basically you can span everything from Windows 95 to Windows 10, and for 32 and 64 bit (for the Windows versions supporting 64 bit).
> 

And there is a mail-list which has been of great help to me,
when I used gwindows.

(gnavi-discuss at lists.sourceforge.net)

Especially Gautier was really helpful


-- 
--
Björn

Re: Ada interacting with Windows 8.1+ GUI

[alby.gamper]

On Friday, October 12, 2018 at 1:42:43 AM UTC+11, gautier...@hotmail.com wrote:
> > > https://sourceforge.net/projects/gnavi/
> 
> > Thus I doubt that Gnavi is still maintained, or do I err?
> 
> The GWindows framework is maintained (by me :-) ), only the *gnavi.org* site is (very) outdated.
> If you download the installer (or get the code from SVN or Git) you have the latest status, with documentation.
> If you compile your applications with a 64-bit-targetting GNAT, it will produce 64-bit executables.
> It works on Windows 10 too. Basically you can span everything from Windows 95 to Windows 10, and for 32 and 64 bit (for the Windows versions supporting 64 bit).

Hi Gautier

What are your thoughts on moving Gnavi to GitHub ?

Alex

BTW: Nice work, I haven't tried your release, But found numerous errors in
the original 'gnavi.org' outdated release (specifically relating to the assumption
that the system was 32 bit based)

I assume that your version of Gnavi compiles cleanly using GNAT FSF x64
or the latest AdaCore community edition 2018 (which targets x64)

Re: Ada interacting with Windows 8.1+ GUI

[gautier_niouzes]

Le samedi 13 octobre 2018 08:30:35 UTC+2, alby....@gmail.com a écrit :

> Hi Gautier
> 
> What are your thoughts on moving Gnavi to GitHub ?

It's already (mirrored) on GitHub :-)
https://github.com/svn2github/gnavi

> BTW: Nice work, I haven't tried your release, But found numerous errors in
> the original 'gnavi.org' outdated release (specifically relating to the assumption
> that the system was 32 bit based)

Sure. With the version downloaded on gnavi.org you miss 14 years (i.e. 367 commits) of updates!...

> I assume that your version of Gnavi compiles cleanly using GNAT FSF x64
> or the latest AdaCore community edition 2018 (which targets x64)

Latest release was fully built and tested on GNAT GPL 2017 (32 bit), Community 2018 (64 bit).
For some projects (e.g. AZip - http://azip.sf.net ) I use TDM-GCC 5.1.0 (32 bit).
And a few months ago I've built and tested a complete application on the 64 bit TDM-GCC.

Re: Ada interacting with Windows 8.1+ GUI

[alby.gamper]

On Saturday, October 13, 2018 at 10:50:07 PM UTC+11, gautier...@hotmail.com wrote:
> Le samedi 13 octobre 2018 08:30:35 UTC+2, alby....@gmail.com a écrit :
> 
> > Hi Gautier
> > 
> > What are your thoughts on moving Gnavi to GitHub ?
> 
> It's already (mirrored) on GitHub :-)
> https://github.com/svn2github/gnavi
> 
> > BTW: Nice work, I haven't tried your release, But found numerous errors in
> > the original 'gnavi.org' outdated release (specifically relating to the assumption
> > that the system was 32 bit based)
> 
> Sure. With the version downloaded on gnavi.org you miss 14 years (i.e. 367 commits) of updates!...
> 
> > I assume that your version of Gnavi compiles cleanly using GNAT FSF x64
> > or the latest AdaCore community edition 2018 (which targets x64)
> 
> Latest release was fully built and tested on GNAT GPL 2017 (32 bit), Community 2018 (64 bit).
> For some projects (e.g. AZip - http://azip.sf.net ) I use TDM-GCC 5.1.0 (32 bit).
> And a few months ago I've built and tested a complete application on the 64 bit TDM-GCC.

Hi Gautier

Thank you for the quick and detailed response, When I have time, I will have
another look at Gnavi/Gnatcom (more detailed, this time)

Alex

BTW, Feel free to have a look at some of my projects on GitHub, they may
be of interest to you ( https://github.com/Alex-Gamper )

Re: Ada interacting with Windows 8.1+ GUI

[gautier_niouzes]

> One modern way of writing Windows programs im Ada is using .NET. So, one
> could consider GNAT for .NET. Its name is A#.

Do you know a working or up-to-date GNAT for .NET?
The thing with .NET is that is is soon 20 years old, so the marketing effect is fading a bit. Marketing aside, it is just a tool for making applications massively slower and installation more complicated...

Re: Ada interacting with Windows 8.1+ GUI

[Olivier Henley]

Hi,

I am writing an Ada equivalent of GLFW3 and the MS window handling + GL context is actually working. 

The code is almost the bear minimum to 'natively' handle a MS window (Ada wrapping Microsoft C core functions). I recommend you check my implementation as a starter.

The lib:
https://github.com/ohenley/aglw

A working demo, client using the lib:
https://github.com/ohenley/aglw-demos

olivier

Re: Ada interacting with Windows 8.1+ GUI

[Olivier Henley]

On Thursday, October 25, 2018 at 1:19:29 PM UTC-4, Olivier Henley wrote:
> Hi,
> 
> I am writing an Ada equivalent of GLFW3 and the MS window handling + GL context is actually working. 
> 
> The code is almost the bear minimum to 'natively' handle a MS window (Ada wrapping Microsoft C core functions). I recommend you check my implementation as a starter.
> 
> The lib:
> https://github.com/ohenley/aglw
> 
> A working demo, client using the lib:
> https://github.com/ohenley/aglw-demos
> 
> olivier

The windows type definition comes from Adacore win32ada. In the example dir they have working sample that play with native windows, drawing etc.

Note: Anyhow, I plan on isolating only the type definitions needed to handle the window stuff and drop the rest. For me, to bring the whole win32 interface is overkill. But the needed stuff is all used aglw/main/src/win32/aglw-windows.adb

Another 'slim' reference is the Lumen project: https://github.com/karakalo/lumen 
  

Re: Ada interacting with Windows 8.1+ GUI

[joakimds]

> Note: Anyhow, I plan on isolating only the type definitions needed to handle the window stuff and drop the rest. For me, to bring the whole win32 interface is overkill.

Isn't it easy for the compiler to optimize away/remove the code that is not used? Also I can imagine that the packages of the win32 interface is code that has been written and as a developer one only uses it which means it is only compiled once and no re-compilation needed.

When writing an Ada binding to a C library, consider the following two options:
1. Put all the source code in a package A.
2. Divide the source code into several packages, for example create an empty package A and divide the source code into several child packages A.B, A.C, A.D, ...

Let's imagine there is a type called Window. In solution 1 one writes "A.Window" to specify it and in solution 2 one maybe writes "A.D.Window".
Solution 1 makes the code less verbose and puts more responsibility on the compiler to be able to remove unused code. Solution 2 makes the source code more verbose but makes it easier for an Ada compiler to avoid including unused source code in the resulting executable. When I have been thinking about this I've thought "let's assume the compiler is really good and let's go for minimalistic Ada code". Solution 2 is sometimes advertised as one of the selling points of Ada to be able to describe structure of an Ada binding. Currently I am exploring solution 1 when writing Ada code, but "the ultimate way to structure code" is still an open question for me.

Best regards,
Joakim

Re: Ada interacting with Windows 8.1+ GUI

[Simon Wright]

joakimds@kth.se writes:

> Isn't it easy for the compiler to optimize away/remove the code that
> is not used?

Not so much in a library package where some subprograms don't have to be
used by the overall program.

You can compile with -ffunction-sections -fdata-sections which say each
subprogram/data object resp. is to have its own section. If your linker
supports (the equivalent of) -gc-sections. linking with it means that
only the used sections get linked. This is fine for (arm-eabi) embedded
systems & (probably) Linux. which use GNU ld, but not on macOS. Can't
say for Windows.

GNAT provides gnatelim, which analyses your code and (?) regenerates it
without the unused objects. No idea how well this works.

Re: Ada interacting with Windows 8.1+ GUI

[gautier_niouzes]

Am Freitag, 26. Oktober 2018 11:19:24 UTC+2 schrieb Simon Wright:

> You can compile with -ffunction-sections -fdata-sections which say each
> subprogram/data object resp. is to have its own section. If your linker
> supports (the equivalent of) -gc-sections. linking with it means that
> only the used sections get linked. This is fine for (arm-eabi) embedded
> systems & (probably) Linux. which use GNU ld, but not on macOS. Can't
> say for Windows.

It does something visible in terms of executable size.

> GNAT provides gnatelim, which analyses your code and (?) regenerates it
> without the unused objects. No idea how well this works.

gnatelim produces a file with a list of pragmata like:
pragma Eliminate (Zip, Traverse, Source_Location => "zip.adb:514");

On the next build GNAT will see the subprogram's code as blank lines.
gnatelim reduces further the executable size (on Windows; which means that -gc-sections is not fully efficient). The downside is that the list is quickly outdated, you need to rebuild it often.

Re: Ada interacting with Windows 8.1+ GUI

[Bill Findlay]

On 26 Oct 2018, Simon Wright wrote
(in article <lyin1pjca1.fsf@pushface.org>):

> joakimds@kth.se writes:
>
> > Isn't it easy for the compiler to optimize away/remove the code that
> > is not used?
>
> Not so much in a library package where some subprograms don't have to be
> used by the overall program.
>
> You can compile with -ffunction-sections -fdata-sections which say each
> subprogram/data object resp. is to have its own section. If your linker
> supports (the equivalent of) -gc-sections. linking with it means that
> only the used sections get linked. This is fine for (arm-eabi) embedded
> systems &  (probably) Linux. which use GNU ld, but not on macOS. Can't
> say for Windows.
>
> GNAT provides gnatelim, which analyses your code and (?) regenerates it
> without the unused objects. No idea how well this works.

Does :

-Wl,-dead_strip -Wl,-dead_strip

not work on macOS instead of:

-Wl,--gc-sections -Wl,--as-needed

?

-- 
Bill Findlay

Re: Ada interacting with Windows 8.1+ GUI

[Simon Wright]

Bill Findlay <findlaybill@blueyonder.co.uk> writes:

> On 26 Oct 2018, Simon Wright wrote
> (in article <lyin1pjca1.fsf@pushface.org>):
>
>> joakimds@kth.se writes:
>>
>> > Isn't it easy for the compiler to optimize away/remove the code that
>> > is not used?
>>
>> Not so much in a library package where some subprograms don't have to be
>> used by the overall program.
>>
>> You can compile with -ffunction-sections -fdata-sections which say each
>> subprogram/data object resp. is to have its own section. If your linker
>> supports (the equivalent of) -gc-sections. linking with it means that
>> only the used sections get linked. This is fine for (arm-eabi) embedded
>> systems &  (probably) Linux. which use GNU ld, but not on macOS. Can't
>> say for Windows.
>>
>> GNAT provides gnatelim, which analyses your code and (?) regenerates it
>> without the unused objects. No idea how well this works.
>
> Does :
>
> -Wl,-dead_strip -Wl,-dead_strip
>
> not work on macOS instead of:

I don't think you have to say it twice! - but, yes, thanks

> -Wl,--gc-sections -Wl,--as-needed

I wasn't aware of --as-needed. Seems only to eliminate whole shared
libraries, not an issue on arm-eabi!

Re: Ada interacting with Windows 8.1+ GUI

[Bill Findlay]

On 26 Oct 2018, Simon Wright wrote
(in article <lyefcckenz.fsf@pushface.org>):

> Bill Findlay<findlaybill@blueyonder.co.uk>  writes:
>
> > On 26 Oct 2018, Simon Wright wrote
> > (in article <lyin1pjca1.fsf@pushface.org>):
> >
> > > joakimds@kth.se writes:
> > >
> > > > Isn't it easy for the compiler to optimize away/remove the code that
> > > > is not used?
> > >
> > > Not so much in a library package where some subprograms don't have to be
> > > used by the overall program.
> > >
> > > You can compile with -ffunction-sections -fdata-sections which say each
> > > subprogram/data object resp. is to have its own section. If your linker
> > > supports (the equivalent of) -gc-sections. linking with it means that
> > > only the used sections get linked. This is fine for (arm-eabi) embedded
> > > systems &  (probably) Linux. which use GNU ld, but not on macOS. Can't
> > > say for Windows.
> > >
> > > GNAT provides gnatelim, which analyses your code and (?) regenerates it
> > > without the unused objects. No idea how well this works.
> >
> > Does :
> >
> > -Wl,-dead_strip -Wl,-dead_strip
> >
> > not work on macOS instead of:
>
> I don't think you have to say it twice! - but, yes, thanks

I was under the impression you had to say it separately for
data-sections and function-sections, but I could easily be wrong.

-- 
Bill Findlay

Re: Ada interacting with Windows 8.1+ GUI

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyin1pjca1.fsf@pushface.org...
> joakimds@kth.se writes:
>
>> Isn't it easy for the compiler to optimize away/remove the code that
>> is not used?
>
> Not so much in a library package where some subprograms don't have to be
> used by the overall program.

It's definitely not easy, but it is possible.

...
> GNAT provides gnatelim, which analyses your code and (?) regenerates it
> without the unused objects. No idea how well this works.

Janus/Ada has a /T option that keeps extra information with the code so that 
unused library-level subprograms can be eliminated. Since we invented Claw, 
it can even eliminate unused primitive subprograms of tagged types (since 
these are referenced from the type tag, they always appear used; the linker 
has to prove that there are no dispatching calls for a particular "slot" in 
order to remove them). (That reduces the default size of a Claw program from 
1.4MB to about 0.45MB.)

This was on an option because we were concerned about the extra binding time 
required; however, it turns out to work so well that it is the default on 
Windows (and indeed, one can't link a Windows program without it, as 
otherwise one ends up with symbols not defined on whatever version of 
Windows you have - since the basic runtime defines the union of all of those 
versions).

But Janus/Ada can do this because it handles all of the linking/binding for 
the Ada code itself. (That is then fed into the Microsoft linker to link 
with the Win32 API and any foreign language code.) Conventionally linked 
code would make that very hard.

                                        Randy.