v7 SALFLIBC.DLL and Colour Mode.

I have come across one change in the latest v7 DLL re colour modes (over a DLL provided by Paul in March 2013) which may impact those with legacy code.

Previously the default colour mode was VGA (stated in manual) but now it appears to be RGB. Thus if a user (like me) had assumed the default and not used use_rgb_colours@ = 0 to specify this they now get 'rubbish'. I assume that this may have been an intentional change?

Many Thanks

Bill

Hi Bill,

Paul did it partly in response to a request from me that as surely no-one still used 16 colour VGA mode, perhaps the default ought to be 24 bit colour. Seems like I was wrong. It is mentioned in the CWP.ENH file and in the revision history on the website.

I'm almost never in favour of changes that break existing code, but sometimes, things must advance.

As it used to be, failure to USE_RGB etc gave you incredibly frustrating failure to show things in the right colours or at all, so the boot has simply moved to the other foot!

Eddie

Thanks for the quick response Eddie - I should have spotted it in the revision history. It is obviously 'slack' programming in a way (historically - this program dates from 199*?) and is easy to fix.

Thanks again

Bill

If by USE_RGB you means RGB_COLOURS then yes, that was needed change. I do not know how many times in the past i was losing hairs and hours swearing to the hell trying to find out why abruptly the %GR stopped to work until realizing that i forgot again and again this subtle switch rgb_colours...

Another such bottom kick from the past is the use INTEGER2 in some library subs like FILES@. We discussed this before. Hope Integer2 will also be pesticided and exterminated.

Yes, I mangled the routine name to indicate concept. If I'd quoted the exact routine, I would have used the final @ ! (Or I was to idle to get the correct name). I also swear, curse and rant at some of the issues...

Eddie

Thanks both - Whilst I appreciate the desire to eliminate everything from the past that is a pain I very much hope that Paul and others NEVER (in my working lifetime) remove old integer*2 support - some of us have to maintain and develop old programs and do not want to re-write them!

Yes I know such routines are a pain but most (but not all) have modern equivalents so those with modern programs can work unhindered - though I do see that it is reasonable to go to an RGB standard given the relative painless way (3 hours for me on 15 programs) of dealing with this.

All the best

Bill

Why the move to an RGB default from a VGA default had to stop 16-colour modes working is a function of implementation, and I suspect that Paul simply changed the default without working through the ramifications (I would have done the same, so no criticism from me there).

Making INTEGER by default *4 instead of *2 certainly makes the old habit of having different contents in the same COMMON block in different routines into a real problem. It may also complicate some bitwise storage of flags. But sensible (sorry Bill!) code should survive this change, better than say REAL going from *4 to *8, where roundoff behaviour changes. That is unless you have specific code to catch integer overflow.

As an aside, why is LOGICAL so big? When I was short of RAM in early PC days, I wanted LOGICAL0.125, or maybe a relative scale between .TRUE. and .FALSE. - with LOGICAL4 one approaches the ability to shade nuances into this.

Eddie

As far as I know there are no ramifications as far as the library is concerned. Users who have old code with VGA colours will need to change before using the new DLL.

Paul,

There do appear to be ramifications, e.g.

Thus if a user (like me) had assumed the default and not used use_rgb_colours@ = 0 to specify this they now get 'rubbish'

This doesn't affect me.

Eddie

My apologies.

The potential ramifications for users was clear at the outset and caused us to think long before making the change.

As far as I know there are no ramifications as far as the internal library code is concerned.

Well, Bill said it only took a few hours. I call it a problem if I'm nowhere near a solution in several days! (Slow learner!)

I think the change was the right one.

Eddie