From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!nzpost2.xs4all.net!news.kpn.nl!not-for-mail Subject: Re: Hardware independent programming Newsgroups: comp.lang.ada References: <5ef9712d$0$1221$e4fe514c@news.kpn.nl> From: ldries46 Date: Tue, 30 Jun 2020 08:28:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5ef9712d$0$1221$e4fe514c@news.kpn.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Message-ID: <5efadba5$0$1220$e4fe514c@news.kpn.nl> NNTP-Posting-Host: 01930249.news.kpn.nl X-Trace: G=wAtPM4gH,C=U2FsdGVkX1+h0B38/6Q3V98qsd3QcJbxKfXX3VZyk/5KtSjvMYv/BqQH8VQKH+Mu8VZ0yf915fKz6G2nrSkm9z3oRhEjLRaYIKrNLNFy18Q= X-Complaints-To: abuse@kpn.nl Xref: reader01.eternal-september.org comp.lang.ada:59254 List-Id: Op 29-6-2020 om 6:42 schreef ldries46: > Hardware can in some cases have limits you have to consider when > writing a program. >  At this moment I can mention three: > > 1. The printer. The format of the documents you want to print must fit >    on the printers available to the user. In general the problem is >    solved by the possibility of printer drivers to shrink you document >    f.i. from A4 to A4 or saving the document to a file that can be >    printed elsewhere. > 2. The monitor on the system your program is running. Creating a window >    that is to large for your screen resolution can be trouble some but >    you do not know the resolution of the the customer using your >    program. The solution for such a problem can only be hardware >    independent programming. Your program should know the resolution of >    your screen and adjust to  that or in the worst case decide that >    system is not suitable for the program. > 3. The available memory. Your program will in some cases need to know >    the limits to which the heap stretches within the memory (in cases >    where it is necessary  to use very large bulks of data). For >    operating systems that have the possibility to stretch the heap with >    a part on disc both boundaries (with and without disc data) are of >    interest. > > There should be a package in Ada that like GNAT.OS-lib does with > operating system differences, makes such hardware parameters available > for the programmer. > I know, I just said something that can create a lot of discussion, but one of the reasons that Ada was created was that programs were often not portable from one operating system to another for the simple reason that on one system another set op routines was used as on another operating system, or even new versions of the same OS. When different hardware is going to create the same type of problems my view is that to save that reason for the existence of Ada asks also for a form of hardware independency. Yes there are probably more hardware problems to be solved and no, I do not have solutions for all. But let me make a suggestion, use environment variable on a standard way in all operating systems then Ada can pick them up and use them: On my Windows 10 Operating system the variable OS="Windows_NT" is put there by Windows itself, On my Linux(Ubuntu) system the variable did not exist so I made it myself OS="Linux" now the .gpr file can differentiate between operating systems. For Screens the values Screen_Width and Screen_Height should be defined for Software like Gtk, Qt and Gnoga to know what the resolution of the screen is, and at least give you the possibility to make your program fit on all screens / graphical cards. Even a parameter MEM_AVAIL could be usefull. I know this are items to be resolved in an OS but a language like Ada could use the in a Package to make your program hardware independent.