Re: Windows; its way or the highway. (Was Re: RISC OS 6 - no shadow modes?)

This has grown rather long, so I have trimmed a fair amount...


In article <gemini.jgc5my003lbr7035o@xxxxxxxxxxxxxxxxxx>,
Jeremy C B Nicoll <jeremy@xxxxxxxxxxxxxxxx> wrote:
John M Ward <john@xxxxxxxxxxxxxx> wrote:

[some snipped, re registry keys]

You don't seem to be aware of the amount of stuff that is eg held in
opaque binary (bit flag) values in any OS including RISC OS.

Yes, I am; but I wasn't going in that direction, as it is obvious that
many resource-type files will need to be essentially "binary" for the
foreseeable future. Perhaps one day it will be judged worthwhile to
update such file-types to a more human-readable form -- but that's an
imponderable so seems little point in pursuing at this time.

[some interesting material read, including Y2k issues, expensive storage
many years ago, etc; but snipped from this reply]

It's the same decision that JSD made to make it impossible, or at
least hard, for people to tamper with many of Pluto's settings.
And it's done because lost of them refer internally to other ones
and they all need changed in sync.

Even so, he provided textual copies of several of those files, to
make it easier for users to see what is going on.

Yes, he produced one-way lists/reports which made it easier to see
what values one had defined somewhere. But he didn't (and I am sure
he never would) completely externalise parameters.

Agreed, especially with external boxes (as in Pluto 3).

[snipped a bit about pointers, and a further chunk about Pluto, as I
don't want to get bogged-down with apps when the original point was
about registry keys]


and all of those must be initiated at every start-up, whether
or not they are going to be needed.

I doubt that. I'd expect that when a particular part of Windows
starts it will ask for all of a particular class of values from
the registry and do whatever it needs to do with them.

If it has been made to work that way then thst is fine. It just
doesn't give that impression somehow -- but it isn't exactly common
knowledge how it /does/ work, as far as I ahve been able to
ascertain on a cursory investigation.

Why do you need to know how it works?

Only so that others here don't keep trying to tell me that I "don't know
about it". It isn't that important to me, especially as I am (still!)
trying to stop people contacting me with their computer problems because
I "know about these things". I am somewhat caught between two stools...

You try and run several copies of the same app under RO and keep
their choices in Choices separate and you'll have a problem. YOU
might not want to do that, but eg when I was supporting AntiSpam I
wanted to be able to run my own 'live' copy of the app, plus the one
I had under test, plus any of the previous versions to recreate
problems that people reported. I'd want eg to test the "new user"
logic that built a default set of options in the right place, and
naturally I din't want those to overwrite any real set.

In such unusual circumstances I'd probably set up different system
variables (something we can do on RISC OS!) or on a different drive
(with its own !Boot) or different machine altogether.

As it stands this was impossible because all of those apps would want
to save their choices in the same place. One can get around that to
some extent by using sysvars like AntiSpam$ChoicesDir, set in each
App's Obey file (and pointing to different places).

That's the kind of approach. Another -- in Select at least -- is to
have different users, whose configs are stored separately within !Boot
(this is not something I have investigated in detail as I am the only
user here).

[some more snipped]

It's a pity that all sys vars are global in scope rather than having
controllable scope (unlike eg environment vars unders shells in other
OSes).

I think that is because those particular OSes were designed to be
multi-user, and that is at least one of the main reasons for having that
capability. There are other facilities that we have available to handle
that kind of requirement, including (as you indicated) the built-in
BASIC

In most cases values are only read when eg the app that created
them is started.

Hopefully so; but in that case it would seem more sensible for the
app itself to contain the relevant data

Why? There's a nice convenient black box that stores things provided
by the OS - why not use that? Then every programmer doesn't have to
reinvent the wheel.

Whatever works better in each case, I'd have thought; though if the
"black box" is trusted (which I gather it hasn't tended to be, by and
large) then I am sure it'll do.

and to initiate it from there. It would need something of a
programming language built into the OS, and a simple but consistent
protocol for managing it, but I do believe it has been done that
way elsewhere for almost two decades, without any great
difficulties.

Do you mean RO and Obey files and system variables?

That is a versatile and easy enough system to understand and to be able
to easily tweak when required. I do this occasionally, keeping the
original version in the same app folder, e.g. the modified !Run and the
unedited !Run_orig (as I name it).

Or do you mean Windows and BAT files (etc) and environment variables?

Not really, I worked with those for years, but it really isn't the same
thing at all, especially with the filename issues between the
command-line display and the (hacky) long-name-plus-hidden-extension
Windows version.

Or Exec or EXEC2 or REXX or JCL or shell scripts or something else?

I am not qualified to comment on them, but don't need to as I have
always had all I need right here. I don't try to do too many strange
things with what I have working perfectly well -- though I do tinker
sometimes. Don't tell anyone ;-)

My own preferred system does it that way, and in so doing also
allows me to customise things to my own way of working without
needing any formal training and without my jamming up the rest of
the system. Each app has just a few files, usually called
something obvious like !Run, !Boot, !Templates, !Sprites, !Help and
so on. I believe you too are familiar with that systems ;-)

It's great so far as it goes, but it's not very flexible for
developers.

It doesn't seem to have generated any serious difficulties for
developers over the years (apart from the lateness of a C++ compiler);
but I'm sure it would be easy enough to create a development environment
tool/program that would emulate, vector pointers, whatever developers
might have identified as modern needs that weren't anticipated in the
original design of our system.

It probably falls far short of rocket science, and is hardly likely to
have been the first such need, as other systems will in many cases have
needed to cretae the same. All the conceptual and pseudo-coding work
will already have been done, I'd have thought.

--
John Ward in Medway, Kent - using RISC OS since 1987
Now using an Iyonix, an A9home, 2 RiscPCs and Virtual-RPC!
Acorn/RISC OS web page: www.john-ward.org.uk/personal/john/computers
.

Relevant Pages

  • Re: Advice Needed...
    ... will notice something is wrong with the general look of the app. ... Access developers don't seem to notice these things for some reason. ... I've written controls before and made every effort ... never liked about VB6 is the lack of a design-time size-to-fit feature. ...
    (microsoft.public.vb.general.discussion)
  • Re: Delphi, .NET and Linux
    ... So because professional developers are not stuck in a corner cranking out the same app day by day, they are all Office Space employees? ... While the Enterprise developer may not deal with the problems that a smaller one app shop would normally face, they usually have very daunting and extremely large scale considerations and tasks. ... Enterprise Corporate developers are often faced with the daunting task of building applications that support tens of thousands to hundreds of thousands of users. ...
    (borland.public.delphi.non-technical)
  • Re: Android marketplace blossoming....
    ... with the expectation of new software coming out to be ... year earlier between the amount of money that Android users spend. ... other developers had the same complaint. ... software that is more than just a dumb client app ...
    (comp.sys.mac.advocacy)
  • Re: Help, my developers are killing me with varchar2(4000)
    ... don't like this design philosophy. ... OMG - are som eof our developers working for you as well? ... client app code, ... Some new manager and new recent grad is responsible. ...
    (comp.databases.oracle.server)
  • Re: MSI Packages
    ... For computer registry keys, the only requirement should be permissions. ... app and output .xml back to the parent app. ...
    (microsoft.public.windows.terminal_services)