Re: Ada Tutor Web Site Shutting Down

["Randy Brukardt" <randy@rrsoftware.com>]

"Rugxulo" <rugxulo@gmail.com> wrote in message 
news:291504a4-ec55-45f1-bf7f-13078bf71c3e@m10g2000yqd.googlegroups.com...
Hi,

>On May 5, 4:12 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> Better, dunno. Janus/Ada 95 (32-bit only) would be updated if anyone 
>> wanted
>> it, but no one has asked. (It's still in our pricelists.)

>Updated how? (A quick glance at the 2005 standard seems more
>complicated regarding changes than initially implied.)

Just recompiled and tested. It might need some runtime updates, but probably 
not a lot. All of our Ada 95/2005/2012 technology is from a common codebase, 
so building the DOS version just means selecting the right configuration and 
recompiling. (And lots of testing and probably a bit of debugging.)

The biggest problem with it is that the DOS extender we used didn't work 
with NT and afterwards. (It actually works precisely once, then you have to 
reboot before it will work again. Not very practical.)

> Well, I'm not a
> customer (and don't know Ada), so I guess that rules me out.  ;-)
> I'd assume it's "good enough" for the few that use DOS commercially
> these days. (I assume you probably are more geared towards businesses
> than home users.)

I don't think we have any DOS customers anymore; they've all moved to 
Windows console mode or to other OSes.

> The only significant DOS Ada app I know of (which is probably my
> fault, not Ada's) is Gautier's 3D engine (used GNAT):
> http://sites.google.com/site/rugxulo/eng3d018.zip?attredirects=0

>> But a better question is why would you want to use a new compiler?
>
>Why not?  :-)  No, seriously, I was only responding to the OP's claim
>that Ada95 is obsolete and that his tutorial was in DOS (hence, old)
>and needed to be updated. I don't even know what compiler he used for
>it originally.

If I remember right, his tutorial uses a DOS display program. That looked 
old when it was new. ;-)

>> Is there anything inportant that you can do in DOS that you can't do
>> in a Windows console program or a standard Linux program?
>
>Sure, run in DOS!  :-))
>
>(self-modifying code? direct hardware access? run in less than 10 MB
>of RAM? call the BIOS?)

Self-modifying code: Not with Janus/Ada (no self-modifying code there). We 
wanted it to be reproducible and somewhat secure. Direct hardware access - I 
suppose, but is that an advantage? Or a security nightmare waiting to 
happen? Same with "call the BIOS". Run in less than 10 MB of RAM - I think 
there are Linux flavors that can do that. The Ada programs are pretty small 
for any of the OSes (so that's about the OS footprint).

>> The main reason for compiling a
>> DOS program would be so that you don't have to change anything about,
>> including the DOS specific stuff.
>
>Sure, assuming there is any DOS-specific stuff, which I know is
>sometimes unavoidable, but doing that almost defeats the purpose of a
>portable HLL.

It was pretty much impossible to do anything interesting without doing 
something DOS specific. That's actually true of pretty much every OS target, 
simply because of the different nature of file names on each platform.

>> In that case, you're best off sticking
>> with the same compiler that it was built with, why make more work by
>> introducing a new set of bugs.
>
>Well, bugs will always exist, even with the best of intentions and
>strictest preparations.

Exactly.


>> (We occassionally get requests for absolutely ancient compiler versions, 
>> for
>> someone that needs to make a tiny change in some old program. Not long 
>> ago,
>> I needed to dig up a 1985 version of Janus/Ada for someone. The cool 
>> thing
>> was that I tried running it to make sure I'd copied it uncorrupted [an 
>> issue
>> because it copied from 25 year old floppies], and it worked fine on a 
>> modern
>> Windows XP machine. I knew there was a reason that we were really careful
>> about following the OS rules back in the day...)
>
>Yes, that's the ideal, software that still runs for many years in the
>future. The DPMI standard helped that a lot. For sure, DOS lived a
>long, long time.

I think 1985 was well before DPMI, and probably was before expanded and 
extended memory, too. This probably was a basic 640K compiler (I don't think 
we even had 640K in our machines at the time - our original IBM PC/XT 
started with 256K, and I think the Seattle Computer 10 MHZ 8086 [much faster 
than the PC] had about that as well).

>Unfortunately, Windows has gone downhill (in DOS support) since XP,

You could have just left out the parenthetical remark, and you still would 
have been right. ;-)

>and 64-bit completely kills it. (XP Mode is only for business
>editions, not home users.) You'll have to use DOSBox or VirtualBox
>(preferably with VT-X) or else switch to Linux for DOSEMU. (Well, you
>could run FreeDOS natively, but I doubt most will consider that.)

That's one of the reasons I'm not moving most of my work to Windows 7 
anytime soon. I still use a number of DOS programs regularly, including a 
circa 1986 programming editor.

                                     Randy.