RE: [announcement] SYSAPI and SYSSVC for Windows

RE: [announcement] SYSAPI and SYSSVC for Windows

[amado.alves]

[Windows vs. Linux]

This is OT,, but whataheck, I'd like to share my recent experience and impressions. I'm trying to reinstall Linux on my laptop after a disc crash. RedHat 9 used to install, but RedHat is gone commercial now so I tried Fedora. It failed miserably (over the network). I also tried Debian over the network, Mandrake over the network, and Mandrake with CDs. I even tried Plan 9 network. All with floppies, because my CD does not boot. All failed. All fail setting the graphic system. Many fail in other things also. The Mandrake case is incredible. The installation goes graphic fine, but the last step about configuring X fails: it's incredibly stupid and irritating: if the graphic is working why doesn't the bloody thing continue with the same parameters? And then it cannot recover. All other installations except Plan 9 fail partially right from the start: they start loosing text lines. Framebuffer problems I think. Is informatics a fraud or what? I'm close to go growing watermellons like Xanana Gusmao.

Just to prove why Windows is an *excelent* system--except for price. But now it seems you'll have to pay for Linux too. RedHat starts at 179 dollars I think. So there is still hope for AdaOS ;-)

Re: [announcement] SYSAPI and SYSSVC for Windows

[Georg Bauhaus]

amado.alves <amado.alves@netcabo.pt> wrote:
: [Windows vs. Linux]
: 
: This is OT,,

and it omits the crucial factors:
1/ What graphics system does your laptop have?
2/ Who has written the graphics driver for Windows?
3/ Did they have to keep the graphics card programming interface a secret?

(I have had a "cheap" Thinkpad and no graphics problems with plain
Debian.)

: Just to prove why Windows is an *excelent* system--except for price.

Hm, evaluating systems by the existence of a functioning graphics
control program?

: But now
: it seems you'll have to pay for Linux too.
: RedHat
: starts at 179 dollars I think. So there is still hope for AdaOS ;-)

Free Software is about Freedom, not price, as is frequently repeated,
but maybe not frequently enough :-)


-- Georg

RE: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

amado.alves wrote:

> [Windows vs. Linux]
> 
> Just to prove why Windows is an *excelent* system--except for price.

Try to install Windows over network!

It is also amusing to install NT 4.0 on a relatively modern box. You will
have a lot of fancy blue screens.

> But
> now it seems you'll have to pay for Linux too. RedHat starts at 179
> dollars I think. So there is still hope for AdaOS ;-)

Well, an OO OS written in Ada sounds good. However, it would be rather
difficult to do in a clear way without multiple inheritance and dispatch,
full blown ADT, tagged tasks and protected types, light-weight smart
pointers, reasonable sreaming and memory pools support. Ada just has
started to catch it, but it has a long way to go.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> Try to install Windows over network!

There are toolkits supplied by Microsoft to permit remote installing.
If you know how to use them, it's no big deal.
 
> It is also amusing to install NT 4.0 on a relatively modern box. You will
> have a lot of fancy blue screens.

Windows NT 4.0 is an anachronism. Microsoft doesn't support it anymore, 
either. Even Windows 2000 is outdated. Windows XP is the way to go, it does
not only include all of Windows 2000 but also all of Windows NT (even the
OS/2 1.3 and POSIX subsystems exist in XP). 

> Well, an OO OS written in Ada sounds good. However, it would be rather
> difficult to do in a clear way without multiple inheritance and dispatch,
> full blown ADT, tagged tasks and protected types, light-weight smart
> pointers, reasonable sreaming and memory pools support. Ada just has
> started to catch it, but it has a long way to go.

Ada 95 just has a different way of doing things. If you take your time to
understand them, you can use them effectively as well.

I bet the Ada 20xx standard that is in the works will add even more 
interesting stuff to the language.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Georg Bauhaus]

Ekkehard Morgenstern <ekkehard.morgenstern@onlinehome.de> wrote:
: Windows NT 4.0 is an anachronism. Microsoft doesn't support it anymore, 
: either. Even Windows 2000 is outdated. Windows XP is the way to go, it does
: not only include all of Windows 2000 but also all of Windows NT (even the
: OS/2 1.3 and POSIX subsystems exist in XP). 

Though I think that starting with NT4, Windows has given up the nice
modularisation present in NT 3.51 among other things.

Let alone the much debated forcedness of "support" for no-copying 
soft/hardware, saluting the DMCA and Palladium.
Did someone say something like "we need more trust"?


-- Georg

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> Though I think that starting with NT4, Windows has given up the nice
> modularisation present in NT 3.51 among other things.

Not in the least. As I said, XP contains all of 2000 and all of NT.

Windows is still modular, it's just not as obvious because the system
has become much bigger.

> Let alone the much debated forcedness of "support" for no-copying 
> soft/hardware, saluting the DMCA and Palladium.
> Did someone say something like "we need more trust"?

This panicking in the face of TCPA efforts is not justified.

The Palladium platform will support "trusted" and "untrusted"
operation. It just mimicks things present in MULTICS, and OS/400,
for example, namely the possibility of providing a secure 
environment for running applications.

The user can decide whether they want to run trusted or other apps.

The trusted mode is mainly targeted at business that want to 
protect its business-critical data.

Other operating systems will also support TCPA, namely AIX, Solaris
and GNU/Linux. Whether the users will accept it, is another question,
but I figure that businesses will welcome it.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Georg Bauhaus]

Ekkehard Morgenstern <ekkehard.morgenstern@onlinehome.de> wrote:
: 
: "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote:
:> Though I think that starting with NT4, Windows has given up the nice
:> modularisation present in NT 3.51 among other things.
: 
: Not in the least. As I said, XP contains all of 2000 and all of NT.

Hm. So is it not true that they more or less have woven the shell and
the graphics subsystem into one thing?
(I know I can sort of replace explorer by cmd.exe, but then ...)
Does someone remember the "light" edition of IBM's OS/2 workplace shell
running on WfW 3.11? I remember a microsoft employee explaining
(in 1996) that the NT developers would have wished to go on with
the development of an O-O filesystem, they weren't allowed because
of the new interface ...

:> Let alone the much debated forcedness of "support" for no-copying 
:> soft/hardware, saluting the DMCA and Palladium.
:> Did someone say something like "we need more trust"?
: 
: This panicking in the face of TCPA efforts is not justified.

(Who is panicking? :-) By trust I meant to refer to honest business.
(The baker hands me a loaf of bread, I pay. X sends content to me over
an internet connection, I pay.)
Now you can't copy bread (except if you employ Jesus' trick), but
you can copy software (and music and films, no news here).
If your general attitude towards consumers contains,
"People are stupid and selfish and have a tendency to be criminals, in
 particular if they have computers (you know they get all this free stuff
 how should they have learned to pay), they sure will make illegal copies,
 everyone knows this, no use explaining that producing media content is
 work etc",
then you don't believe in a kind of business where a sufficient number
of people will see that paying is the right thing to do.
Or at least you presume it is more profitable to not believe in
paying customers.
<rant mode=OT>
This, IMHO, is what Palladium addresses.
 
: The Palladium platform will support "trusted" and "untrusted"
: operation. It just mimicks things present in MULTICS, and OS/400,
: for example, namely the possibility of providing a secure 
: environment for running applications.
: 
: The user can decide whether they want to run trusted or other apps.

The users might have an option to decide whether they want to run
"trusted" applications like media player, real player, and its ilk or not
see anything at all -- because there is little to be seen without
"trusted" programs. What other apps? In a sense, there will be trusted
programs. But the concept of a trustworthy person is not currently
preferred.  Why?
(All there is is threat, contemporary ad: "you know what the other
prisoners will do to you in jail, movie pirat, do you?"
addressing a *mass* audience, not professionally copying criminals). 

I'm glad there are some compiler vendors who seem to trust their
customers and don't use all sorts of electric circuits but a plain
contract, and payment.  Why? Might they have reason to assume that
customers aren't necessarily thiefs or fences?

Lets see whether the prices for products that cannot be copied
will adapt or whether Sony Music, Hollywood, et. al. will leave
the prices at the current level and try to, uhm, "recover".
(after all there is said to be a huge loss due to copying,
everyone in the music and films industries (including pornographic
films industries) seems to be starving, right?).
</>

-- Georg

Re: [announcement] SYSAPI and SYSSVC for Windows

[Vinzent 'Gadget' Hoefler]

Georg Bauhaus wrote:

>(after all there is said to be a huge loss due to copying,
>everyone in the music and films industries (including pornographic
>films industries) seems to be starving, right?).

They do. Just take a look at all these poor girls, they are almost all
soooo skinny. I even remember that some of these told a magazine that
they only eat "one slice of toast and a glass of water each day". What
a shame. We have to donate for all these poor people. Buying at least
one CD every day could help them, couldn't it? ;->>>


Vinzent.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> : Not in the least. As I said, XP contains all of 2000 and all of NT.
> 
> Hm. So is it not true that they more or less have woven the shell and
> the graphics subsystem into one thing?

Huh?? No.

Graphics on XP is managed by DirectX (various DLLs), GDI+ (GDIPLUS.DLL),
GDI (GDI32.DLL), called by the GUI subsystem (USER32.DLL and UXTHEME.DLL).
The GUI subsystem in XP is themed, and hence drawing of system GUI 
components is done by UXTHEME.DLL. 

The Shell (GUI user environment) is handled by various components,
among which Windows Explorer and Internet Explorer. 

The IE component is used for displaying DHTML dialog boxes and applets,
and used by parts of the Windows Explorer and the Help subsystem.
Generally, it's just used as an HTML viewer.

GDI+ is portable to other Windows versions and provides a simple C++
interface for doing graphics with floating-point accuracy. But it's
very, very slow. They fixed some of it in SP1.

DirectX 8 and especially DirectX 9 do all sorts of hardware-based
graphics. DirectX 9 has a better interface and a new concept. 
Generally it unifies 2D and 3D graphics. 

Microsoft seems to work on the next generation of graphical user
interfaces, as it seems, which will keep every GUI component as a
3D object internally.

(that's also why the free OS communities should pay attention to what
Microsoft is doing when they want to stay competetive!)

UxTheme is a nice concept for theming GUIs. There are already some
uncertified versions that permit changing the view of Windows in
rather drastic ways, much like the Enlightenment window manager on
GNU/Linux.

New in XP is also the .NET framework, which permits Java-like
GUI programming, but it's mainly targeted at client/server operation,
as it seems.

It could be that in some years, Windows programming will be only
possible with .NET, but I doubt that it will happen any time soon, 
because lots of applications would have to be rewritten.

> (I know I can sort of replace explorer by cmd.exe, but then ...)

You were able to replace the shell already on Windows 3.1. It's no big
deal really, you can configure the process that is started in the
Windows registry. You can use any application as the user interface 
shell. Some people switch the default shell off and start every program
using the Windows task manager.

You can even use multiple desktops (GUI workspaces), and multiple
monitors. (This is mainly used for applications like info terminals,
etc. on which the user shall not see the system's shell).

Plus, you can serve multiple workstations with virtual terminals
(Windows Terminal Services).

XP can also permit remote maintenance if the user wishes so.

There's plenty more stuff in XP, and that's why it uses a couple
of gigs on the harddrive. ;)

Personally, XP is my all-time favourite version of Windows, and I'm
sure Microsoft will come up with something even better in a couple
of years. "Longhorn" is scheduled for 2006 or 2007, so I guess they
have a big change in mind. ;)

I'm glad that this time they take their time to develop the system.
That's much better than shelling out a new version every other year
that has to be shipped before it's finished and patched up by the
user. If they had implemented a mandatory Windows Update feature,
there'd been rage all around in the press, and so people have to do
it manually, and often don't even know about it, that it can make
their system reliable and stable, and then they bitch that it isn't
working properly. ;)

> Does someone remember the "light" edition of IBM's OS/2 workplace shell
> running on WfW 3.11? I remember a microsoft employee explaining
> (in 1996) that the NT developers would have wished to go on with
> the development of an O-O filesystem, they weren't allowed because
> of the new interface ...

OS/2 was very good. Too bad that Microsoft and IBM parted on the system.
And IBM shouldn't have thrown it away as they did.

I was on an OS/2 developers conference in Colorado in 1997 I think,
for my employer, when the IBM folks said OS/2 was dead. It was sad,
really. I just had bought my copy of Warp 4 with the integrated speech 
recognition (cool stuff btw), and a lot of OS/2 books.

So, Microsoft revived the OO ideas already in Windows 3.1 with OLE,
and later on with COM, DCOM, and COM+. I never programmed for it,
so I don't know if it's really good, but I think it is.

Windows nowadays, especially XP, is all based on component classes.
The whole Windows shell is written with it (COM+ and COM).

The only complaint I can give is that the components that come
with XP aren't documented at all (except the COMCTL32 and COMDLG32
DLLs, which is only a tiny subset of the components). With a COM or
OLE browser you can see what classes exist and which methods they
have but there's no real documentation for all of the components
(since there are literally gigabytes worth of components in XP,
I doubt Microsoft has enough employees to document them all!! ;) ).

> : This panicking in the face of TCPA efforts is not justified.
> 
> (Who is panicking? :-) By trust I meant to refer to honest business.
> (The baker hands me a loaf of bread, I pay. X sends content to me over
> an internet connection, I pay.)
> Now you can't copy bread (except if you employ Jesus' trick), but
> you can copy software (and music and films, no news here).
> If your general attitude towards consumers contains,
> "People are stupid and selfish and have a tendency to be criminals, in
>  particular if they have computers (you know they get all this free stuff
>  how should they have learned to pay), they sure will make illegal copies,
>  everyone knows this, no use explaining that producing media content is
>  work etc",
> then you don't believe in a kind of business where a sufficient number
> of people will see that paying is the right thing to do.
> Or at least you presume it is more profitable to not believe in
> paying customers.
> <rant mode=OT>
> This, IMHO, is what Palladium addresses.

No, Microsoft said it will not restrict the use of the system.
Everything will be as it was before, except that there will be a new
subsystem providing unsecure operation, while the core system will
become secure. Microsoft knows that people don't want to invest in
all-new software. You can still use all of your old software, and
no-one will snoop on your computer about it.

Do you know about the whole NSA Key topic? Someone complained that
there was an NSA key file shipped with Windows, and he suspected that
Microsoft could use it to install NSA specific software silently on
people's computers. But that's not true, it was only named like that
because the government required that Microsoft would keep a copy of
their certification keys, and so they kept the copy on the user's
computers to make sure a backup exists in the case the original key
gets lost, because they otherwise couldn't meet the government
requirements.

Microsoft also knows that many people use pirated software on their
computers. However, that's in the responsibility of those people,
and Microsoft knows sales would drop dramatically if they would
disallow the use of such. It would also hinder the development of
new software, since you would have to certify it during development
to run it in secure mode.

This is btw already true for many Windows component types which have
to be certified to be used, but since Microsoft ships tools for
generating the certificates with the development suites, it's in
the responsibility of the programmer. This might change for the
secure application services in the future, but Microsoft will 
provide a way to register applications.

In any case: No matter what they do, you will always be able to
develop your own software, and then you're free to do what you like.
Like, writing a new MP3 player or video composition tool, or whatever.

> : The user can decide whether they want to run trusted or other apps.
> 
> The users might have an option to decide whether they want to run
> "trusted" applications like media player, real player, and its ilk or not
> see anything at all -- because there is little to be seen without
> "trusted" programs. 

You forget about WinAMP and all the free software on the market.

Even if Micrsoft would provide only a secure Media Player (perhaps as
required by the movie and music industry, don't forget that Microsoft
has to cooperate with those), you could still use independent software.

Although TCPA might seem to be targeted in the DRM direction, and 
certainly will be used for some of it, it will certainly have other
applications as well. 

The TCPA specification has changed a lot in the light of more or less
recent protests from consumers and the press. And hence, Microsoft
will not make the system a closed operation. In that case, no-one
would buy Windows, and that is definitely not in their market interest.

(Microsoft is sitting in the TCPA group along with other big companies)

> What other apps? In a sense, there will be trusted
> programs. But the concept of a trustworthy person is not currently
> preferred.  Why?
> (All there is is threat, contemporary ad: "you know what the other
> prisoners will do to you in jail, movie pirat, do you?"
> addressing a *mass* audience, not professionally copying criminals). 

In a sense the government wants to protect people from themselves.
Software piracy has always been illegal, and copies for your own
personal use aren't. Even if those would be illegal as well, no-one
would really be able to verify this. (AFAIK the new EU laws only
state that you are not allowed to go around a copy protection if
there is one. But you don't need to if you use a setup that provides
a copy without going around the copy protection.)

What's the use of software piracy anyway? All you get is viruses
and programs without support. I prefer buying all the software I
really need to use, and only that, and using free licensed software 
whereever possible. And if I want to have a movie, I wait until it's
out on DVD and then I buy it, and CD's likewise.

There are a lot of unemployed people, and software piracy is simply
endangering jobs everywhere.

Even the current version of Windows Media Player allows you to
copy all your CDs onto your computer and encrypt them. Microsoft
plans to provide the same functionality in Longhorn, so that 
feature will not disappear, because it provides convenience for the
user.

> I'm glad there are some compiler vendors who seem to trust their
> customers and don't use all sorts of electric circuits but a plain
> contract, and payment.  Why? Might they have reason to assume that
> customers aren't necessarily thiefs or fences?

For small companies, developing a compiler is a costly effort, and
hence needs to be copy protected. Imagine you take all your money
and invest into the development of a compiler, and then you go home
and a friend offers you a pirate copy of it. How would YOU feel?

Small companies will always use dongles. 

Big companies like Microsoft don't need dongles. They know they
will have enough money to develop and market the product, and
as long as enough people buy it, all will be ok. 

The only change so far was with Windows XP, in which they 
introduced a strong copy protection (that was cracked soon after,
they had better used some sort of PCI card or dongle) for the
first time. That was a clear sign to me that Windows XP would be
better than any earlier version and that they put a lot of effort
into it.

> Lets see whether the prices for products that cannot be copied
> will adapt or whether Sony Music, Hollywood, et. al. will leave
> the prices at the current level and try to, uhm, "recover".
> (after all there is said to be a huge loss due to copying,
> everyone in the music and films industries (including pornographic
> films industries) seems to be starving, right?).

There are a lot of things people don't think about when they say
what you said. 

Like, record companies have a lot of staff that needs to be paid,
and they need to look good at the stock exchange too, if they're
there or their investors would drop them.

The distribution networks for audio and video products also
have a lot of resellers inbetween that want to make a profit too.
So a CD costs a couple of cent to manufacture but costs a couple
of Euros or Dollars in the shop, all re-sellers, employees and
artists paid.

As soon as the audio/video industry has the facilities to sell
everything directly via the Internet, they can also drop the
prices for their services. There are already some perfectly
legal online music shops that sell songs by professional artists
for a couple of cents each. So it IS possible.

I think it's a matter of personal maturity whether you let 
other people have their share of profits. We're living in a 
cooperative society after all, and although I think that 
capitalism might not be the perfect concept, by far, at least
it keeps a lot of people employed and making a living. So we
don't need to hunt our food ourselves, and we don't need to
build our houses and cars ourselves, we have a standard of living
that allows us to talk about such subjects and not just be 
involved with matters of direct survival.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Georg Bauhaus]

Ekkehard Morgenstern <ekkehard.morgenstern@onlinehome.de> wrote:
: 
: "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote:
:> : Not in the least. As I said, XP contains all of 2000 and all of NT.
:> 
:> Hm. So is it not true that they more or less have woven the shell and
:> the graphics subsystem into one thing?
: 
: Huh?? No.

I checked, not the shell but the Executive. From user mode to
kernel mode,
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarwbgen/html/msdn_movuser.asp

: (that's also why the free OS communities should pay attention to what
: Microsoft is doing when they want to stay competetive!)

Yes.  BTW, are 3D GUI objects a Microsoft invention?
Then there is a patent opportunity, so free OS communities will
have to consider 4D GUI components to stay competitive :-)

: New in XP is also the .NET framework, which permits Java-like
: GUI programming, but it's mainly targeted at client/server operation,
: as it seems.

In particular, it also looks like an embraced CORBA.

:> If your general attitude towards consumers contains,
:> "People are stupid and selfish and have a tendency to be criminals, in
:>  particular if they have computers (you know they get all this free stuff
:>  how should they have learned to pay), they sure will make illegal copies,
:>  everyone knows this, no use explaining that producing media content is
:>  work etc",
:> <rant mode=OT>
:> This, IMHO, is what Palladium addresses.
: 
: No, Microsoft said it will not restrict the use of the system.

They sure will help resticting copying. I'm not saying that distributing
copies to circumvent payment is a nice thing to do, but I think "secure"
software expresses the above attitude towards customers: "they are thieves,
this won't change, we must use force." Sounds like defamation to me.

: Everything will be as it was before, except that there will be a new
: subsystem providing unsecure operation, while the core system will
: become secure.

Interesting wording, a little biased towards secure transactions
of money I guess?

: Microsoft knows that people don't want to invest in
: all-new software. You can still use all of your old software, and
: no-one will snoop on your computer about it.

Question is, can I still use my old real player 8 and listen to BBC?
Probably yes. Will I be able to watch an older US film online using
RP8 as "unsecure" software, after signing a pay-per-view contract?

: Microsoft also knows that many people use pirated software on their
: computers. However, that's in the responsibility of those people,
: and Microsoft knows sales would drop dramatically if they would
: disallow the use of such.

Yes and No. Are they disallowing the use of a FAT file system unless
there is a license agreement,
http://www.microsoft.com/mscorp/ip/tech/fat.asp ?

:> The users might have an option to decide whether they want to run
:> "trusted" applications like media player, real player, and its ilk or not
:> see anything at all -- because there is little to be seen without
:> "trusted" programs. 
: 
: You forget about WinAMP and all the free software on the market.

This excludes the server side from view.
What software is used to produce the streams?
What software is used to produce the media content suitable for
non-MS/non-Real players?
Does it offer "secure" operation, that is D"R"M compatibility?


: Even if Micrsoft would provide only a secure Media Player (perhaps as
: required by the movie and music industry, don't forget that Microsoft
: has to cooperate with those), you could still use independent software.

Aha! You may want to study what Jack Valenti has said about
what the internet is: a distribution channel for media content that
has to be secured from software piractes to "protect America's greatest
trade export".
 
: The TCPA specification has changed a lot in the light of more or less
: recent protests from consumers and the press.

Good "Old Europe". (An interesting variation of a dictum about Europe
by US DoD officials not long ago.)

: And hence, Microsoft
: will not make the system a closed operation. In that case, no-one
: would buy Windows, and that is definitely not in their market interest.

But how many young people will continue to listen to music on CDs
when they have to buy each and every of them? How will this affect
Music Industry? To be continued...

: There are a lot of unemployed people, and software piracy is simply
: endangering jobs everywhere.

...Interesting. I doubt that Microsoft would have grown that large
were it not for the widespread illegal copies of DOS and Word
(and that spread sheet software the name of which I cannot currently
remember).

Without software piracy, and by analogy, music piracy, will those who
are thieves now become buyers then? Where will their money come from?


:> I'm glad there are some compiler vendors who seem to trust their
:> customers and don't use all sorts of electric circuits but a plain
:> contract, and payment.  Why? Might they have reason to assume that
:> customers aren't necessarily thiefs or fences?
: 
: For small companies, developing a compiler is a costly effort, and
: hence needs to be copy protected.
: 
: Small companies will always use dongles. 

I don't think small compiler companies will always use dongles.
Is Comeau Computing a large company?
Don't know about RR Software. Do they use dongles?
I know of FLEXlm for site licensing for another Ada compiler, but not
for single user licensing. I think ISE Eiffel uses license files a well.

And: ACT produces Free Software, GNAT compiler and tools, which
must still be a costly effort because it is an evolving compiler.
They don't use copy protection at all you could guess, other than
the requirement that you may not take the compiler sources,
rework them, sell the product and store the reworked sources away
as private property.  Where is the dongle? Will GNAT need "DRM"
hardware to work in "secure" mode?

: Imagine you take all your money
: and invest into the development of a compiler, and then you go home
: and a friend offers you a pirate copy of it. How would YOU feel?

I wouldn't be surprised. But small companies usually have the time
to talk to their prospective customers before they hand over a
copy of their product.

: Big companies like Microsoft don't need dongles. They know they
: will have enough money to develop and market the product, and
: as long as enough people buy it, all will be ok. 

The media industries seem to differ.

: There are a lot of things people don't think about when they say
: what you said. 
: 
: Like, record companies have a lot of staff that needs to be paid,
: and they need to look good at the stock exchange too, if they're
: there or their investors would drop them.

You are repeating old, old arguments here :-) Look for complaints
about LP recordings of classical music in the 50s and 60s, and about
tape recorders.  Same thing. They have always complained. They
have always compared figures selectively, describing The Situation
Of the Music Industry as one that inevitably favours the desired outcome
of the comparison: the trade is in a bad shape, employees are
suffering, etc etc etc.
In the long run the industry has grown.


: There are already some perfectly
: legal online music shops that sell songs by professional artists
: for a couple of cents each. So it IS possible.

That is not true of your average artist at your avery online store.
As cheap as ever.

: I think it's a matter of personal maturity whether you let 
: other people have their share of profits.

Yes. Exactly. That is why I believe in honest business, not
in threat, force, and costly safeguard.

: We're living in a 
: cooperative society after all,

That's an interesting claim if you allow me to include "business"
in "society".  Is business cooperative, or competitive, or both?
Will a company invite competitors, or will they try to keep them
out of projects? What does that say about "cooperative society"?
And maturity?
Nothing. Too many generalisations for my taste. I would make
non-technical arrangements in order to keep the number of unwelcome
surprises like license violations low.



-- Georg

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> :> Hm. So is it not true that they more or less have woven the shell and
> :> the graphics subsystem into one thing?
> : 
> : Huh?? No.
> 
> I checked, not the shell but the Executive. From user mode to
> kernel mode,
> http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarwbgen/html/msdn_movuser.asp

So what?!

Plus, you're talking about NT 4.0, which is a pink flying elephant
that doesn't exist anymore. ;)

I couldn't care less if GDI runs in kernel mode. 

A graphics card driver can tear down the system anyway, whether GDI is
in user or kernel mode. Or whatever you were alluding to.

> Yes.  BTW, are 3D GUI objects a Microsoft invention?

No, they've existed long before on various experimental UIs.

> Then there is a patent opportunity, so free OS communities will
> have to consider 4D GUI components to stay competitive :-)

Don't make fun of it! 3D user interfaces will be considered "normal"
in a couple of years.

I still remember when people got laughed at for talking about
graphical user interfaces. "All you need is a text terminal!"

Technically, the 3D thing comes automatically with DirectX 9 or
higher. They've eliminated DirectDraw, all you can do is create
textured rectangles to get a similar effect. ;)

Many computers already have hardware-accelerated 3D graphics,
even business computers which are often sold with state-of-the-art
hardware, whether the customer realizes it or not, and hence
there'll be a point in the future in which it can be safely required.

In my own OS project (DELOS), I will also experiment with 3D
user interfaces. 

Other GUI research groups (apart from Microsoft) have come up with 
some new 3D GUI paradigms, but they aren't well-evolved yet.

You don't really know what research is or has been going on in that
area. I've already seen 3D GUI apps on SGI's over a decade ago, so
it's not uncommon for software developers to invent things like that,
I guess.

Things really get interesting when users have real 3D projectors
available (as in shutter glasses, or 3D laser-to-vapor projectors,
or retina projectors, which all exist already).

But also for regular 2D displays, 3D user interfaces might be
interesting.

For example, imagine windows could have a flip side, or would be
cubes or other bodies. With a flip side, in a word processor,
for example, you could literally turn the pages of your document
and write on every front and back page. 

Or you could move windows from back to front or sideways or out
of view. Or you could be like in a room or sphere and rotate the
view and hence get to have more things open at the same time.

For modelling software, you could eliminate most of the window
boxing and three-side views, you could work on the object directly,
of sorts.

Just to project a 2D surface into 3D space alone doesn't make a 3D
user interface. (that's related to the results I've seen of some
3D UI working group, which did just that)

For all those applications, a 3D GUI paradigm needs to be created
that makes sense. If I get around to it, I will also do some research.

> : New in XP is also the .NET framework, which permits Java-like
> : GUI programming, but it's mainly targeted at client/server operation,
> : as it seems.
> 
> In particular, it also looks like an embraced CORBA.

So does OLE or COM or DCOM, for which you also need IDL compilers.

CORBA has been an effort that was never fully integrated into an OS,
because they all came up with their own designs (for better or worse).

Nonetheless, CORBA is available for all those OSes.

(btw, Microsoft has always been sitting in the CORBA standards group,
so that's not really a surprise)

> They sure will help resticting copying. I'm not saying that distributing
> copies to circumvent payment is a nice thing to do, but I think "secure"
> software expresses the above attitude towards customers: "they are thieves,
> this won't change, we must use force." Sounds like defamation to me.

Software piracy exists, so why should they not do something about it?

Microsoft doesn't imply anything. They said they will permit to run
all kinds of apps on the next generation Windows kernel. So whether you use
the secure or unsecure subsystem is your business alone.

> : Everything will be as it was before, except that there will be a new
> : subsystem providing unsecure operation, while the core system will
> : become secure.
> 
> Interesting wording, a little biased towards secure transactions
> of money I guess?

Yes, of course. I'm very interested in secure transactions of money. <vbg>

If Microsoft serves as the motor of the industry, then why not? If no-one
else dares to play that role, then why should they not take it?

It will definitely create jobs. Software piracy never created any job.

> : Microsoft knows that people don't want to invest in
> : all-new software. You can still use all of your old software, and
> : no-one will snoop on your computer about it.
> 
> Question is, can I still use my old real player 8 and listen to BBC?
> Probably yes. Will I be able to watch an older US film online using
> RP8 as "unsecure" software, after signing a pay-per-view contract?

Yes, of course.

Microsoft are not dumb, they always knew how to pull the money out of
our pockets, they are up for seconds! ;)

Microsoft is the last company on Earth probably who doesn't want to
make money selling us new stuff.

As long as some people keep an eye on what they're doing and scream and
ramble everytime they lift a finger, then all is well, and Microsoft
bows to the wishes of the general public. ;)

I've once seen a report about Microsoft in which they showed how they
always fear losing market shares and customers, thinking they're going
out of business any day. That's the right way to lead a company:
Always think every day could be your last! ;)

Microsoft is definitely a much friendlier company than IBM for example.

IBM stopped the development of OS/2 and Visual Age for C++, that's just
like someone throwing all their gold out of the window and laughing
merrily that they've relieved themselves of such burden.

> : Microsoft also knows that many people use pirated software on their
> : computers. However, that's in the responsibility of those people,
> : and Microsoft knows sales would drop dramatically if they would
> : disallow the use of such.
> 
> Yes and No. Are they disallowing the use of a FAT file system unless
> there is a license agreement,
> http://www.microsoft.com/mscorp/ip/tech/fat.asp ?

The article is about licensing the intellectual property rights and
patents of the FAT file system.

This has the advantage that they can give licensees the correct
specification of the FAT format, which is often incorrectly 
implemented by third-party software.

In the case of device manufacturers that pay for FAT-preformatted media,
I think the cost is negligible.

In the case of free or open-source software like GNU/Linux, this would
mean removal of FAT file system support (which isn't really a great loss).
(Or a negotation about a special license for the GNU/Linux or other free OS
projects. Perhaps if it's not open-source it might be ok, which would 
simply mean some chunk of binary code to be included for PC-based systems.)

I wonder, if this also applies to boot blocks, which are generally in
FAT format. (perhaps Microsoft's law department didn't even think of that <g>)
 
> : You forget about WinAMP and all the free software on the market.
> 
> This excludes the server side from view.
> What software is used to produce the streams?

There's also free streaming software, like Ogg Vorbis.

> What software is used to produce the media content suitable for
> non-MS/non-Real players?

See above. Plus, anyone can create an independent streaming format
and write a set of client/server tools for it.

> Does it offer "secure" operation, that is D"R"M compatibility?

DRM is already supported by Windows Media Player 9.

That barely anyone is using it shows you how much acceptance it got
on the market. Perhaps this will change in a couple of years, but
DRM does NOT prevent you from using unlicensed data.

(otherwise you couldn't listen to music or videos that you've 
created yourself, which would make no sense because all the 
hobbyist musician and filmmakers would break away along with all
who have to create experimental content in the production process)

> : Even if Micrsoft would provide only a secure Media Player (perhaps as
> : required by the movie and music industry, don't forget that Microsoft
> : has to cooperate with those), you could still use independent software.
> 
> Aha! You may want to study what Jack Valenti has said about
> what the internet is: a distribution channel for media content that
> has to be secured from software piractes to "protect America's greatest
> trade export".

Of course the industry has an interest in protecting their rights.

You don't want everybody to drive with your own car too, do you?

> : The TCPA specification has changed a lot in the light of more or less
> : recent protests from consumers and the press.
> 
> Good "Old Europe". (An interesting variation of a dictum about Europe
> by US DoD officials not long ago.)

Why, what did they say, the US DoD officials?

> : And hence, Microsoft
> : will not make the system a closed operation. In that case, no-one
> : would buy Windows, and that is definitely not in their market interest.
> 
> But how many young people will continue to listen to music on CDs
> when they have to buy each and every of them? How will this affect
> Music Industry? To be continued...

You might already have the answer: In the US, some record company
already is making deals with universities and colleges to make music
available there for free download (and target group screening purposes
of course).

I think the music industry knows quite well how their markets work.
They will have to find new ways to attract customers if the other ones
aren't working anymore.
 
> : There are a lot of unemployed people, and software piracy is simply
> : endangering jobs everywhere.
> 
> ...Interesting. I doubt that Microsoft would have grown that large
> were it not for the widespread illegal copies of DOS and Word
> (and that spread sheet software the name of which I cannot currently
> remember).
> 
> Without software piracy, and by analogy, music piracy, will those who
> are thieves now become buyers then? Where will their money come from?

It all depends on what you spend your money on. You can spend your money
on software as much as you can spend it on your computer hardware.
People often forget what they paid for their hardware. 

Is it really that much to buy just the stuff you need?

At least in my case, it isn't. Despite I don't have much money, I have
quite a good development machine at home with broadband internet access
and all the software and development tools I need. For example, I use
free software wherever possible, like GNAT for Ada, or a trial version
of ObjectAda, I use StarOffice (which I got as a freebie licensed from 
my ISP) instead of Microsoft Office, and so on. For editing I use VIM,
for graphics Paint or GIMP or IrfanView, for some other areas I use 
software that I've written myself, and so on. The only software that I
had to buy were Windows XP and Micrsoft Visual Studio .NET 2002, and
everything else has been licensed thru my ISP or is licensed freeware.
Recently I've rented a virus scanner and spam blocker for a year each, 
an interesting business model that I've had to check out. 

Everything else, like music, videos and stuff has been properly 
licensed or bought. When I have downloads, I've downloaded them on
sites where it explicitly allowed. My personal video recordings are
marked as such and I don't pass them on.

So, as an individual person, I'm free from any unlicensed or pirated
content or software. And it wasn't hard at all. I simply don't buy
the stuff that I cannot afford, nor do I use it.

Companies can do the same, there are often volume licenses for 
companies that lower the price for every place of work, and there's
generally lots of free software that can be used by companies.

To stress the marketing effect of pirated software or content does
not change the fact that it is illegal, and that companies can sue
you for it when you get caught.

(I was once caught in my teen age, and that was enough for me to see
that the benefits of piracy aren't worth the trouble! ;) )
 
> I don't think small compiler companies will always use dongles.
> Is Comeau Computing a large company?
> Don't know about RR Software. Do they use dongles?
> I know of FLEXlm for site licensing for another Ada compiler, but not
> for single user licensing. I think ISE Eiffel uses license files a well.

Well, some software manufacturers will see the need for dongles,
and some don't. 

> And: ACT produces Free Software, GNAT compiler and tools, which
> must still be a costly effort because it is an evolving compiler.
> They don't use copy protection at all you could guess, other than
> the requirement that you may not take the compiler sources,
> rework them, sell the product and store the reworked sources away
> as private property.  Where is the dongle? Will GNAT need "DRM"
> hardware to work in "secure" mode?

GNAT is GPL'd and as such free licensed software.

That is, the license explicitly permits copying.

> : Imagine you take all your money
> : and invest into the development of a compiler, and then you go home
> : and a friend offers you a pirate copy of it. How would YOU feel?
> 
> I wouldn't be surprised. But small companies usually have the time
> to talk to their prospective customers before they hand over a
> copy of their product.

So you think talking to the customer will reveal whether they will
make a pirate copy of it?

I don't know what planet you've been living on in the past decades,
but that method can work only if they have only very few customers.
And that usually implies a large price.

If you spend a couple million bucks on a piece of software, as a 
customer, then of course you make sure that it's not spread around
like sliced bread.

But if you buy an off-the-shelf product for a couple of bucks,
then "why not give a copy of it to your friend?"

But even customers paying large sums for software often give it
away to fellow companies. If your software costs millions,
this can mean millions worth of money that is missing in your
pocket. Hence the need for dongles or something similar, 
especially for small companies.

BTW, some companies developing free licensable software often
make their money with support or consulting contracts.

> In the long run the industry has grown.

Of course, but they have to see the advantages as well.

> : There are already some perfectly
> : legal online music shops that sell songs by professional artists
> : for a couple of cents each. So it IS possible.
> 
> That is not true of your average artist at your avery online store.
> As cheap as ever.

No, I was referring to DRM-supported music shops. You can play the
music that you download only on your own computer and/or transfer it
to recording devices.

> : I think it's a matter of personal maturity whether you let 
> : other people have their share of profits.
> 
> Yes. Exactly. That is why I believe in honest business, not
> in threat, force, and costly safeguard.

Unfortunately, not all people on the customer and/or manufacturer's
side think like you.

I also handle my purchases responsibly. If I had an OS that was
fixed to a particular machine, I would not buy it. Even Windows XP
can be retargeted to a different computer if the current one breaks,
or if you want to move it. And I expect it to.

Many people _do_ make illegal copies of software and/or content,
and the companies react accordingly, "punishing" all.

If you disagree with a company's policies, you can always decide
not to use their products. (sometimes easier said than done,
but it _can_ be done as the whole GNU project shows)

> : We're living in a 
> : cooperative society after all,
> 
> That's an interesting claim if you allow me to include "business"
> in "society".  Is business cooperative, or competitive, or both?

In a very profound sense, we're all dependent on one another.

In the case of a business, the customer might be dependent on the
products or services of a business, while the business is dependent
on the customer to buy them.

And dependency is a sort of cooperative endeavor.

Competition exists between businesses, but also cooperation.

> Will a company invite competitors, or will they try to keep them
> out of projects? What does that say about "cooperative society"?

When a company isn't successful with one path, it can choose another.
There are literally unlimited possibilities of what people can do,
right? If a company is not flexible enough to react to the market
situation, then it will go bankrupt.

(when my employer went bankrupt in March, we were told this would
be the normal way things go, just a regular business case)

It all depends on how you view the world around you: If you see
everyone as your own personal enemy, then things will look difficult,
right? Companies can be successful in competition as well as in
cooperation. It really depends how the companies see themselves
and the world around them.

For example, if you have an apparent competitor that "takes away
your projects", then you could go and negotiate with them what
projects you could do to alleviate their workload or how to help
them to be even more successful. And if they don't want cooperation,
then you could go on a different path, getting different projects,
then you're out of that company's radar. Or you could create a
war chest, figure out how to beat the competitor and begin your
battle. It all depends on what _you_ want.

> And maturity?

Mature would be cooperation on all levels. Which, in the end,
would be the most productive for all parties.

> Nothing. Too many generalisations for my taste. I would make
> non-technical arrangements in order to keep the number of unwelcome
> surprises like license violations low.

You can only do that to a certain extent -- it really depends on
what kind of stuff it's about.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Georg Bauhaus]

Ekkehard Morgenstern <ekkehard.morgenstern@onlinehome.de> wrote:
: 
: "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote:
:> :> Hm. So is it not true that they more or less have woven the shell and
:> :> the graphics subsystem into one thing?
:> : 
:> : Huh?? No.
:> 
:> I checked, not the shell but the Executive. From user mode to
:> kernel mode,
:> http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarwbgen/html/msdn_movuser.asp
: 
: So what?!

I thought that the more the whole system becomes dependent on
the correct working of a graphics driver (module), the less
it is in accord with the principles of modular system design.

: Plus, you're talking about NT 4.0, which is a pink flying elephant
: that doesn't exist anymore. ;)

Except as a frequently used file server? (Be that the right thing
to do or not, reports have been given in this thread.)

: A graphics card driver can tear down the system anyway, whether GDI is
: in user or kernel mode. Or whatever you were alluding to.

Really? Will the LAN port connectivity of a system running
on top of a microkernel be affected by the failure of some
user mode graphics program?

:> Then there is a patent opportunity, so free OS communities will
:> have to consider 4D GUI components to stay competitive :-)
: 
: Don't make fun of it! 3D user interfaces will be considered "normal"
: in a couple of years.

Yes, and I wonder whether this will be more than Disney
animations, given the current lack of creativity in using
2D. ;-)

: In my own OS project (DELOS), I will also experiment with 3D
: user interfaces. 

Do you cooperate with graphics designers and with perception
experts?

: You don't really know what research is or has been going on in that
: area. I've already seen 3D GUI apps on SGI's over a decade ago, so
: it's not uncommon for software developers to invent things like that,
: I guess.

We shouldn't forget that we see things in 3D around us, except on
most computer screens.

: For example, imagine windows could have a flip side, or would be
: cubes or other bodies. With a flip side, in a word processor,
: for example, you could literally turn the pages of your document
: and write on every front and back page. 

That's not it. Boils down to 2D. What you don't have, currently,
is, e.g., hyperlinking other than cross references. I imagine a way of 
visualising things on a computer screen (or some such) that allows
users to poke in several dimensions. All I know in this direction
is, more or less, a 3D onto 2D projection of a file system, and
apparently game backgrounds.  Boring.


Do you remember Ford Prefect experiencing what it is like to
perceive in a virtual world, in the basement of a travel guide
publishers's sky scraper?

: Or you could move windows from back to front or sideways or out
: of view. Or you could be like in a room or sphere and rotate the
: view and hence get to have more things open at the same time.

Or have just one thing opened and see not just one surface of it.

: Just to project a 2D surface into 3D space alone doesn't make a 3D
: user interface. (that's related to the results I've seen of some
: 3D UI working group, which did just that)

Yes.

: Software piracy exists, so why should they not do something about it?

Question is, what should they be doing? Explaining, inviting, requesting?
Or supporting force?

: Microsoft doesn't imply anything. They said they will permit to run
: all kinds of apps on the next generation Windows kernel. So whether you use
: the secure or unsecure subsystem is your business alone.

No it isn't, presuming some data streaming software facts in the backwater
of DRM.  I have tried to hint at movies and Hollywood lobbyist Jack Valenti.

:> : Everything will be as it was before, except that there will be a new
:> : subsystem providing unsecure operation, while the core system will
:> : become secure.
:> 
:> Interesting wording, a little biased towards secure transactions
:> of money I guess?
: 
: Yes, of course. I'm very interested in secure transactions of money. <vbg>

Again, payment may be achieved through agreement on its necessity by
humans, or through technical force based on defamatory prejudice, or
based on possibly generalised single instances.

: If Microsoft serves as the motor of the industry, then why not?

Exactly because they have a chance of at last establishing the
common knowledge that producing computer software is work, and
as every work, needs payment.

: It will definitely create jobs. Software piracy never created any job.

As I said, the spread of PC software, by illegal copying, might have
quite significantly influenced the demand for computer software.
If everyone would have been forced to pay the license fees for DOS
and Word in the 80s, what would the number of personal computer users
have been? How many would use PCs today?
 
: As long as some people keep an eye on what they're doing and scream and
: ramble everytime they lift a finger, then all is well, and Microsoft
: bows to the wishes of the general public. ;)

They also "bow" to the demands of courts, which sentence them to
giving their software to schools at no cost. Well, what a great
opportunity for MS's marketing department, attracting people
in their childhood...  How may times have you heard people say
"Windows" and "PC" as if there were no other possible combination
of personal computer and operating system?

: IBM stopped the development of OS/2 and Visual Age for C++, that's just
: like someone throwing all their gold out of the window and laughing
: merrily that they've relieved themselves of such burden.

http://www-306.ibm.com/software/awdtools/vacpp/

The Mac version has been available as beta software. So, not thrown
out of the window, just two OSs less (OS/2, Windows), and at least two
OSs more (Mac and Linux/pSeries).

:> : You forget about WinAMP and all the free software on the market.
:> 
:> This excludes the server side from view.
:> What software is used to produce the streams?
: 
: There's also free streaming software, like Ogg Vorbis.

Sure, though there are few (portable etc) players...

: anyone can create an independent streaming format
: and write a set of client/server tools for it.

Can they? What is the upfront cost? Will the banks agree to support
yet another way of micro payment, if needed?

: Of course the industry has an interest in protecting their rights.
: You don't want everybody to drive with your own car too, do you?

I wouldn't mind if other car makers used the idea of a steering
wheel in their cars, too. Software patent lobbyists think otherwise.

:> Good "Old Europe". (An interesting variation of a dictum about Europe
:> by US DoD officials not long ago.)
: 
: Why, what did they say, the US DoD officials?

Old Europe. No Good.

: Is it really that much to buy just the stuff you need?

It is a question of percentage. I cannot squeeze a number different 
from 100 out of 100%. If you have spent nn% or your money on music, but
mm% time on listening to music, mm > nn is possible as long as
somehow you have enough CDs, some of which might be copies.
If you can't have CDs for mm% of time any longer, then you
will listen to less CDs, or you will buy less CDs. In the latter case,
the music industry will earn less.  What's likely?

: So, as an individual person, I'm free from any unlicensed or pirated
: content or software. And it wasn't hard at all. I simply don't buy
: the stuff that I cannot afford, nor do I use it.

Thats what I'm trying to say. You don't buy more than you can
afford. But people do in general listen to more than they can
afford. I don't think they are not willing to buy music they like,
its just a maladjusted price that keeps them from buying CDs instead
of coping.

: Well, some software manufacturers will see the need for dongles,
: and some don't. 

Why?

:> And: ACT produces Free Software, ...
:> ...  Where is the dongle? Will GNAT need "DRM"
:> hardware to work in "secure" mode?
: 
: GNAT is GPL'd and as such free licensed software.
: 
: That is, the license explicitly permits copying.

Yes. Why can they or other Free Software companies still operate a
seemingly profitable company without dongles, if so? (You have
mentioned support.)

:> But small companies usually have the time
:> to talk to their prospective customers before they hand over a
:> copy of their product.
: 
: So you think talking to the customer will reveal whether they will
: make a pirate copy of it?
: 
: I don't know what planet you've been living on in the past decades,
: but that method can work only if they have only very few customers.
: And that usually implies a large price.

We had been talking about small companies?
What is your estimate of the number of customers that small
computer companies usually have?
And it need not be large prices for all products, the Comeau compiler
is the best thing I have ever seen for a two digit price.

:> In the long run the industry has grown.
: 
: Of course, but they have to see the advantages as well.

So do we, as customers.

:> : I think it's a matter of personal maturity whether you let 
:> : other people have their share of profits.
:> 
:> Yes. Exactly. That is why I believe in honest business, not
:> in threat, force, and costly safeguard.
: 
: Unfortunately, not all people on the customer and/or manufacturer's
: side think like you.

How many don't?



-- Georg

Piracy was Re: [announcement] SYSAPI and SYSSVC for Windows

[Robert I. Eachus]

Somewhat off topic, but very on-topic as well for those who want to sell 
software...

Georg Bauhaus wrote:

> : Is it really that much to buy just the stuff you need?

But that is just it.  I can't buy the stuff I need.

> It is a question of percentage. I cannot squeeze a number different 
> from 100 out of 100%. If you have spent nn% or your money on music, but
> mm% time on listening to music, mm > nn is possible as long as
> somehow you have enough CDs, some of which might be copies.
> If you can't have CDs for mm% of time any longer, then you
> will listen to less CDs, or you will buy less CDs. In the latter case,
> the music industry will earn less.  What's likely?

That I no longer listen to CD's, but I buy them?  That actually is the 
case.  In many cases I have bought CDs of music, in some cases music 
which I already had purchased on LP or tape, fed the CD into my 
computer, ripped the tracks, and put the CD on a closet shelf, just in 
case I needed to rerip a track at a different rate or something.  But as 
I said.  I no longer listen to CDs, I don't even have a CD player.  At 
home, I have playlists in WinAmp (right now a list called NC (for 
non-commmercial) Christmas. (I also have a Santa playlist, and one with 
both.) Do I still have all the CDs the music on the list came from? 
Probably, but in a number of stacks of CDs in no particular order.

> : So, as an individual person, I'm free from any unlicensed or pirated
> : content or software. And it wasn't hard at all. I simply don't buy
> : the stuff that I cannot afford, nor do I use it.

My attitude as well on software.  In fact there is one shareware program 
I bought several copies of because I liked it so much, and my kids did 
too.  But when it comes to Microsoft, I have literally bought several 
hundred copies of various flavors of Windows that were never used--and a 
dozen that I have used. (Computers bought with Windows 95 or Windows 98, 
then installed Windows NT or Window 2000, set up with multiple disk 
partitions, etc.) For me, a personal "site license" for all versions of 
Windows might make sense--if Microsoft offered a family license that 
covered my immediate family.  This particular box has Windows 2000 
Server, Windows 2000 Workstation, and Windows 98 SE all installed, with 
the CD-ROMs in a rack, along with Red Hat Linux disks, all in the same 
color (Red) jewel box cases.

Next year I expect to switch to Windows XP, but it still isn't ready 
enough for me. (No kidding, of course, the version I am waiting to 
install supports AMD64 in long mode. ;-)  The beta exists, but some of 
the (64-bit) drivers I need are not available yet.

> Thats what I'm trying to say. You don't buy more than you can
> afford. But people do in general listen to more than they can
> afford. I don't think they are not willing to buy music they like,
> its just a maladjusted price that keeps them from buying CDs instead
> of coping.

> : Well, some software manufacturers will see the need for dongles,
> : and some don't. 

Ah, but I see a distinct need for non-dongle versions.  Just like I 
often apply the hacks to games so I don't need the CD-ROM present when 
playing.  I don't want to have to search for the "right" CD to play a 
game from hard drive.  Even less do I want the game to use the CD when 
the disk is much faster.

So in my experience, the dislocation is not really piracy, it is vendors 
who don't want to sell the products that people want to buy.  Would I 
prefer to buy music in MP3 format on CompactFlash compatible cards 
rather than on CD.  Definitely, and I imagine that if the product was 
offered, the volume sold would soon be such that the media price would 
be comparable.  The music vendors could try to copy protect the devices, 
but why? If they did it right, they would be selling non-programmable 
versions of CF cards that cost considerably less to manufacture than
actual flash cards, and the difference could/should go to the musicians 
and the music distributors.  If someone wanted to "pirate" the music and 
sell it on real CF cards, the media costs would kill them. (Depending on 
the compression level used, I can fit several CDs on one 8 Meg card, but 
I usually use 64 Meg cards, and I have never to my knowledge actually 
filled one--other than in my digital camera. ;-)

The situation is getting much better.  There are now services selling 
MP3s on-line.  Comcast as a free offer for Rhapsody, but I am not sure 
it is quite what I want.  $9.95/month, plus charges to "burn" CDs.  I 
don't want to burn CDs, but it may be that I can't use the music as 
presented.  I'm still trying to sort that out.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

Ekkehard Morgenstern wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> Try to install Windows over network!
> 
> There are toolkits supplied by Microsoft to permit remote installing.
> If you know how to use them, it's no big deal.
>  
>> It is also amusing to install NT 4.0 on a relatively modern box. You will
>> have a lot of fancy blue screens.
> 
> Windows NT 4.0 is an anachronism.

It is more stable than 2k/XP, thank to absence of plug'n'pray, I suppose.
Multitasking is also better under NT, at least it is more predictable. So
many of our customers keep sticking to NT. And honestly, I can hardly
remember anything really new in OS API...

> Microsoft doesn't support it anymore,
> either. Even Windows 2000 is outdated. Windows XP is the way to go, it
> does not only include all of Windows 2000 but also all of Windows NT (even
> the OS/2 1.3 and POSIX subsystems exist in XP).

As well as quick basic...

>> Well, an OO OS written in Ada sounds good. However, it would be rather
>> difficult to do in a clear way without multiple inheritance and dispatch,
>> full blown ADT, tagged tasks and protected types, light-weight smart
>> pointers, reasonable sreaming and memory pools support. Ada just has
>> started to catch it, but it has a long way to go.
> 
> Ada 95 just has a different way of doing things.

There is no different way to do things I mentioned. There are only more or
less nasty work-arounds. It is OK for 80% of applications, but for an OS,
using work-arounds in API is the worst thing I can imagine. Nobody needs
one more "adux" or "adows". We need a completely new OS. Scalable from
embedded to mainframe, from real-time to time-sharing etc, and with an OO
API. So if ADT and OO with all their bells and whistles are not supported
by a language (and presently there is no one), it is would be a great
mistake to make the OS API OO.

> If you take your time to
> understand them, you can use them effectively as well.
> 
> I bet the Ada 20xx standard that is in the works will add even more
> interesting stuff to the language.

I bet it will not change the situation. The time of a big cut is yet to
come.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> > Windows NT 4.0 is an anachronism.
> 
> It is more stable than 2k/XP, thank to absence of plug'n'pray, I suppose.

No, it's because NT is smaller and hence less bug-prone.

If you update Windows 2000 or XP regularly using the Windows Update function,
and make sure you have good drivers (for example by getting them from
Microsoft if possible, or the latest from the device manufacturer), they are
no less stable than NT.

> Multitasking is also better under NT, at least it is more predictable. 

That's only because XP is bigger and runs more stuff after booting.
If you disable all unneeded services, and make sure you have drivers
that don't block out the task scheduler, then XP should behave just as good.

> So many of our customers keep sticking to NT. And honestly, I can hardly
> remember anything really new in OS API...

There's truckloads of new stuff in the Windows 2000 and XP system APIs.
Not only everything has improved, but also there's plenty of new stuff.
Many concepts have been adapted from the UNIX world (like job scheduling), 
but there are also new concepts, enhanced graphics, more components, and
so on.

If your customers keep sticking to NT forever, they will have to make
a major investment when upgrading to a new system someday. The current
world is already 2 generations ahead, and the third is already in the 
make (Longhorn).

Some people are still using MS-DOS or Windows 3.1, but that doesn't mean
they're better than what's current.

You can already run 64 bit applications on XP.
 
> As well as quick basic...

So what? Microsoft is ensuring compatability. You can even still run DOS
programs on XP (tho somewhat limited).
 
> There is no different way to do things I mentioned. There are only more or
> less nasty work-arounds. It is OK for 80% of applications, but for an OS,
> using work-arounds in API is the worst thing I can imagine. Nobody needs
> one more "adux" or "adows". We need a completely new OS. Scalable from
> embedded to mainframe, from real-time to time-sharing etc, and with an OO
> API. So if ADT and OO with all their bells and whistles are not supported
> by a language (and presently there is no one), it is would be a great
> mistake to make the OS API OO.

Well, arbitrary inheritance might not be what you want when creating an OS.

Also, wanting features from other languages in Ada might not be the right
solution. Ada has its own concept. We'll see what the Ada20xx committee will
decide upon.

For me, as a C++ programmer, it's also weird to get acquainted with Ada,
but I at least can admit that I like its concepts. And I don't think there's
really something missing in the language, altho new capabilities might
always be good.

All that inheritance stuff present in C++ didn't necessarily lead to better
programs. In fact, C++ programs are often unnecessarily bloated and big.
For example, in Ada I can simply use a limited type when I want to prevent
assignment to it. In C++ I have to declare a private copy constructor and
a private copy assignment, which makes no sense really, in a logical way.
And if I do want to support copying in C++, I have to write at least a 
copy constructor and a copy assignment for every class. Template classes
have nonsensical limitations, and some of the scope rules (like no goto
over initialization) are nonsensical either. To use exceptions in C++,
I have to create a real exception class, while in Ada I can simply declare it,
which greatly speeds up implementation of code supporting exceptions.
In C++, there are no built-in types for concurrent data structures and tasks,
which means you have to use a library, which is almost never portable.

Especially the concurrency aspects of Ada make it ideal as a systems 
programming and implementation language.

The whole OO stuff isn't really necessary for an OS. Abstraction (using types)
and black-boxing (information hiding) is more important than proper OO
inheritance schemes.

BTW, there was/is a fully OO OS, namely BeOS, which used C++. So perhaps you
should support the development of BeOS. I've heard there's a group continuing
its development after Be Inc. abandoned it.

> > If you take your time to
> > understand them, you can use them effectively as well.
> > 
> > I bet the Ada 20xx standard that is in the works will add even more
> > interesting stuff to the language.
> 
> I bet it will not change the situation. The time of a big cut is yet to
> come.

Well, let's see. People interested in reliable software will always be
supporting such languages as Ada.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen]

Ekkehard Morgenstern wrote:
> For example, in Ada I can simply use a limited type when I want to prevent
> assignment to it. In C++ I have to declare a private copy constructor and
> a private copy assignment, which makes no sense really, in a logical way.

It makes a great deal of sense. You wish to prevent assignment,
and therefore you make the assignment operator inaccessible.

> And if I do want to support copying in C++, I have to write at least a 
> copy constructor and a copy assignment for every class.

No, you need to do this only when the default of memberwise-assignment
is not suitable. That implies that class is holding onto some resource
that must not be shared (such as a pointer). It's easier and better to
push down the semantics of copying that shared resource into a class of
its own (generically known as a smart pointer) instead of repeating the
code to copy it everywhere. If you find yourself creating assignment
operators and copy constructors for many classes then you are probably
designing them incorrectly.

> Template classes have nonsensical limitations

I know of several limitations, none of them particularly nonsensical.
(Here are three: 1)Floating point template parameters 2)String literal
template parameters 3)Virtual template methods.)
What exactly do you mean by this?

> (like no goto over initialization) are nonsensical

What exactly would be the semantics of a goto over an initialization?
Do you think you can jump into the middle of a scope in Ada and bypass
the elaboration of the declarations of that scope?

> To use exceptions in C++, I have to create a real exception class,
 > while in Ada I can simply declare it, which greatly speeds up
 > implementation of code supporting exceptions.

So we have an Ada proponent bashing C++ for requiring more typing
(in both senses!)? In any case, the claim is false. In Ada one writes
     Joe : exception;
     raise Joe;
     exception when Joe => ...
If you want the same thing in C++, you say
     struct Joe { };
     throw Joe();
     try { ... } catch (Joe) { ... }

> In C++, there are no built-in types for concurrent data structures and tasks,
> which means you have to use a library, which is almost never portable.

That's true.

> Especially the concurrency aspects of Ada make it ideal as a systems 
> programming and implementation language.

Except that the Ada concurrency system isn't portable either,
except to people who know exactly what they're doing. For
example, scheduling may not be pre-emptive and doing I/O may
block all tasks. And it's not especially clear that you want
to use the concurrency features of a programming language in
an operating system, which after all is there to implement this
concurrency.

> The whole OO stuff isn't really necessary for an OS. Abstraction (using types)
> and black-boxing (information hiding) is more important than proper OO
> inheritance schemes.

What does "really necessary" mean? OO stuff is useful when it's
useful. Certainly driver interfaces tend to be chock full of tables
of function pointers, which suggests that they should be implemented
through inheritance.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Hyman Rosen" <hyrosen@mail.com> wrote:
> Ekkehard Morgenstern wrote:
> > For example, in Ada I can simply use a limited type when I want to prevent
> > assignment to it. In C++ I have to declare a private copy constructor and
> > a private copy assignment, which makes no sense really, in a logical way.
> 
> It makes a great deal of sense. You wish to prevent assignment,
> and therefore you make the assignment operator inaccessible.

If you are writing a lot of tiny classes that require two or three extra lines
of declaration, then it can and will be extra cumbersome.

In Ada, you just declare the type as limited and done with.

Also, in C++ you cannot prevent derivation! Everybody can derive from your 
classes.
 
> > And if I do want to support copying in C++, I have to write at least a 
> > copy constructor and a copy assignment for every class.
> 
> No, you need to do this only when the default of memberwise-assignment
> is not suitable. 

Which can, depending on the project, be a 100% of the cases.

> That implies that class is holding onto some resource
> that must not be shared (such as a pointer). 

Exactly.

> It's easier and better to
> push down the semantics of copying that shared resource into a class of
> its own (generically known as a smart pointer)

I used this since 1995, and called it "AutoPointer". It is still wrong
to omit the declaration of a copy constructor or copy assignment,
because someone could try to copy or assign the object being pointed to.

So that only moves the problem. Also, if an AutoPointer is copied,
it also has to copy the object it is point to, or at least update a 
reference counter.

Work over work over work that really need not be.

> instead of repeating the
> code to copy it everywhere. 

That's BS anyway. You write a copy constructor / copy assignment only
once for the class it affects.

> If you find yourself creating assignment
> operators and copy constructors for many classes then you are probably
> designing them incorrectly.

If you have a lot of objects that cannot be copied by default copy
assignment, then you have to do that. Especially when all of the classes
are independent from each other and held by pointers mostly.

> > Template classes have nonsensical limitations
> 
> I know of several limitations, none of them particularly nonsensical.
> (Here are three: 1)Floating point template parameters 2)String literal
> template parameters 3)Virtual template methods.)
> What exactly do you mean by this?

String literal template parameters could be very useful, for example.
And floating-point template parameters as well, for numerics, for example.

And template classes CAN have virtual methods, or are you referring
to something else?

> > (like no goto over initialization) are nonsensical
> 
> What exactly would be the semantics of a goto over an initialization?
> Do you think you can jump into the middle of a scope in Ada and bypass
> the elaboration of the declarations of that scope?

I haven't tried with Ada yet, but in C++, it seems nonsensical to 
disallow skipping a declaration block with goto, especially since you 
can simulate it using break / continue, where it works!!

Going over an object instantiation could be implemented very easily
by calling the initialization block(s) being skipped first, and then
jumping to the target location. That's a no-brainer, really, requiring
only little extra code in the compiler.

> > To use exceptions in C++, I have to create a real exception class,
>  > while in Ada I can simply declare it, which greatly speeds up
>  > implementation of code supporting exceptions.
> 
> So we have an Ada proponent bashing C++ for requiring more typing
> (in both senses!)? In any case, the claim is false. In Ada one writes
>      Joe : exception;
>      raise Joe;
>      exception when Joe => ...
> If you want the same thing in C++, you say
>      struct Joe { };
>      throw Joe();
>      try { ... } catch (Joe) { ... }

That's similarly short, however, in practice you would pass parameters
to the exception object in C++, and then the class declaration for the
exception gets more complicated. 

Since in Ada that's not possible, Ada is shorter! ;)

Also, in Ada, exceptions are clearly marked "exception". In C++, you
can supply any object as an exception.

> > Especially the concurrency aspects of Ada make it ideal as a systems 
> > programming and implementation language.
> 
> Except that the Ada concurrency system isn't portable either,
> except to people who know exactly what they're doing. For
> example, scheduling may not be pre-emptive and doing I/O may
> block all tasks. And it's not especially clear that you want
> to use the concurrency features of a programming language in
> an operating system, which after all is there to implement this
> concurrency.

Your latter statement is true for the core task switching kernel only.
For all other parts of the OS, using the concurrency features of Ada
can be beneficial. 

That portability thing is true also, since Ada does not define that
tasking must be pre-emptive. However, for my own OS (DELOS) that will not
matter since it'll be pre-emptive anyway (or, if operated on top of
another OS, use the pre-emptive scheduler of that). My own version
of Ada will be pre-emptive in any case. (I'll write an Ada compiler
that generates virtual machine code for my OS, that will translate
it to the host CPU format upon initialization)

> > The whole OO stuff isn't really necessary for an OS. Abstraction (using types)
> > and black-boxing (information hiding) is more important than proper OO
> > inheritance schemes.
> 
> What does "really necessary" mean? OO stuff is useful when it's
> useful. Certainly driver interfaces tend to be chock full of tables
> of function pointers, which suggests that they should be implemented
> through inheritance.

The simple forms of inheritance provided by Ada should be sufficient
for that purpose. 

For my own OS, I will use a message-based driver system (probably using
the task/entry scheme in Ada).

In fact, I learnt about Ada only a couple of weeks ago. Before that,
I wanted to create my own programming language for my OS, and then
I realized that Ada 95 provides exactly what I wanted. :)

Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen]

Ekkehard Morgenstern wrote:
> If you are writing a lot of tiny classes that require two or three extra lines
> of declaration, then it can and will be extra cumbersome.

If those classes contain an unassignable member (and if they don't,
why do you need to prevent assignment of the containing class?), then
using the default assignment operator and copy constructor is not
legal, and will be flagged as a compile-time error. You don't need
any extra declarations.
     struct uncopyable
     {
         uncopyable() { }
     private:
         uncopyable(const uncopyable &);
         uncopyable &operator=(const uncopyable &);
     };

     struct also_uncopyable
     {
         uncopyable u;
     };

> Also, in C++ you cannot prevent derivation!
 > Everybody can derive from your classes.

False. Using the following idiom, no class can be derived from Joe.
     class JoeF { friend class Joe; JoeF() { } };
     class Joe : virtual JoeFinalizer { ... };

> I used this since 1995, and called it "AutoPointer". It is still wrong
> to omit the declaration of a copy constructor or copy assignment,
> because someone could try to copy or assign the object being pointed to.

Huh? If you omit declaring your own, you get the language-specified
default ones, and then attempts to use them will cause compilation
errors, just as you want. Perhaps you have an example which you think
demonstrates the issue?

> So that only moves the problem. Also, if an AutoPointer is copied,
> it also has to copy the object it is point to, or at least update a 
> reference counter.

Well, of course. If you actually want to have the item copied in some
fashion defined for the particular object, you must do the work! But
the point is that you only have to do this work in one place,, and if
you want it to be uncopyable, that only has to be done in one place too.

> Work over work over work that really need not be.

I don't see it. Perhaps you have examples?

> That's BS anyway. You write a copy constructor / copy assignment only
> once for the class it affects.

My point is that, done correctly, you can write this zero times
instead of one time.

> If you have a lot of objects that cannot be copied by default copy
> assignment, then you have to do that. Especially when all of the classes
> are independent from each other and held by pointers mostly.

Those objects should be held by smart pointers, and only the
smart pointers need to implement the assignment operator and
copy constructor. The holding classes will then use these
operations without having to mention them explicitly.

> String literal template parameters could be very useful, for example.
> And floating-point template parameters as well, for numerics, for example.

There's no argument that they can be useful, but the restrictions
are not "nonsensical". There are valid reasons for them, even if
it's possible to envision the restrictions being lifted.

> And template classes CAN have virtual methods, or are you referring
> to something else?

Template methods of a class cannot be virtual.

> I haven't tried with Ada yet, but in C++, it seems nonsensical to 
> disallow skipping a declaration block with goto, especially since you 
> can simulate it using break / continue, where it works!!

I don't know what you think you can do, but you are wrong.
You cannot ever bypass the initialization of objects in a
scope, except by bypassing that scope entirely. Care to post
examples?

> Going over an object instantiation could be implemented very easily
> by calling the initialization block(s) being skipped first, and then
> jumping to the target location. That's a no-brainer, really, requiring
> only little extra code in the compiler.

No, because declarations can appear anywhere in a block,
and initialization can therefore depend on other things
computed earlier.

> Since in Ada that's not possible, Ada is shorter! ;)

No comment.

> Your latter statement is true for the core task switching kernel only.
> For all other parts of the OS, using the concurrency features of Ada
> can be beneficial.

I anxiously await AdaOS which will demonstrate this.

> I'll write an Ada compiler

Yeah, you and Nick Roberts. Your vaporware does not constitute
evidence in the debate of programming language suitability.

In the New York City subway system there's currently a sequence of
ads running for the School of Visual Arts making fun of people who
say things like "Is his art better than the stuff I'm always talking
about doing?" and "She's much too prolific to be any good."

Windows, Unix, and Linux are all wildly successful operating systems
and are written in C and C++. I disregard all claims that Ada can do
as well or better until I actually see an operating system written in
Ada doing as well or better.

> In fact, I learnt about Ada only a couple of weeks ago. Before that,
> I wanted to create my own programming language for my OS, and then
> I realized that Ada 95 provides exactly what I wanted. :)

Sigh.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen]

Hyman Rosen wrote:
> False. Using the following idiom, no class can be derived from Joe.
>     class JoeF { friend class Joe; JoeF() { } };
>     class Joe : virtual JoeFinalizer { ... };

That should be
     class Joe : virtual JoeF { ... };
of course.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Hyman Rosen" <hyrosen@mail.com> wrote:
>      struct also_uncopyable
>      {
>          uncopyable u;
>      };

That's a really good idea! I haven't thought of that yet! 
(*hides in shame*) ;)

If "uncopyable" has zero members, it doesn't even affect structure 
layout. :)

> False. Using the following idiom, no class can be derived from Joe.
>      class JoeF { friend class Joe; JoeF() { } };
>      class Joe : virtual JoeF { ... };

OK. Noted! :)

> > I used this since 1995, and called it "AutoPointer". It is still wrong
> > to omit the declaration of a copy constructor or copy assignment,
> > because someone could try to copy or assign the object being pointed to.
> 
> Huh? If you omit declaring your own, you get the language-specified
> default ones, and then attempts to use them will cause compilation
> errors, just as you want. Perhaps you have an example which you think
> demonstrates the issue?

Yeah, say, you have hundreds of classes that use pointers. 

Like,

    class X {
        A*     a;
        B*     b;
        C*     c;
        ...
    };

If the object needs to be copied, then you have to provide a copy 
constructor and copy assignment, right?

This is something that is elegantly solved in Ada with the access type.
You simply assign and Ada keeps track of the reference.

In C++, you either have to have your own reference counting scheme,
or do a full copy of all enclosed objects.

Or are there other ways to do that that I'm unaware of?

> > Work over work over work that really need not be.
> 
> I don't see it. Perhaps you have examples?

Like, the one I mentioned before. Don't you agree that with Ada access 
types, you have much less overhead than with C++?

> Those objects should be held by smart pointers, and only the
> smart pointers need to implement the assignment operator and
> copy constructor. The holding classes will then use these
> operations without having to mention them explicitly.

But if all your classes depend on pointers, then you have to write
copy assignment and copy constructor for all of your classes,
no matter whether you use smart pointers.

> > String literal template parameters could be very useful, for example.
> > And floating-point template parameters as well, for numerics, for example.
> 
> There's no argument that they can be useful, but the restrictions
> are not "nonsensical". There are valid reasons for them, even if
> it's possible to envision the restrictions being lifted.

For not permitting string literals or floating-point values in
templates, there's no excuse, really.

These values are not uncomparable per se, a distinct string constant
or a distinct floating-point value is still distinct.

In many compilers, template instantiation identifiers are strings
anyway, so that should really be no problem.

Ada for example permits variant records on those kinds of values, right? :)

> > And template classes CAN have virtual methods, or are you referring
> > to something else?
> 
> Template methods of a class cannot be virtual.

What is a "template method of a class" for you?

Something like

    class X {

        template <int a, int b> void func( ... );
    };

?
 
> > I haven't tried with Ada yet, but in C++, it seems nonsensical to 
> > disallow skipping a declaration block with goto, especially since you 
> > can simulate it using break / continue, where it works!!
> 
> I don't know what you think you can do, but you are wrong.
> You cannot ever bypass the initialization of objects in a
> scope, except by bypassing that scope entirely. Care to post
> examples?

That's true. Break and Continue bypass _entire_ scopes. 

As in

    while (1) {
        int a = 5, b = 6;
        if ( cond ) break;
        int c = a + b;
        ...
    }
 
> > Going over an object instantiation could be implemented very easily
> > by calling the initialization block(s) being skipped first, and then
> > jumping to the target location. That's a no-brainer, really, requiring
> > only little extra code in the compiler.
> 
> No, because declarations can appear anywhere in a block,
> and initialization can therefore depend on other things
> computed earlier.

Yeah, now I can see what you mean.

Something like:

    while (1) {
        int a = 5, b = 6;
        if ( cond ) goto L;
        extern void prepare( int&, int& );
        prepare( a, b );
        int c = a + b;
    L:  func( c );
    }

In this case, "goto" would skip both the "prepare" call and the 
computation of "c".

But what about all the other cases in which that doesn't happen?

Like in:

    while (1) {
        int a = 5, b = 6;
        if ( cond ) goto L;
        int c = a + b;
        if ( c == 4711 ) break;
    L:  int d = b + 9;
        func( d );
    }

In this case, skipping the "c" computation block entirely wouldn't
matter at all. But still, C++ doesn't allow it.

Since the compiler knows the source code, it could decide on
an individual basis whether goto was legal.

Or there could be rules on how to handle the goto in such a case.
Like, all declarations are moved to the beginning of the scope
by the compiler if a goto is used inside a scope block. 

Or some other rule.

> > Your latter statement is true for the core task switching kernel only.
> > For all other parts of the OS, using the concurrency features of Ada
> > can be beneficial.
> 
> I anxiously await AdaOS which will demonstrate this.

Well, if I complete mine, it'll not be the only one! :)
 
> > I'll write an Ada compiler
> 
> Yeah, you and Nick Roberts. Your vaporware does not constitute
> evidence in the debate of programming language suitability.
> 
> In the New York City subway system there's currently a sequence of
> ads running for the School of Visual Arts making fun of people who
> say things like "Is his art better than the stuff I'm always talking
> about doing?" and "She's much too prolific to be any good."

LOL!! :)

It's true, my Ada compiler is still vaporware. But I've written
some compilers already for other languages, so it's not entirely ruled
out. :)

I've also written various compiler-compiler toolkits, and I plan to
use one of these or a new Ada one for my new Ada compiler.

(I think writing my own will be quicker than making an existing one
do what I want)

My Ada development-system will have its own database engine and hence
project management will be a piece of cake. Plus, it will probably be
freeware or shareware or open-source.

> Windows, Unix, and Linux are all wildly successful operating systems
> and are written in C and C++. I disregard all claims that Ada can do
> as well or better until I actually see an operating system written in
> Ada doing as well or better.

The programming language isn't what matters. All that matters is the
OS concept itself, whether it will be successful.

Since my project (DELOS) is only my own endeavour so far, I don't think
it'll have any impact on the software industry. For what it's worth,
even if it's just satisfying my own curiousity and ideas, it might 
serve as an example on how to implement such a system.

If it takes me another couple of years, the software industry will
have overtaken me anyway (unless of course I continue updating its
design).

> > In fact, I learnt about Ada only a couple of weeks ago. Before that,
> > I wanted to create my own programming language for my OS, and then
> > I realized that Ada 95 provides exactly what I wanted. :)
> 
> Sigh.

Well, you'd be surprised how fast I learn. ;)

I bought the book "Programming in Ada 95" (2nd ed.) by Barnes,
and it arrived a couple of days ago, and I'll have to do a lot of 
reading. It's a marvellous book btw, ideal for people like me who
want to get an in-depth look at Ada. :)

I had already designed my own language(s) with constrained data types
and stuff. But if Ada works for my project, I don't need a different
language, and Ada is well-known already.

Some of Ada's concepts seemed weird to me at first, but they do
indeed make sense after you let them seep in deeply enough. ;)

Perhaps I'll ask those AdaOS guys what they're doing, perhaps we
can combine our concepts. :)

Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen]

Ekkehard Morgenstern wrote:
> Yeah, say, you have hundreds of classes that use pointers.

If you have them, then you already have code that deals with
them. If you are having to deal with an existing bad design,
then you have a bunch of work ahead of you to fix it. But
"hunfreds of classes that use pointers" doesn't just happen,
someone bad was responsible for creating them.

> This is something that is elegantly solved in Ada with the access type.
> You simply assign and Ada keeps track of the reference.

Say what? An access type is a pointer, nothing more. Ada doesn't keep
track of anything! (Well, if the storage pool goes out of scope, or
soemthing like that, I think Ada frees all the memory in the pool, but
I don't think that's what you're talking about.)

> Or are there other ways to do that that I'm unaware of?

As I said above, I think you are extremely confused about what Ada
does when you copy access types.

> But if all your classes depend on pointers, then you have to write
> copy assignment and copy constructor for all of your classes,
> no matter whether you use smart pointers.

Your classes should not depend upon pointers (unless none of them own
the memory, so that simply copying the pointer is OK). If an object
owns the memory that its member pointer is addressing, then the pointer
should be wrapped up in a smart pointer that will orchestrate the copying
policy. Then the class containing that smart pointer doesn't need a
copy constructor or assignment operator to be user-written. The compiler-
generated one will work properly. And you don't have to write your own
smart pointers. Just go to Boost and use one of theirs.

> For not permitting string literals or floating-point values in
> templates, there's no excuse, really.
> These values are not uncomparable per se, a distinct string constant
> or a distinct floating-point value is still distinct.

Template parameters can be expressions. Allowing floating point
parameters would require discussing the issue of whether x<1.0>
and x<1.0/3.0 + 1.0/3.0 + 1.0/3.0> are the same type or not. It's
doable, but there's enough work involved that they just punted.

Template parameters which are addresses are supposed to be of
objects with external linkage, which string literals are not.
Instead of x<"joe"> you can do char joe[] = "joe"; x<joe>;

> What is a "template method of a class" for you?
> Something like
>     class X {
>         template <int a, int b> void func( ... );
>     };

Yes, exactly. Such a member function template cannot be virtual.

> Or some other rule.

Think of what you're asking - you want people to devote time to
complicated rules about when jumping into the middle of a scope
is legal. If you push them enough, they would just outlaw it
altogether!

> My Ada development-system will have its own database engine and hence
> project management will be a piece of cake. Plus, it will probably be
> freeware or shareware or open-source.

Well, there's already a free-software Ada compiler. Why don't you just
use it as a base for your work instead of trying to recreate all the
knowledge that has gone into making it what it is? A fundamental mistake
made by many programmers is to believe that they can "do it better". They
fail to realize that an existing system may be large and complicated
because it has been modified to handle complex issues and problems that
they do not know about. It's like evolution. The process of modifying
software breeds instincts and behavior into the code which represents
internalized and implicit knowledge of the world. A new project won't
have that.

What you will need to do most of all is to start with small projects
which immediately work and do something useful. If you begin with anything
huge you will never complete it.

> The programming language isn't what matters. All that matters is the
> OS concept itself, whether it will be successful.

All that matters is the execution - the OS must deliver what it promises.
Microkernels are a great OS concept, but they have failed to be the base
of a successful OS.

> Since my project (DELOS) is only my own endeavour so far, I don't think
> it'll have any impact on the software industry.

Yeah, that's what Linus thought!

> Well, you'd be surprised how fast I learn. ;)

No matter how fast you learn, it takes a good long while before it seeps
into your bones.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Hyman Rosen" <hyrosen@mail.com> wrote:
> "hundreds of classes that use pointers" doesn't just happen,
> someone bad was responsible for creating them.

Some concepts require the use of pointers, such as linked lists,
and pointers to instances of objects.

That's not a bad design to create a pointer to a instance of an object.
It's a perfectly normal C++ way of programming.

I don't know what kind of programs you deal with, but you seem
somehow detached from the real world of programming.

> Say what? An access type is a pointer, nothing more. Ada doesn't keep
> track of anything! (Well, if the storage pool goes out of scope, or
> soemthing like that, I think Ada frees all the memory in the pool, but
> I don't think that's what you're talking about.)

Well, some documents say that access types can be garbage collected by
the runtime system.

> Your classes should not depend upon pointers (unless none of them own
> the memory, so that simply copying the pointer is OK).

That's not true. When a pointer points to an object that has been
allocated away from those classes, and the memory associated with it
disappears gets returned to the free pool, then the pointer is invalid
too. Copying a pointer value is about the worst thing you can do, 
unless you know exactly what you're doing.

> If an object owns the memory that its member pointer is addressing, 
> then the pointer should be wrapped up in a smart pointer that will 
> orchestrate the copying policy. 

> Then the class containing that smart pointer doesn't need a
> copy constructor or assignment operator to be user-written. 

That really depends on what kind of class you're dealing with.
Not all pointers can be held in smart pointers, nor be copied.

> The compiler-
> generated one will work properly. And you don't have to write your own
> smart pointers. Just go to Boost and use one of theirs.

As if that would be a major software-engineering task.
 
> Template parameters can be expressions. Allowing floating point
> parameters would require discussing the issue of whether x<1.0>
> and x<1.0/3.0 + 1.0/3.0 + 1.0/3.0> are the same type or not. 

They're not the same. The value might be the same, but it depends
on floating-point accuracy. But to prevent such problems, one
could postulate they aren't the same.

The compiler would simply take those parameters as a string literal,
(which most compilers do for constants in templates anyway).

> Template parameters which are addresses are supposed to be of
> objects with external linkage, which string literals are not.
> Instead of x<"joe"> you can do char joe[] = "joe"; x<joe>;

A string literal becomes an address only in the code generation
phase of the compiler.

For the compiler, it doesn't matter if a string literal is
postulated to be taken literally into the template type signature.

If a programmer would instantiate a template on a pointer then,
the compiler could complain that this special case would imply
using string literals.

> Think of what you're asking - you want people to devote time to
> complicated rules about when jumping into the middle of a scope
> is legal. If you push them enough, they would just outlaw it
> altogether!

There are cases in which gotos into the middle of some context
would be useful.

Sometimes the clarity of code can suffer if the programmer is 
forced to write a work-around for something like that.

That's what programming constructs are for: ease programming.

> > My Ada development-system will have its own database engine and hence
> > project management will be a piece of cake. Plus, it will probably be
> > freeware or shareware or open-source.
> 
> Well, there's already a free-software Ada compiler. Why don't you just
> use it as a base for your work instead of trying to recreate all the
> knowledge that has gone into making it what it is? 

GNAT is based on the GNU Compiler Collection, which in turn depends on
a lot of libraries. If I want an Ada compiler that generates code for my
own virtual machine, I would have to port and modify them all.

This would definitely take more time (understanding all that code,
plus modifying and porting it), than writing an all-new compiler.

I like writing compilers and so that will not be a major effort for me.

> A fundamental mistake
> made by many programmers is to believe that they can "do it better". 

Sometimes they can, it depends on the programmer. I often reinvent the
wheel and get better, smaller, faster, and more reliable results.

That's what programming's all about: creating software.

> They
> fail to realize that an existing system may be large and complicated
> because it has been modified to handle complex issues and problems that
> they do not know about. 

A software that is large and complicated oftentimes is not good software. 
Seemingly complex issues can often be simplified greatly when you 
re-think and rework your concepts and designs.

Many algorithms are like "from the back thru the chest into the eye",
unnecessarily complicated, because the programmer used only existing
algorithms that are not feasible for the problem at hand, or because
s/he couldn't think of a better one.

> It's like evolution. The process of modifying
> software breeds instincts and behavior into the code which represents
> internalized and implicit knowledge of the world. A new project won't
> have that.

Can I quote you on that? ;)

I'm in favour of extreme programming: Something doesn't work, throw it
away, redesign it, rewrite it, recode it. Interestingly, you get a 
better concept every time you do that. Plus, you learn not to cling to
your code as if your life would depend on it. 

In practice, there are often projects you invest a lot of time into,
and then they're thrown away. If you're an extreme programmer, then
you do not only don't care about whether the code is actually used,
but you invest as little time as possible.

Often, when I cannot write something (like a small program or 
component) in two days, I know the concept might be wrong. 

Programming is a form of creative expression and as such subject to
the creative process.

Sometimes you have a great idea and then bam, you write the code 
for it, and it's all good. 

Some ideas evolve over years or decades before they can flow into
a tangible project.
 
> What you will need to do most of all is to start with small projects
> which immediately work and do something useful. If you begin with anything
> huge you will never complete it.

For me that really doesn't matter anymore. I've been programming for,
well, 22 years now (and I began when I was 11).

Like, a compiler might be huge for you, but for me it's just medium-scale.

My OS project is huge, but I'll find a way not only to encapsulate
the hierarchies for it in the simpliest way possible, but also to provide
the simpliest interfaces for it, yet most powerful, for the programmer
as well as the user.

I want to prove someday that is possible that a single person writes
a complete operating system and plenty of applications for it.

(the only compromise I'll have to make is I'll have to make use of
existing hardware drivers, because I cannot own all hardware -- but
my OS will run on top of other OSes, so I can arbitrarily delay the
standalone version) 

> > The programming language isn't what matters. All that matters is the
> > OS concept itself, whether it will be successful.
> 
> All that matters is the execution - the OS must deliver what it promises.
> Microkernels are a great OS concept, but they have failed to be the base
> of a successful OS.

Not true -- AmigaOS had a microkernel (some say picokernel) and it was
wildly successful for almost a decade.

> > Since my project (DELOS) is only my own endeavour so far, I don't think
> > it'll have any impact on the software industry.
> 
> Yeah, that's what Linus thought!

Well, my OS project is still largely vaporware, and I don't know when
I'll find the time to get around to implement all of it.

Unlike Linus, I don't just want to write a kernel, I want to write a
complete OS (possibly sans the HAL in the first phase), and when the
POSIX layer is finished, I can compile and run other GNU projects for
it too.

My OS will be GPL'ed, i.e. in the domain of the GNU project, so if I
actually finish it, others will be able to benefit from it as well,
if they want to. 

> > Well, you'd be surprised how fast I learn. ;)
> 
> No matter how fast you learn, it takes a good long while before it seeps
> into your bones.

Ada is a new programming language to me, and although it seems to be
similar to Pascal or Modula, it has a lot of other intesting concepts.

Yeah, it'll take a while until I fully understand Ada and can take
advantage for it, and rest assured, I won't write a compiler for it
until that happens. ;)

Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen]

Ekkehard Morgenstern wrote:
> Some concepts require the use of pointers, such as linked lists,
> and pointers to instances of objects.

How many times are you going towrite a linked list?
Are you going to have hundreds of linked list implementations
in your program? Is std::list unsuitable for som ereason?

As for pointers to instances, if you mean many pointers to some
single object, then you can copy those pointers around willy-nilly
anyway, so you still don't need custom copy and assignment.

> That's not a bad design to create a pointer to a instance of an object.
> It's a perfectly normal C++ way of programming.

It's a perfectly normal way of C programming.
In C++, it's much more suspect.

> I don't know what kind of programs you deal with, but you seem
> somehow detached from the real world of programming.

I've been doing nothing professionally but programming for twenty years.

> Well, some documents say that access types can be garbage collected by
> the runtime system.

Only if the compiler implements it. By far the vast majority do not,
except for implementations which target JVMs. C++ implementations could
do the smae as well, and many programs use the Boehm conservative collector
in just such a fashion.

> Copying a pointer value is about the worst thing you can do, 
> unless you know exactly what you're doing.

Some of us do, you know.

> That really depends on what kind of class you're dealing with.
> Not all pointers can be held in smart pointers, nor be copied.

Neither of those statements is true.

> As if that would be a major software-engineering task.

Sigh. You may want to look up the discussions on auto_ptr, and have a
look at the implementation of the Boost smart pointers before making
remarks like that. You remind me of those inexperienced mountain climbers
who die on mountains that are far beyond the range of their abilities,
because they do not even know enough to know what things are dangerous.

> They're not the same. The value might be the same, but it depends
> on floating-point accuracy. But to prevent such problems, one
> could postulate they aren't the same.

I'm awaiting with eagerness the ensuing discussions here on c.l.a.
where I get to defend why x<1.0 + 1.0> is different from x<2.0>.

> This would definitely take more time (understanding all that code,
> plus modifying and porting it), than writing an all-new compiler.
> 
> I like writing compilers and so that will not be a major effort for me.

I will now invite the people in this newsgroup who have actually worked
on Ada compilers to respond to this. I'll be over there banging my head
against the wall. Holler if you need me. (Oh, and if your compiler will
target x86 architecture, don't forget to write to Intel and AMD for the
manuals on how to optimize code for each different version of the Pentium
and Athlon procesors.)

> Like, a compiler might be huge for you, but for me it's just medium-scale.

Be sure to let me know when you're done.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Hyman Rosen" <hyrosen@mail.com> wrote:
> I've been doing nothing professionally but programming for twenty years.

Well, so you are not a professional programmer?

Anyway, I think your approach to programming in C++ is very good, altho I do 
not agree with everything for every case.

I've been programming for 22 years, and professionally for 12 years.
 
> > Well, some documents say that access types can be garbage collected by
> > the runtime system.
> 
> Only if the compiler implements it. By far the vast majority do not,
> except for implementations which target JVMs. C++ implementations could
> do the smae as well, and many programs use the Boehm conservative collector
> in just such a fashion.

Garbage collection has its pro and cons, and I'm glad that in Ada it's optional.

There are garbage collected C++ systems, like Microsoft Managed C++ for Windows.
 
> > I like writing compilers and so that will not be a major effort for me.
> 
> I will now invite the people in this newsgroup who have actually worked
> on Ada compilers to respond to this. I'll be over there banging my head
> against the wall. Holler if you need me. (Oh, and if your compiler will
> target x86 architecture, don't forget to write to Intel and AMD for the
> manuals on how to optimize code for each different version of the Pentium
> and Athlon procesors.)

You don't need to write to Intel or AMD to get that information, you can
download it from their websites. I have all of the current Intel and AMD
processor manuals.

However, for my Ada compiler, this won't matter, since it generates code for
a virtual machine of my own design. The virtual machine itself handles
the translation of the code. I will not make the effort of optimizing 
specifically for every CPU out there, only the ones that are current. For
the other CPU's I will generate acceptable code. If I can get the old
optimization guidelines for the old CPUs (some of which might still be
available on their websites), then I might take them into account.

It's all much easier than you think!
 
> > Like, a compiler might be huge for you, but for me it's just medium-scale.
> 
> Be sure to let me know when you're done.

Yes, you will know when I'm done.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen]

Ekkehard Morgenstern wrote:
> This would definitely take more time (understanding all that code,
> plus modifying and porting it), than writing an all-new compiler.
> I like writing compilers and so that will not be a major effort for me.

One of the evolutionary aspects of GNAT is its ability to provide
clear and coherent error messages that direct the programmer's
attention to the most likely problem in an incorrect program. This
has come about through years of feedback, where users of GNAT report
messages which are less than what they would like to see, and GNAT
is augmented to handle those cases.

Without examining GNAT's code, and without access to its test suite,
you will not have the benefit of those feedbacks, and your error
messages will be of low quality.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Hyman Rosen" <hyrosen@mail.com> wrote:
> One of the evolutionary aspects of GNAT is its ability to provide
> clear and coherent error messages that direct the programmer's
> attention to the most likely problem in an incorrect program. This
> has come about through years of feedback, where users of GNAT report
> messages which are less than what they would like to see, and GNAT
> is augmented to handle those cases.

This a very good aspect of GNAT that I already realized when using
it. Before I can make a decision whether to port GNAT and the GCC,
I will have to take a look at its source. I will do that soon.

As I understand the GCC bootstrapping phase, I will have to write
a minimal C compiler that conforms to some rules, and then I can
compile with it the first stage of GCC, and with that the second,
and so on. And then I just need to recompile the GNU libraries
and the GNAT compiler.

However, I haven't looked at the GCC source for some years, so I
have to update myself on that first.

My only concern is, that I won't need all the stuff that comes
with the GCC, the GNU libraries and GNAT. 

The whole concept also makes assumptions about storage of source
files. I want to store all code and sources into a database
and read them from there. Since my database supports versioning,
the scope of file names is inappropriate. My compiler shall work
without files, since I want to use it to write the base of an
operating system. Since many of the GNU projects are file-based,
this might present a problem.

> Without examining GNAT's code, and without access to its test suite,
> you will not have the benefit of those feedbacks, and your error
> messages will be of low quality.

This might indeed be a problem. Perhaps my Ada compiler will only
be for writing the base code that can boot and run the operating
system, and then I can use a POSIX layer to support the GNU stuff,
including GNAT. So on my OS, you would still be able to use GNAT,
if you want to.

I'm using my own compiler-generation tools, and I will write new
ones for Ada, but the automated translation approach that I've 
chosen leaves little possibility for good error messages. In the
horrible first version of my compiler-generator, the source text
would just be accepted or rejected, resulting in a single error
message! ;)  -- of course I cannot uphold that for compilers that
are used by the general public. I will think of a better concept
for my compiler-creation tools that will allow better checks. :)

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

I wrote:
> As I understand the GCC bootstrapping phase, I will have to write
> a minimal C compiler that conforms to some rules, and then I can
> compile with it the first stage of GCC, and with that the second,
> and so on. And then I just need to recompile the GNU libraries
> and the GNAT compiler.

I just downloaded the source for GCC 3.3.2, and yes, the bootstrap
compiler needs a minimal C compiler (K&R compatible), and the
standard C libraries, plus a make tool, a Korn shell or similar
(for the configure script and other scripts), the Ada compiler
requires GNAT for compilation, which has thus also be bootstrapped,
and so on. So I basically have to write a minimum UNIX-compatible
environment to compile GCC and GNAT, if I want to port it to a new
platform (virtual machine).

By then I wouldn't need it anymore, since I would already have an
Ada compiler (because I want to write my virtual machine in Ada).

However, I would port GCC as part of the developent environment
for the user, if my Ada compiler wouldn't be sufficient for 
public usage. I plan to provide a POSIX environment anyway, so
that could be used then to run GCC and the like.

If GCC, or at least the bootstrap part was written in BCPL,
porting it would be far easier! Then I'd just need an INTCODE
interpreter for my platform and bam I could run it.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen]

Ekkehard Morgenstern wrote:
> I just downloaded the source for GCC 3.3.2, and yes, the bootstrap
> compiler needs a minimal C compiler

GCC is fully capable of being built as a cross-compiler, so you do
not necessarily need a bootstrap compiler on your target system.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Hyman Rosen" <hyrosen@mail.com> wrote:
> GCC is fully capable of being built as a cross-compiler, so you do
> not necessarily need a bootstrap compiler on your target system.

Thanks! I haven't thought of that! :)

So I could use an existing platform, write a code generator 
(or description thereof if supported), and then use it as a cross
compiler. Then I could compile all the tools and libraries needed
on the target platform for GCC to compile itself.

Which GCC version would you recommend for doing that?

Re: [announcement] SYSAPI and SYSSVC for Windows

[Stephen Leake]

"Ekkehard Morgenstern" <ekkehard.morgenstern@onlinehome.de> writes:

> "Hyman Rosen" <hyrosen@mail.com> wrote:
> > GCC is fully capable of being built as a cross-compiler, so you do
> > not necessarily need a bootstrap compiler on your target system.
> 
> Thanks! I haven't thought of that! :)
> 
> So I could use an existing platform, write a code generator 
> (or description thereof if supported), 

The code generator in GCC is highly configurable; to port it to a new
CPU, you write a "machine description" file, which specifies how to
translate Register Transition Logic into assembler. See the GCC manual
for more info.

> and then use it as a cross compiler. Then I could compile all the
> tools and libraries needed on the target platform for GCC to compile
> itself.

Yes.

> Which GCC version would you recommend for doing that?

All are appropriate; GCC has been a cross compiler for a very long
time. If you want the fewest bugs in GNAT, use 3.15p.

-- 
-- Stephe

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

Ekkehard Morgenstern wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> > Windows NT 4.0 is an anachronism.
>> 
>> It is more stable than 2k/XP, thank to absence of plug'n'pray, I suppose.
> 
> No, it's because NT is smaller and hence less bug-prone.

That's an interesting view on the nature of progress! (:-))

> If you update Windows 2000 or XP regularly using the Windows Update
> function, and make sure you have good drivers (for example by getting them
> from Microsoft if possible, or the latest from the device manufacturer),
> they are no less stable than NT.
>
>> Multitasking is also better under NT, at least it is more predictable.
> 
> That's only because XP is bigger and runs more stuff after booting.
> If you disable all unneeded services, and make sure you have drivers
> that don't block out the task scheduler, then XP should behave just as
> good.

No the problem is that time slicing functions in some different way. We have
heavily multitasking data acquisition and control applications running
under Windows. When customers expressed a cautious desire to "take a look
at", we discovered that things worked just fine under NT, performed worse
under 2k. Under XP we already needed to play with thread's priorities to
make it working...

>> So many of our customers keep sticking to NT. And honestly, I can hardly
>> remember anything really new in OS API...
> 
> There's truckloads of new stuff in the Windows 2000 and XP system APIs.
> Not only everything has improved, but also there's plenty of new stuff.
> Many concepts have been adapted from the UNIX world (like job scheduling),
> but there are also new concepts, enhanced graphics, more components, and
> so on.

I do not count the stuff you mention as a part of OS. And instead of useless
job scheduling and fancy visual effects, they'd better make DLLs and
drivers being notified upon process termination or at least
ReleaseMutexAndWaitForSingleObject...

> If your customers keep sticking to NT forever, they will have to make
> a major investment when upgrading to a new system someday. The current
> world is already 2 generations ahead, and the third is already in the
> make (Longhorn).
> 
> Some people are still using MS-DOS or Windows 3.1, but that doesn't mean
> they're better than what's current.

Hey, MS-DOS is real-time! (:-))

> You can already run 64 bit applications on XP.

Huh, I ran 64-bit applications on NT four years ago, before Compaq killed
DEC Alpha!

>> As well as quick basic...
> 
> So what? Microsoft is ensuring compatability. You can even still run DOS
> programs on XP (tho somewhat limited).
>  
>> There is no different way to do things I mentioned. There are only more
>> or less nasty work-arounds. It is OK for 80% of applications, but for an
>> OS, using work-arounds in API is the worst thing I can imagine. Nobody
>> needs one more "adux" or "adows". We need a completely new OS. Scalable
>> from embedded to mainframe, from real-time to time-sharing etc, and with
>> an OO API. So if ADT and OO with all their bells and whistles are not
>> supported by a language (and presently there is no one), it is would be a
>> great mistake to make the OS API OO.
> 
> Well, arbitrary inheritance might not be what you want when creating an
> OS.

Then it makes no sense to do it OO.

> Also, wanting features from other languages in Ada might not be the right
> solution. Ada has its own concept. We'll see what the Ada20xx committee
> will decide upon.

It is not about features of other languages. I know no language which
consistently implements ADT (and OO)

> For me, as a C++ programmer, it's also weird to get acquainted with Ada,
> but I at least can admit that I like its concepts. And I don't think
> there's really something missing in the language, altho new capabilities
> might always be good.
> 
> All that inheritance stuff present in C++ didn't necessarily lead to
> better programs. In fact, C++ programs are often unnecessarily bloated and
> big. For example, in Ada I can simply use a limited type when I want to
> prevent assignment to it. In C++ I have to declare a private copy
> constructor and a private copy assignment, which makes no sense really, in
> a logical way.

You need not to advocate for Ada in c.l.a! (:-)) But the example is
unfortunate, both Ada and C++ do assignment wrong, IMO.

> And if I do want to support copying in C++, I have to write
> at least a copy constructor and a copy assignment for every class.

They are rather independent things. The problem of C++ is that I cannot tell
the compiler to derive "=" from copy constructor.

> Template classes have nonsensical limitations, and some of the scope rules
> (like no goto over initialization) are nonsensical either.

True

> To use
> exceptions in C++, I have to create a real exception class, while in Ada I
> can simply declare it, which greatly speeds up implementation of code
> supporting exceptions.

Right. But there are also numerous problems with exceptions in Ada. In
general they fall out of the type system. I do not think as many do, that
C++'s mapping exception->type is good. Ada's exception->object is OK to me.
But I wished to have exceptions a true enumeration type, to have ranges.
And thus extensible enumeration types, and of course a way to put
exceptions in the contract of a subprogram.

> In C++, there are no built-in types for concurrent
> data structures and tasks, which means you have to use a library, which is
> almost never portable.

... and definitely has race conditions problems.

But again, there are problems. We need tasks and protected objects be tagged
types, separate bodies for accept statements, protected actions on multiple
protected arguments, rendezvous with multiple tasks... (I have a large
list)

> Especially the concurrency aspects of Ada make it ideal as a systems
> programming and implementation language.

Oh yes.

> The whole OO stuff isn't really necessary for an OS. Abstraction (using
> types) and black-boxing (information hiding) is more important than proper
> OO inheritance schemes.

I strongly disagree, but perhaps you mean ADT as opposed to OO. But even
then...

> BTW, there was/is a fully OO OS, namely BeOS, which used C++. So perhaps
> you should support the development of BeOS. I've heard there's a group
> continuing its development after Be Inc. abandoned it.
> 
>> > If you take your time to
>> > understand them, you can use them effectively as well.
>> > 
>> > I bet the Ada 20xx standard that is in the works will add even more
>> > interesting stuff to the language.
>> 
>> I bet it will not change the situation. The time of a big cut is yet to
>> come.
> 
> Well, let's see. People interested in reliable software will always be
> supporting such languages as Ada.

Yes, I do!

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> No the problem is that time slicing functions in some different way. We have
> heavily multitasking data acquisition and control applications running
> under Windows. When customers expressed a cautious desire to "take a look
> at", we discovered that things worked just fine under NT, performed worse
> under 2k. Under XP we already needed to play with thread's priorities to
> make it working...

What kind of stuff are you doing?

Why not use message queues and asynchronous I/O internally and stuff?

Even Win 2000 can be amazingly fast (XP even more).

It just depends on how you're approaching your projects. There are often
various ways to do things, and it depends on which way you choose, how
your program will perform. There's almost always a way to do it faster.

> I do not count the stuff you mention as a part of OS. And instead of useless
> job scheduling and fancy visual effects, they'd better make DLLs and
> drivers being notified upon process termination or at least
> ReleaseMutexAndWaitForSingleObject...

Huh?? DLLs ARE notified upon process termination. The DLL has to have a
DllMain() function that receives parameters like DLL_PROCESS_ATTACH and
DLL_PROCESS_DETACH and DLL_THREAD_ATTACH and DLL_THREAD_DETACH.

However, you must not terminate the process forcefully. Under some
conditions, the DLL cleanup is not done properly, but this is documented
well in the Windows API documentation.

A desire in a "ReleaseMutexAndWaitForSingleObject" function smells
like bad multithreading design to me. What is it that you want to achieve
with that?

> > You can already run 64 bit applications on XP.
> 
> Huh, I ran 64-bit applications on NT four years ago, before Compaq killed
> DEC Alpha!

That's true, I was referring to Intel platforms. ;)

> > Also, wanting features from other languages in Ada might not be the right
> > solution. Ada has its own concept. We'll see what the Ada20xx committee
> > will decide upon.
> 
> It is not about features of other languages. I know no language which
> consistently implements ADT (and OO)

In C++ you can use pure virtual classes to provide abstract data types.
And in Java, you use interfaces.

> You need not to advocate for Ada in c.l.a! (:-)) But the example is
> unfortunate, both Ada and C++ do assignment wrong, IMO.

How would you like assignment to be handled?

> They are rather independent things. The problem of C++ is that I cannot tell
> the compiler to derive "=" from copy constructor.

That's true, in C++, operator=() is not inheritable. But that's because of
the way object construction is handled.

> > exceptions in C++, I have to create a real exception class, while in Ada I
> > can simply declare it, which greatly speeds up implementation of code
> > supporting exceptions.
> 
> Right. But there are also numerous problems with exceptions in Ada. In
> general they fall out of the type system. I do not think as many do, that
> C++'s mapping exception->type is good. Ada's exception->object is OK to me.
> But I wished to have exceptions a true enumeration type, to have ranges.
> And thus extensible enumeration types, and of course a way to put
> exceptions in the contract of a subprogram.

Call me a heretic, but I think how Ada handles exceptions is cool! ;)

I'm glad I don't have to specify exceptions in the function/procedure 
contract. Imagine how that would blow the spec declarations out of 
proportion! ;)

(I hated that feature already in C++ and Java and I'm glad it doesn't
exist in Ada) ;)

For example, to show you why it's wrong: At my previous employer,
there were lots of rather inexperienced programmers working on big Java
projects. They would throw exceptions and not declare them properly,
catch them properly and/or omit them from the method contract 
declarations. The result was that there were a lot of bugs related
to exception handling.

Ada really simplifies exceptions a lot. And in the worst case, the
program simply exits. (better than awkward handling and unpredictable
behaviour)

So having exception contracts for subprograms don't really eliminate
the problems (programmers) in front of the computer! ;)

Enumerations for exceptions might also be a bad idea. Imagine if 
someone puts an exception in the middle of some range that wasn't
intended to be there, and *poof*, your good concept goes overboard.

> > In C++, there are no built-in types for concurrent
> > data structures and tasks, which means you have to use a library, which is
> > almost never portable.
> 
> ... and definitely has race conditions problems.

Depends really on how you program. In good multitasking programs,
there are no race conditions! ;-P

> But again, there are problems. We need tasks and protected objects be tagged
> types, separate bodies for accept statements, protected actions on multiple
> protected arguments, rendezvous with multiple tasks... (I have a large
> list)

I solved the accept-thing in my SYSSVC package by calling procedures in the 
accept handlers. :)

Perhaps some of the things that you wanted will go into the new Ada standard.
In the meantime, I guess we have to do without them. ;)

And remember: There's always another way to do it! ;)

Ada 95 provides me with programming conveniences I've never dreamt of before.
It's like cotton candy to me! :)

(of course, as a C++ programmer, in the beginning I've cursed at some of Ada's
peculiarities, but now I like them! ;) )

Hah, you just need to "downgrade" your design a bit and make it simpler,
not as fancy as you would with C++, and boom you get along well with Ada. :)

You do not only save time by doing that, the program will also benefit 
from it with less bugs and smaller footprint. :)

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

Ekkehard Morgenstern wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> No the problem is that time slicing functions in some different way. We
>> have heavily multitasking data acquisition and control applications
>> running under Windows. When customers expressed a cautious desire to
>> "take a look at", we discovered that things worked just fine under NT,
>> performed worse under 2k. Under XP we already needed to play with
>> thread's priorities to make it working...
> 
> What kind of stuff are you doing?

The thing I mentioned was a large automation system for a roller
dynamometer.

> Why not use message queues and asynchronous I/O internally and stuff?

It uses all that. The problem is [very simplified] that two threads which
require approximately same number of time quants per second, get it under
NT, while under XP the balance looks like 8/1, causing stalling of a queue.
Boosting the priority of some of the threads solves the problem, although
leaving a feeling of great discomfort. We have no time for any scientific
researches concerning XP, so we are just waiting for the Service Pack 1000,
Longhorn, Devilhoof, whatsoever! (:-))

> Even Win 2000 can be amazingly fast (XP even more).

You mean, amazingly to what one would expect from a MS product! (:-))

>> I do not count the stuff you mention as a part of OS. And instead of
>> useless job scheduling and fancy visual effects, they'd better make DLLs
>> and drivers being notified upon process termination or at least
>> ReleaseMutexAndWaitForSingleObject...
> 
> Huh?? DLLs ARE notified upon process termination. The DLL has to have a
> DllMain() function that receives parameters like DLL_PROCESS_ATTACH and
> DLL_PROCESS_DETACH and DLL_THREAD_ATTACH and DLL_THREAD_DETACH.
> 
> However, you must not terminate the process forcefully. Under some
> conditions, the DLL cleanup is not done properly, but this is documented
> well in the Windows API documentation.

Yes, this is what I mean - better reboot the box, if a process crashes, and
never ever think to use TerminateProcess...
 
> A desire in a "ReleaseMutexAndWaitForSingleObject" function smells
> like bad multithreading design to me. What is it that you want to achieve
> with that?

To avoid race conditions. Because, it is c.l.a, it is worth to mention how
Ada did solve this, it introduced the requeue-statement.

>> > Also, wanting features from other languages in Ada might not be the
>> > right solution. Ada has its own concept. We'll see what the Ada20xx
>> > committee will decide upon.
>> 
>> It is not about features of other languages. I know no language which
>> consistently implements ADT (and OO)
> 
> In C++ you can use pure virtual classes to provide abstract data types.
> And in Java, you use interfaces.

I meant ADT in the sense of user-defined types. They could be abstract or
not. All languages have problems with that. For example, in Ada you cannot:

   type Handle is private access Object;
private
   type Handle is record -- Private implementation of an access type
      ...
   end record;

>> You need not to advocate for Ada in c.l.a! (:-)) But the example is
>> unfortunate, both Ada and C++ do assignment wrong, IMO.
> 
> How would you like assignment to be handled?

There is no agreement on that. If you ask my opinion, then without much
tinking, about it...

1. User-definable assignment for all types
2. Separated from copy constructor
2. Deriving assignment from a copy constructor on demand
3. Defining the copy constructor through assignment, also on demand
4. An ability to specify the contract so that the semantics of the copy
constructor and assignment are compatible, when not 2 or 3
5. It should be dispatching in both arguments
6. Disallowing assignment in derived types on demand
7. Access to the target before it gets finalized
...

>> > exceptions in C++, I have to create a real exception class, while in
>> > Ada I can simply declare it, which greatly speeds up implementation of
>> > code supporting exceptions.
>> 
>> Right. But there are also numerous problems with exceptions in Ada. In
>> general they fall out of the type system. I do not think as many do, that
>> C++'s mapping exception->type is good. Ada's exception->object is OK to
>> me. But I wished to have exceptions a true enumeration type, to have
>> ranges. And thus extensible enumeration types, and of course a way to put
>> exceptions in the contract of a subprogram.
> 
> Call me a heretic, but I think how Ada handles exceptions is cool! ;)
> 
> I'm glad I don't have to specify exceptions in the function/procedure
> contract. Imagine how that would blow the spec declarations out of
> proportion! ;)

I didn't say I want it in the way Java does it (:-)) If exception contracts
will be adopted in Ada, I assure you, they will be made in a reasonable
Ada-way. For example, the contract or its parts will be inheritable.

> (I hated that feature already in C++ and Java and I'm glad it doesn't
> exist in Ada) ;)
> 
> For example, to show you why it's wrong: At my previous employer,
> there were lots of rather inexperienced programmers working on big Java
> projects. They would throw exceptions and not declare them properly,
> catch them properly and/or omit them from the method contract
> declarations. The result was that there were a lot of bugs related
> to exception handling.

This is statically checkable, so I presume that Ada 2100 would simply spit
an error message.

> Ada really simplifies exceptions a lot. And in the worst case, the
> program simply exits. (better than awkward handling and unpredictable
> behaviour)

... and your heart pacemaker reboots ...

> So having exception contracts for subprograms don't really eliminate
> the problems (programmers) in front of the computer! ;)

Yes, but DbC allows to manage the problems in a better way.

> Enumerations for exceptions might also be a bad idea. Imagine if
> someone puts an exception in the middle of some range that wasn't
> intended to be there, and *poof*, your good concept goes overboard.

No. Ranges in my view should serve the purpose of defining a class of
exceptions. IIF all exceptions has to be of same type, you need ranges for
things like:

exception
   when IO_Faults'Range =>
      -- try to recover here
   when others =>
      -- Clean up

Alternatively one could switch to C++ approach, though deriving all
exceptions from the same base. That has a great disadvange that the size of
an exception object would become unpredictable. This is not what I would
like to see in a real-time embedded system.

>> But again, there are problems. We need tasks and protected objects be
>> tagged types, separate bodies for accept statements, protected actions on
>> multiple protected arguments, rendezvous with multiple tasks... (I have a
>> large list)
> 
> I solved the accept-thing in my SYSSVC package by calling procedures in
> the accept handlers. :)
> 
> Perhaps some of the things that you wanted will go into the new Ada
> standard. In the meantime, I guess we have to do without them. ;)
> 
> And remember: There's always another way to do it! ;)

Work-around is the worst possible thing for an interface.

> Ada 95 provides me with programming conveniences I've never dreamt of
> before. It's like cotton candy to me! :)
> 
> (of course, as a C++ programmer, in the beginning I've cursed at some of
> Ada's peculiarities, but now I like them! ;) )

I learned Ada (83) before C and C++, so I never liked the latter. As for
peculiarities, most of them have a rationale. That's the difference between
Ada and C++. You need to fall in love with C++, blindly, because to like it
rationally, is impossible! (:-))

> Hah, you just need to "downgrade" your design a bit and make it simpler,
> not as fancy as you would with C++, and boom you get along well with Ada.
> :)

In fact, it is the opposite. Ada's approach to OO is much more advanced and
consistent than C++'s one. So one need to downgrade switching to C++.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: 
> The thing I mentioned was a large automation system for a roller
> dynamometer.

What do you need Windows NT for in this application?

You could also use Windows CE or similar, or GNU/Linux, of course,
or QNX, which is said to be a real-time OS.

> > Why not use message queues and asynchronous I/O internally and stuff?
> 
> It uses all that. The problem is [very simplified] that two threads which
> require approximately same number of time quants per second, get it under
> NT, while under XP the balance looks like 8/1, causing stalling of a queue.
> Boosting the priority of some of the threads solves the problem, although
> leaving a feeling of great discomfort. We have no time for any scientific
> researches concerning XP, so we are just waiting for the Service Pack 1000,
> Longhorn, Devilhoof, whatsoever! (:-))

If you want me to take a look at the source, just e-mail me.

I'm sort of an expert for concurrent programming, so I might be able to
show you how to do it on 2000 and XP without any performance problems.

Normally, when you get a timing dependency, you have a design problem.

Windows never had predictable timing, but that's another story, basically
you cannot rely on precise timing. And for almost all applications, you
don't ever need it if you take some precautions and use the right design.
 
> > However, you must not terminate the process forcefully. Under some
> > conditions, the DLL cleanup is not done properly, but this is documented
> > well in the Windows API documentation.
> 
> Yes, this is what I mean - better reboot the box, if a process crashes, and
> never ever think to use TerminateProcess...

Design your application such that it does not depend on DLL cleanup.

The most simple way to detect a previous application failure is to write
a flag somewhere when the application starts, and clear it, when it exists
normally. When the application starts you check whether that flag is set
and perform all necessary cleanup that the previous instance of the process
failed to achieve.

You can use SEH (Structured Exception Handling) to prevent a process from
falling into the system exception handler. You can provide your own, and
make sure everything is cleaned up before the process exits and gets 
restarted.

> > A desire in a "ReleaseMutexAndWaitForSingleObject" function smells
> > like bad multithreading design to me. What is it that you want to achieve
> > with that?
> 
> To avoid race conditions. Because, it is c.l.a, it is worth to mention how
> Ada did solve this, it introduced the requeue-statement.

Race conditions never happen with properly designed multitasking apps.

For example, use the Event objects in Windows to signal conditions and
avoid circular dependencies between data producers and consumers.

Use the new WaitForSingleObjectEx() or WaitForMultipleObjectsEx() functions
to put a thread into an alertable wait state. This is required for 
asynchronous I/O anyway. 

If you wait on multiple conditions at once, use WaitForMultipleObjectsEx().

If you want to terminate a thread, give it a signal and wait on the thread
object for its temination, then close the thread handle. Provide an SEH
handler for every thread to avoid falling into the system exception handler.

If you implement your own message queues on Windows, use an Event object
and a message list (protected by a mutex semaphore). Make the Event object
manual-reset. This way a thread can wait for multiple message queues. 
If a message is to be queued, lock the message list, queue the message,
signal the event object and unlock the message list. If a thread receives
a message, the wait returns and then the thread locks the message list,
consumes all messages and links them into a private message
queue, then resets the event object and unlocks the message list. After
handling of all signalled message queues, it begins processing the messages
in the private queue.

All threads should be serving a particular purpose and not be intertwined
with some logic. If you have a clean design, it's easy to rule out
race conditions.

> I meant ADT in the sense of user-defined types. They could be abstract or
> not. All languages have problems with that. For example, in Ada you cannot:
> 
>    type Handle is private access Object;
> private
>    type Handle is record -- Private implementation of an access type
>       ...
>    end record;

In C++, you simply define a class

    class abstract_class {
        public:
        virtual ~abstract_class() = 0;
        virtual void ifc_func1( void ) = 0;
        ...
    };

    typedef abstract_class* abstract_class_ptr;

To implement a type, simpy write

    class my_type : public abstract_class {
        public:
        virtual ~my_type();
        virtual void ifc_func1( void );
        ...
    };

    typedef my_type* my_type_ptr;

To process an object of any type derived from abstract_class, you simply
use the abstract_class_ptr:

    abstract_class_ptr p = ... ;

    p->ifc_func1();

and the function ifc_func1 of my_type will get called if the pointer 
points to an object of that type.
 
> > So having exception contracts for subprograms don't really eliminate
> > the problems (programmers) in front of the computer! ;)
> 
> Yes, but DbC allows to manage the problems in a better way.

If the programmers all know what they're doing, then it's no problem.

> Alternatively one could switch to C++ approach, though deriving all
> exceptions from the same base. 

btw, that could be simply implemented into Ada as:

    type my_exception is new exception with
    record
           ...
    end record;

So, exception would just have to be a tagged type.

In a subprogram declaration, you could write perhaps:

    procedure f( ... ) raise my_exception;

However, what to do with exceptions raised by the runtime system?
You would also have to write then:

    procedure f( ... ) raise my_exception, Constraint_Error;

for example. The compiler could analyse possible locations for
constraint errors, etc., and then complain if Constraint_Error etc.
are missing from the explicit exception declaration contract.

Programmers often underrate the scope of explicit exception contracts.

To declare exception type ranges, one could write:

    xcpt_a : exception;
    xcpt_b : exception;
    type my_xcpts is ( xcpt_a, xcpt_b );

or
    type my_xcpts is ( xcpt_a : exception, xcpt_b : exception );

For the runtime system this could mean, there'd be a new runtime
exception range called "runtime_exceptions".

Then, in a subprogram contract, you could write:

    procedure f( ... ) raise my_exception, runtime_exceptions'Range;

This would simplify taking account of that.

> Work-around is the worst possible thing for an interface.

Depends really on how you do it. Normally you don't let work-arounds
show up in the interface (in Ada: in the spec).
 
> I learned Ada (83) before C and C++, so I never liked the latter. As for
> peculiarities, most of them have a rationale. That's the difference between
> Ada and C++. You need to fall in love with C++, blindly, because to like it
> rationally, is impossible! (:-))

I don't really like C++, but only for how it forces the programmer to
write a lot of code that isn't really necessary, that's just there to
satisfy the pecularities of the language.

That's true for Ada too, but generally Ada is much shorter than C++.

C++ is well-defined also, btw. There's already a number of ISO standards
for C and C++, and they fulfill the same purpose as the Ada rationale.
Also, Bjarne Stroustrup's C++ books are also valuable when dealing with
the language, since he invented it.

> > Hah, you just need to "downgrade" your design a bit and make it simpler,
> > not as fancy as you would with C++, and boom you get along well with Ada.
> > :)
> 
> In fact, it is the opposite. Ada's approach to OO is much more advanced and
> consistent than C++'s one. So one need to downgrade switching to C++.

Ada 95 is a simple, light-weight programming language compared to C++.

C++ provides almost any OO facility that can be thought of, and
hence offers much more OO constructs than Ada. Plus, it's not as limited.

However, sometimes you don't want to use an elaborate OO design, because
you have to write a lot of extra code just to implement all your class
hierarchies.

I've not completed my Ada studies yet, and I'm still learning, but
from what I've seen, OO programming is very restricted when compared to
C++. However, this must not necessarily be bad.

For example, in my SYSSVC package, I've used procedures of the form

    type T is limited private;
    procedure f( O : in out T );

However, when T has a field that I need to take the address of within
the procedure f(), it isn't possible. I tried various things and ended
up with using an access value:

    type T is limited private;
    type T_Ptr is access T;
    procedure f( O : in T_Ptr );

Then it was possible to create an access to a member of T within the
procedure.

This struck me as weird. Can you explain that?

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

Ekkehard Morgenstern wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> The thing I mentioned was a large automation system for a roller
>> dynamometer.
> 
> What do you need Windows NT for in this application?

Because it is a part of the customer requirement.

>> > Why not use message queues and asynchronous I/O internally and stuff?
>> 
>> It uses all that. The problem is [very simplified] that two threads which
>> require approximately same number of time quants per second, get it under
>> NT, while under XP the balance looks like 8/1, causing stalling of a
>> queue. Boosting the priority of some of the threads solves the problem,
>> although leaving a feeling of great discomfort. We have no time for any
>> scientific researches concerning XP, so we are just waiting for the
>> Service Pack 1000, Longhorn, Devilhoof, whatsoever! (:-))
> 
> If you want me to take a look at the source, just e-mail me.

Thank you, but firstly it is a proprietary code, and secondly it requires a
lot of special hardware.

> I'm sort of an expert for concurrent programming, so I might be able to
> show you how to do it on 2000 and XP without any performance problems.
> 
> Normally, when you get a timing dependency, you have a design problem.

Windows is the actual design problem, and C++ too.

> Windows never had predictable timing, but that's another story, basically
> you cannot rely on precise timing. And for almost all applications, you
> don't ever need it if you take some precautions and use the right design.
> 
>> > However, you must not terminate the process forcefully. Under some
>> > conditions, the DLL cleanup is not done properly, but this is
>> > documented well in the Windows API documentation.
>> 
>> Yes, this is what I mean - better reboot the box, if a process crashes,
>> and never ever think to use TerminateProcess...
> 
> Design your application such that it does not depend on DLL cleanup.

The problem is to tell the customers, that *their* applications should be
designed so that *our* DLLs and hardware drivers would not stray into an
unpredictable state.

>> > A desire in a "ReleaseMutexAndWaitForSingleObject" function smells
>> > like bad multithreading design to me. What is it that you want to
>> > achieve with that?
>> 
>> To avoid race conditions. Because, it is c.l.a, it is worth to mention
>> how Ada did solve this, it introduced the requeue-statement.
> 
> Race conditions never happen with properly designed multitasking apps.

Yep, a properly designed application also works properly! (:-))

> For example, use the Event objects in Windows to signal conditions and
> avoid circular dependencies between data producers and consumers.
[...]
> If you implement your own message queues on Windows, use an Event object
> and a message list (protected by a mutex semaphore). Make the Event object
> manual-reset.

A manual reset event only needed when there could be more than one task
waiting for the event.

>> Alternatively one could switch to C++ approach, though deriving all
>> exceptions from the same base.
> 
> btw, that could be simply implemented into Ada as:
> 
>     type my_exception is new exception with
>     record
>            ...
>     end record;
> 
> So, exception would just have to be a tagged type.

Really? Consider this:

procedure Funny is
   Bomb : aliased Data;
   type Explode is new exception with record
      What : Data_Ptr;
   end record;
begin
   ...
   raise Explode'(What => Bomb'Unchecked_Access);
end Funny;      

Now you are in an exception handler with an exception of a type which was
already finalized!

Observe that the following is absolutely legal and works in Ada:

procedure Test
   procedure Funny is
      A : exception;
   begin
      raise A;
   end Funny;      
begin
   Funny;
exception
   when others =>
      null; -- Handling gone with the wind A
end Test;

See the difference?

> In a subprogram declaration, you could write perhaps:
> 
>     procedure f( ... ) raise my_exception;
> 
> However, what to do with exceptions raised by the runtime system?

One should deal with classes of exceptions. Ada run-time system would define
a class of run-time exceptions automatically inherited by any subroutine,
because all them are declared on the context of the package System.

> You would also have to write then:
> 
>     procedure f( ... ) raise my_exception, Constraint_Error;
> 
> for example. The compiler could analyse possible locations for
> constraint errors, etc., and then complain if Constraint_Error etc.
> are missing from the explicit exception declaration contract.

No, it would be:

   procedure f( ... ) raise ..., not raise Data_Error;

The compiler checks that Data_Error cannot propagate out of f.

> To declare exception type ranges, one could write:
> 
>     xcpt_a : exception;
>     xcpt_b : exception;
>     type my_xcpts is ( xcpt_a, xcpt_b );
> 
> or
>     type my_xcpts is ( xcpt_a : exception, xcpt_b : exception );
> 
> For the runtime system this could mean, there'd be a new runtime
> exception range called "runtime_exceptions".

In Ada ranges are not first-class objects. Alas. Then range is not a type,
it is a value. Then to be usable (in a case-statement) it has to be static.
And so on...
 
>> Work-around is the worst possible thing for an interface.
> 
> Depends really on how you do it. Normally you don't let work-arounds
> show up in the interface (in Ada: in the spec).

This is what I meant. Consider an interface specifying API for drawing
objects on device contexts. This clearly requires multiple dispatch: on the
object type and on the device type, which is not supported by the language.
End of story.

> C++ is well-defined also, btw. There's already a number of ISO standards
> for C and C++,

A *number of* standards, fascinating! (:-))

> and they fulfill the same purpose as the Ada rationale.
> Also, Bjarne Stroustrup's C++ books are also valuable when dealing with
> the language, since he invented it.
> 
>> > Hah, you just need to "downgrade" your design a bit and make it
>> > simpler, not as fancy as you would with C++, and boom you get along
>> > well with Ada.
>> > :)
>> 
>> In fact, it is the opposite. Ada's approach to OO is much more advanced
>> and consistent than C++'s one. So one need to downgrade switching to C++.
> 
> Ada 95 is a simple, light-weight programming language compared to C++.
> 
> C++ provides almost any OO facility that can be thought of,

Come on! C++ does not have:

1. multiple dispatch;
2. dispatch on function result;
3. dispatch on access types;
4. differentiation between class-wide and specific types;
5. functions returning class-wide objects on the stack;
6. streaming / object factory support ('Input, 'Output attributes in Ada);
7. formal derived type parameter for generics;
...

> I've not completed my Ada studies yet, and I'm still learning, but
> from what I've seen, OO programming is very restricted when compared to
> C++. However, this must not necessarily be bad.
> 
> For example, in my SYSSVC package, I've used procedures of the form
> 
>     type T is limited private;
>     procedure f( O : in out T );
>
> However, when T has a field that I need to take the address of within
> the procedure f(), it isn't possible.

Why? The following is OK:

   type T is limited private;
private
   type T is limited record
      I : aliased Integer;
   end T;

   procedure F (O : in out T) is
      type I_Ptr is access all Integer;
      O_I : I_Ptr := O.I'Access;
   begin
      ...

> I tried various things and ended
> up with using an access value:
> 
>     type T is limited private;
>     type T_Ptr is access T;
>     procedure f( O : in T_Ptr );
>
> Then it was possible to create an access to a member of T within the
> procedure.
> 
> This struck me as weird. Can you explain that?

There are two things, the first one is that to get an access one need an
aliased object, the second is the accessibility checks, protecting you from
dangling pointers. It is not clear what it was in your case. Probably it
was:

   procedure F (O : in out T) is
   begin
      ... O'Access; -- Error

This won't compile because of the first reason. Unlikely to C++, in Ada,
only aliased objects can be accessed via pointers. This allows the compiler
to better optimize the code. In rare cases, because pointers should be
avoided anyway, you have to inform the compiler that the object is aliased.
"Aliased" is the keyword for that. Objects of some types are always
aliased:

   type T is tagged limited ...;
   procedure F (O : in out T) is
   begin
      ... O'Access; -- OK, tagged objects are aliased

And finally, if you want to get a pointer in F, then probably

   procedure F (O : access T);

is reasonable.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> The problem is to tell the customers, that *their* applications should be
> designed so that *our* DLLs and hardware drivers would not stray into an
> unpredictable state.

What's the problem communicating this to the customer?

> A manual reset event only needed when there could be more than one task
> waiting for the event.

Yes that, and then some. (sorry I don't have time right now to elaborate)

> > C++ is well-defined also, btw. There's already a number of ISO standards
> > for C and C++,
> 
> A *number of* standards, fascinating! (:-))

For Ada, there's also an '83 and a '95 rationale. ;)
 
> Come on! C++ does not have:
> 
> 1. multiple dispatch;

True, except for constructors and destructors. They're always called for all derived classes of an object.

Regular virtual methods have to call the methods of their parent class if so desired.

> 2. dispatch on function result;

True. Not possible w/ C++.

> 3. dispatch on access types;

False. Method overloading based on parameters of different types, even pointer types, is supported.

> 4. differentiation between class-wide and specific types;

Class-wide types in Ada roughly correspond to base classes in C++.

> 5. functions returning class-wide objects on the stack;

True, but you can return a reference to an object. (I'm not sure if passing a reference to a 
temporary object would work)

> 6. streaming / object factory support ('Input, 'Output attributes in Ada);

There are provisions for that in the C++ streams standard library. But I haven't yet read
about the features in Ada you're talking about.

> 7. formal derived type parameter for generics;

False. Of course you can use derived classes or other types in templates.

> Why? The following is OK:
> 
>    type T is limited private;
> private
>    type T is limited record
>       I : aliased Integer;

Yes, but I is an Integer. Discrete types can always be aliased.

In my case, it was an array of aliased types, and I wanted to create an access
to an array element.

> "Aliased" is the keyword for that. Objects of some types are always
> aliased:
> 
>    type T is tagged limited ...;

so I could've just used a tagged limited record?

Like this:

    type T is tagged limited
    record
        A : My_Array_Type;
    end record;

    procedure F ( O : in out T ) is
        Ptr : My_Array_Cell_Ptr;
    begin
        Ptr := O.A(1)'Access;
    end;

Right?

> And finally, if you want to get a pointer in F, then probably
> 
>    procedure F (O : access T);
> 
> is reasonable.

Unfortuantely I cannot pass this on to the entry points of my task. ;)

So I decided to use a regular access types and Limited_Controlled types.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Georg Bauhaus]

Ekkehard Morgenstern <ekkehard.morgenstern@onlinehome.de> wrote:
:> 7. formal derived type parameter for generics;
: 
: False. Of course you can use derived classes or other types in templates.

I think this is about "type requirements", not uses.

generic
   type D is new T with private;
package P is
...

like 

class P [D -> T] is ...

in Eiffel.

AFAIK, you cannot write
template<typename D> class P {
...
and nothing else and then expect items passed for D to be of
a conforming T type.
If I have understood some hints on Bjarne Stroustrup's web pages
this can be achieved in C++ as well, using suitable identifiers
and template computations.

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

Ekkehard Morgenstern wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> The problem is to tell the customers, that *their* applications should be
>> designed so that *our* DLLs and hardware drivers would not stray into an
>> unpredictable state.
> 
> What's the problem communicating this to the customer?

We are not MS, to tell customers, that they are wrong. (:-))

>> > C++ is well-defined also, btw. There's already a number of ISO
>> > standards for C and C++,
>> 
>> A *number of* standards, fascinating! (:-))
> 
> For Ada, there's also an '83 and a '95 rationale. ;)

Ada 95 practically includes Ada 83, with very minor exceptions. Rationale is
not the standard, it is rather comments to the standard. BTW, there is also
AARM - Annotated Ada Reference Manual.

>> Come on! C++ does not have:
>> 
>> 1. multiple dispatch;
> 
> True, except for constructors and destructors. They're always called for
> all derived classes of an object.

This is not multiple dispatch. MD is when, for example:

type Matrix is tagged ...;
function "+" (X, Y : Matrix) return Matrix;
   -- This is dispatching in X, Y and the result

In C++ only one (hidden) parameter can be dispatching. All others are
contravariant, which leads to numerous nasty pitfalls

>> 3. dispatch on access types;
> 
> False. Method overloading based on parameters of different types, even
> pointer types, is supported.

Overloading, not overriding. In C++:

class X {...};
void f(X * Ptr); // This is not a member of X!

Formally f is not dispatching in Ptr. It is class-wide. Compare it with Ada;

type X is tagged ...
procedure F1 (Object : access X);       -- This is a "member"
procedure F2 (Object : access X'Class); -- This is not

type Y is new X with ...
procedure F1 (Object : access Y);       -- This overrides F1
procedure F2 (Object : access Y'Class); -- This overloads F2

>> 4. differentiation between class-wide and specific types;
> 
> Class-wide types in Ada roughly correspond to base classes in C++.

No. A class-wide type is a closure of the derived types. C++ tries to
equalize specific and class-wide types. The price is that C++ never become
a fully OO langauge, while Ada can do it easily. It possible to make all
types in Ada "tagged", even Boolean.

>> 5. functions returning class-wide objects on the stack;
> 
> True, but you can return a reference to an object. (I'm not sure if
> passing a reference to a temporary object would work)

This won't help, because of 4. The same type name is sometimes denotes
class-wide, sometimes specific in C++. In declarations it is always
specific, so you cannot do:

declare
   X : Object'Class := Get_From_File; -- Any descendant of Object

To achive same effect, you have to use the heap:

   X_Ptr * Object = Get_From_File (); // internally calls new
   ...
   free (X_Ptr); // do not forget to release it

>> 7. formal derived type parameter for generics;
> 
> False. Of course you can use derived classes or other types in templates.

Georg Bauhaus has answered this

>> Why? The following is OK:
>> 
>>    type T is limited private;
>> private
>>    type T is limited record
>>       I : aliased Integer;
> 
> Yes, but I is an Integer. Discrete types can always be aliased.
> 
> In my case, it was an array of aliased types, and I wanted to create an
> access to an array element.

>> "Aliased" is the keyword for that. Objects of some types are always
>> aliased:
>> 
>>    type T is tagged limited ...;
> 
> so I could've just used a tagged limited record?
> 
> Like this:
> 
>     type T is tagged limited
>     record
>         A : My_Array_Type;
>     end record;
> 
>     procedure F ( O : in out T ) is
>         Ptr : My_Array_Cell_Ptr;
>     begin
>         Ptr := O.A(1)'Access;
>     end;
> 
> Right?

No. It is unrelated. The thing you are getting access of has to be aliased.
So it is the array elements which has to be, for example:

   type T is limited private;
private
   type Integer_Array is array (Integer range <>) of aliased Integer;
   type T is limited record
      A : Integer_Array (1..3);
   end record;

   procedure F (O : in out T ) is
   begin
       ... O.A(1)'Access; -- This is OK, A(i) are aliased
   end;

If the array elements be tagged, then you would need not write "aliased" in
the array declaration.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>   type T is limited private;
> private
>    type Integer_Array is array (Integer range <>) of aliased Integer;
>    type T is limited record
>       A : Integer_Array (1..3);
>    end record;
> 
>    procedure F (O : in out T ) is
>    begin
>        ... O.A(1)'Access; -- This is OK, A(i) are aliased
>    end;
> 
> If the array elements be tagged, then you would need not write "aliased" in
> the array declaration.

try to compile it!

GNAT spat out an error message for it: "non-local pointer cannot point to local object"

Here's the source, Luke:

 1: procedure ttest0 is 
 2:    type Integer_Array is array (Integer range <>) of aliased Integer;
 3:    type Integer_Access is access all Integer;
 4:    type T is limited record
 5:       A : Integer_Array (1..3);
 6:       B : Integer_Access;
 7:    end record;
 8:    procedure F( O : in out T ) is
 9:    begin
10:        O.B := O.A(1)'Access; -- This is OK, A(i) are aliased
11:    end;
12:    O1 : T;
13: begin
14:    F( O1 );
15: end ttest0;

ttest0.adb:10:17: non-local pointer cannot point to local object
gnatmake: "ttest0.adb" compilation error

So, what's wrong with it?

Re: [announcement] SYSAPI and SYSSVC for Windows

[Michal Morawski]

Try:
       O.B := O.A(1)'Unchecked_Access; -- This is OK, A(i) are aliased
'Access does not work because in the procedure You are getting address of
the variable (may be) on the stack

Michal Morawski

"Ekkehard Morgenstern" <ekkehard.morgenstern@onlinehome.de> wrote in message
news:bs4fbr$g8f$1@online.de...
>
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> >   type T is limited private;
> > private
> >    type Integer_Array is array (Integer range <>) of aliased Integer;
> >    type T is limited record
> >       A : Integer_Array (1..3);
> >    end record;
> >
> >    procedure F (O : in out T ) is
> >    begin
> >        ... O.A(1)'Access; -- This is OK, A(i) are aliased
> >    end;
> >
> > If the array elements be tagged, then you would need not write "aliased"
in
> > the array declaration.
>
> try to compile it!
>
> GNAT spat out an error message for it: "non-local pointer cannot point to
local object"
>
> Here's the source, Luke:
>
>  1: procedure ttest0 is
>  2:    type Integer_Array is array (Integer range <>) of aliased Integer;
>  3:    type Integer_Access is access all Integer;
>  4:    type T is limited record
>  5:       A : Integer_Array (1..3);
>  6:       B : Integer_Access;
>  7:    end record;
>  8:    procedure F( O : in out T ) is
>  9:    begin
> 10:        O.B := O.A(1)'Access; -- This is OK, A(i) are aliased
> 11:    end;
> 12:    O1 : T;
> 13: begin
> 14:    F( O1 );
> 15: end ttest0;
>
> ttest0.adb:10:17: non-local pointer cannot point to local object
> gnatmake: "ttest0.adb" compilation error
>
> So, what's wrong with it?
>

Re: [announcement] SYSAPI and SYSSVC for Windows

[Ekkehard Morgenstern]

"Michal Morawski" <morawski@zsk.p.lodz.pl> wrote:
> Try:
>        O.B := O.A(1)'Unchecked_Access; -- This is OK, A(i) are aliased
> 'Access does not work because in the procedure You are getting address of
> the variable (may be) on the stack

Yup, unchecked access works (compiles).

thanks! :)

Re: [announcement] SYSAPI and SYSSVC for Windows

[Robert I. Eachus]

Ekkehard Morgenstern wrote:

> "Michal Morawski" <morawski@zsk.p.lodz.pl> wrote:
> 
>>Try:
>>       O.B := O.A(1)'Unchecked_Access; -- This is OK, A(i) are aliased
>>'Access does not work because in the procedure You are getting address of
>>the variable (may be) on the stack
> 
> 
> Yup, unchecked access works (compiles).
> 
> thanks! :)

This is exactly the sort of thing that Unchecked_Access is provided for. 
  You can tell that wherever you can see O.B, O.A must also exist. 
(Even though those names may be long gone.)  At first though, I thought 
that there was a bug here.  There is nothing wrong in general with the 
assignment.  The reason for the error had to do with accessibility 
levels of parameters.  If O is not a parameter:

  procedure ttest2 is
     type Integer_Array is array (Integer range <>) of aliased Integer;
     type Integer_Access is access all Integer;
     type T is limited record
        A : Integer_Array (1..3);
        B : Integer_Access;
     end record;

     O : T;

     procedure F is
     begin
      O.B := O.A(1)'Access; -- This is OK, A(i) are aliased
     end;

  begin
    F;
  end ttest2;

gnatmake ttest2
gcc -c ttest2.adb
gnatbind -x ttest2.ali
gnatlink ttest2.ali

Everything is fine in this case, since the static accessibility levels 
match.  As for the original ttest0, at first I thought it should be 
legal, but there would be a run-time check that could raise 
Program_Error.  (The problem is incidently is not the assignment of the 
access value to O.B, it is taking O.A(1)'Access.) RM 3.10.2(29) says: 
"A check is made that the accessibility level of X is not deeper than 
that of the access type A. If this check fails, Program_Error is raised."

But there is also paragraph RM 3.10.2(28): "The accessibility level of 
the view shall not be statically deeper than that of the access type 
A..."  The static accessability level of the VIEW O.A(1) is that of F:
3.10.2(7): "A parameter of a master has the same accessibility level as 
the master."

So for the first example, there is a legality check, and it is 
independent of the accessiblity level of the object actually passed as a 
parameter to F.  Aren't you glad that 'Unchecked_Access exists for cases 
like this, where you can figure that the access value is safe, even if 
the compiler can't?  Or where it is harder to figure out if the compiler 
will allow it than to prove it safe?

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: [announcement] SYSAPI and SYSSVC for Windows

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Ekkehard Morgenstern wrote:

> > so I could've just used a tagged limited record?
> > 
> > Like this:
> > 
> >     type T is tagged limited
> >     record
> >         A : My_Array_Type;
> >     end record;
> > 
> >     procedure F ( O : in out T ) is
> >         Ptr : My_Array_Cell_Ptr;
> >     begin
> >         Ptr := O.A(1)'Access;
> >     end;
> > 
> > Right?
> 
> No. It is unrelated. The thing you are getting access of has to be aliased.
> So it is the array elements which has to be, for example:
> 
>    type T is limited private;
> private
>    type Integer_Array is array (Integer range <>) of aliased Integer;
>    type T is limited record
>       A : Integer_Array (1..3);
>    end record;
> 
>    procedure F (O : in out T ) is
>    begin
>        ... O.A(1)'Access; -- This is OK, A(i) are aliased

No, that's not quite good enough.  The parameter O is considered to be
nested within F, so you need 'Unchecked_Access instead of 'Access here.
Whenever you use 'Unchecked_Access, you have to make sure you don't
use dangling pointers -- so the & operator in C or C++ is more like
'Unchecked_Access than 'Access in that regard.

The point is: when you say 'Access, the compiler can prove that you
don't have dangling pointers.  Otherwise, you need 'Unchecked_Access
(but then you better prove it yourself, or your program might do bad
things).

>    end;
> 
> If the array elements be tagged, then you would need not write "aliased" in
> the array declaration.

That's not quite right.  Tagged *parameters* (like O in the above
example) are automatically aliased.  But other objects are aliased only
if declared so (by the "aliased" keyword) or if allocated in the heap by
"new" (whether tagged or not).

IMHO, it was a mistake to make tagged parameters automatically aliased.
We should, instead, have allowed the "aliased" keyword on parameters.

Summary: To get an access value to an existing object, you must first
make sure it's aliased (which means allocated on the heap, explicitly
declared "aliased", or a tagged parameter).  Then you must worry about
accessibility level (which determines whether you should use 'Access or
'Unchecked_Access).

- Bob

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Ekkehard Morgenstern wrote:
> 
>> > so I could've just used a tagged limited record?
>> > 
>> > Like this:
>> > 
>> >     type T is tagged limited
>> >     record
>> >         A : My_Array_Type;
>> >     end record;
>> > 
>> >     procedure F ( O : in out T ) is
>> >         Ptr : My_Array_Cell_Ptr;
>> >     begin
>> >         Ptr := O.A(1)'Access;
>> >     end;
>> > 
>> > Right?
>> 
>> No. It is unrelated. The thing you are getting access of has to be
>> aliased. So it is the array elements which has to be, for example:
>> 
>>    type T is limited private;
>> private
>>    type Integer_Array is array (Integer range <>) of aliased Integer;
>>    type T is limited record
>>       A : Integer_Array (1..3);
>>    end record;
>> 
>>    procedure F (O : in out T ) is
>>    begin
>>        ... O.A(1)'Access; -- This is OK, A(i) are aliased
> 
> No, that's not quite good enough.  The parameter O is considered to be
> nested within F, so you need 'Unchecked_Access instead of 'Access here.
> Whenever you use 'Unchecked_Access, you have to make sure you don't
> use dangling pointers -- so the & operator in C or C++ is more like
> 'Unchecked_Access than 'Access in that regard.

It depends on the target, which was not specified.

Then it is a good style to always write 'Access first, and then to try to
understand why it does not compile. Because if it does not, that probably
indicates a potential design problem.

> The point is: when you say 'Access, the compiler can prove that you
> don't have dangling pointers.  Otherwise, you need 'Unchecked_Access
> (but then you better prove it yourself, or your program might do bad
> things).

Yes.

>> If the array elements be tagged, then you would need not write "aliased"
>> in the array declaration.
> 
> That's not quite right.  Tagged *parameters* (like O in the above
> example) are automatically aliased. But other objects are aliased only
> if declared so (by the "aliased" keyword) or if allocated in the heap by
> "new" (whether tagged or not).

Formally yes, but techincally it is no matter. One can always circumvent
this silly limitation (after all the tagged elements of an array remain
tagged!). So:

type Element is tagged ...
type Element_Ptr is access all Element;
type Container is array (Integer range <>) of Element;
   -- Elements are aliased even if not specified

X : Container (1..3);
X_Ptr : Element_Ptr;
...
X_Ptr := X (1)'Unchecked_Access; -- Illegal

But this is OK:

procedure Get_Ptr (E : in out Element; P : out Element_Ptr) is
begin
   P := E'Unchecked_Access;
end Get_Ptr;

Get_Ptr (X (1), X_Ptr); -- This is fine!

> IMHO, it was a mistake to make tagged parameters automatically aliased.

Agree. But this was rather a consequence of the idea of view conversions,
that was the mistake, IMO.

> We should, instead, have allowed the "aliased" keyword on parameters.

No, I think that "aliased" should better be used as a type qualifier:

type X is aliased tagged ...; -- This is a by-reference type
type X is tagged ...; -- The compiler is free to choose
                      -- (with all the consequences)

For parameters there are access types. IMO it is a bad idea to get pointers
to parameters, if that is really needed one should pass a pointer instead.
A good example is Finalize. There is a nasty problem to get a pointer to
the parameter of Finalize, because there is no way to figure out which pool
it should be. For by-reference types it should be sort of:

procedure Finalize (Object : access not all Object_Type); -- (:-))

Then I would disallow overloading like this:

procedure Foo (Object : access Object_Type);
procedure Foo (Object : in out Object_Type);

Instead of this I would make access types transparent to primitive
operations, as they are to array indexing and record member extraction.

> Summary: To get an access value to an existing object, you must first
> make sure it's aliased (which means allocated on the heap, explicitly
> declared "aliased", or a tagged parameter).  Then you must worry about
> accessibility level (which determines whether you should use 'Access or
> 'Unchecked_Access).

-- 
Merry Christmas!
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Robert A Duff wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> >>    procedure F (O : in out T ) is
> >>    begin
> >>        ... O.A(1)'Access; -- This is OK, A(i) are aliased
> > 
> > No, that's not quite good enough.  The parameter O is considered to be
> > nested within F, so you need 'Unchecked_Access instead of 'Access here.
> > Whenever you use 'Unchecked_Access, you have to make sure you don't
> > use dangling pointers -- so the & operator in C or C++ is more like
> > 'Unchecked_Access than 'Access in that regard.
> 
> It depends on the target, which was not specified.

Good point.  If the access type is nested inside F, then 'Access will
work.  That's pretty unusual, in my experience -- almost all types,
including access types, are declared at library level.

> Then it is a good style to always write 'Access first, and then to try to
> understand why it does not compile.

I suppose that's a reasonable thing to do.  You don't want to use
'Unchecked_Access when you could use 'Access -- it's like crying wolf.

>... Because if it does not, that probably
> indicates a potential design problem.

Sometimes, but there are certainly many cases where you want to make a
pointer to a more-nested thing.  You just have to remember to get rid of
the pointer before it causes trouble, just like in C or C++.  One
technique is to use Limited_Controlled -- Initialize hooks the object
into some global data structure, and Finalize takes it out.  That's
relatively safe.

> > We should, instead, have allowed the "aliased" keyword on parameters.
> 
> No, I think that "aliased" should better be used as a type qualifier:
> 
> type X is aliased tagged ...; -- This is a by-reference type
> type X is tagged ...; -- The compiler is free to choose
>                       -- (with all the consequences)

We're not (just) talking about whether parameters are passed by
reference.  We're (also) talking about whether regular variables are
aliased.  It seems to me somewhat dangerous, and deserving of a special
mark on the variable declaration.  (It wasn't allowed at all in Ada 83.)

> For parameters there are access types. IMO it is a bad idea to get pointers
> to parameters, if that is really needed one should pass a pointer instead.

I think I agree with that, but then you trip over another design mistake
-- there's no such thing as an "access constant" parameter.

> A good example is Finalize. There is a nasty problem to get a pointer to
> the parameter of Finalize, because there is no way to figure out which pool
> it should be. For by-reference types it should be sort of:
> 
> procedure Finalize (Object : access not all Object_Type); -- (:-))

I'm not sure what you mean.  How does this tell you what pool Object is
in (maybe none!)?

> Then I would disallow overloading like this:
> 
> procedure Foo (Object : access Object_Type);
> procedure Foo (Object : in out Object_Type);
> 
> Instead of this I would make access types transparent to primitive
> operations, as they are to array indexing and record member extraction.

We proposed something like that (implicit .all) in the early stages of
the Ada 9X project.

I actually don't like implicit dereference at all, even for selected
components.  But the problem is that .all is so verbose and ugly, it
*needs* to be implicit.  If it were up to me, the syntax for dereference
would be Pointer^ (from Pascal), which is unobtrusive, but still makes
the dereference explicit.  Following a pointer and selecting a record
component is semantically much different from just selecting a record
component -- the syntax should convey that.

- Bob

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Robert A Duff wrote:
>> 
>> > We should, instead, have allowed the "aliased" keyword on parameters.
>> 
>> No, I think that "aliased" should better be used as a type qualifier:
>> 
>> type X is aliased tagged ...; -- This is a by-reference type
>> type X is tagged ...; -- The compiler is free to choose
>>                       -- (with all the consequences)
> 
> We're not (just) talking about whether parameters are passed by
> reference.  We're (also) talking about whether regular variables are
> aliased.  It seems to me somewhat dangerous, and deserving of a special
> mark on the variable declaration.  (It wasn't allowed at all in Ada 83.)

Yes of course. There should be a choice: either to make all objects aliased
by declaring the whole type aliased (so by-reference), or to allow the
compiler to choose, but also to have an ability to apply "aliased" to an
object or to a subtype:

declare
   subtype Aliased_Integer is aliased Integer;
   X : Aliased_Integer; -- Same as aliased Integer

To have "aliased" in the parameter profile, would mean an anonymous aliased
subtype. This is OK, but then we should probably to make the consequent
steps allowing anonymous subtypes of all sorts:

procedure Get_Line (Line : in out String (1..Get_Line_Width));

That could be poblematic.

>> For parameters there are access types. IMO it is a bad idea to get
>> pointers to parameters, if that is really needed one should pass a
>> pointer instead.
> 
> I think I agree with that, but then you trip over another design mistake
> -- there's no such thing as an "access constant" parameter.

Yes.

>> A good example is Finalize. There is a nasty problem to get a pointer to
>> the parameter of Finalize, because there is no way to figure out which
>> pool it should be. For by-reference types it should be sort of:
>> 
>> procedure Finalize (Object : access not all Object_Type); -- (:-))
> 
> I'm not sure what you mean.  How does this tell you what pool Object is
> in (maybe none!)?

That was a joke! Though seriosly, there should be some way to work with pool
objects. Presently, pool is decoupled from the object type. It makes sense,
but quite often one wishes to allocate controlled objects in a specific
pool. Maybe we should allow:

type Object_Type is
   new Ada.Finalization.Limited_Pool_Specific with private;
for Object_Type'Storage use Pool;
type Ptr is access Object_Type;
   -- Implies for Ptr'Storage_Pool use Pool;

A : Object_Type; -- Compile error

procedure Foo (A : access Object_Type); -- A is specific to Pool
procedure Finalize (Object : access Object_Type);

With MD we could make Finalize dispatching on both Object and Pool:

procedure Finalize
(  Object : access Object_Type; -- Object is specific to Pool
   Pool   : in out Root_Storage_Pool
);

But this would require too much work.

>> Then I would disallow overloading like this:
>> 
>> procedure Foo (Object : access Object_Type);
>> procedure Foo (Object : in out Object_Type);
>> 
>> Instead of this I would make access types transparent to primitive
>> operations, as they are to array indexing and record member extraction.
> 
> We proposed something like that (implicit .all) in the early stages of
> the Ada 9X project.
> 
> I actually don't like implicit dereference at all, even for selected
> components.  But the problem is that .all is so verbose and ugly, it
> *needs* to be implicit.  If it were up to me, the syntax for dereference
> would be Pointer^ (from Pascal), which is unobtrusive, but still makes
> the dereference explicit.  Following a pointer and selecting a record
> component is semantically much different from just selecting a record
> component -- the syntax should convey that.

I see it completely different. To me an access type should be just a subtype
of the target type, so it would inherit all operations of the "base". To do
it I would allow user-defined subtypes privately implemented in this case
by a hard-wired access type:

   type Object is ...;
   subtype Handle is private Object;
private
   type Handle is access Object;

This would mean that all operations would be transparent, what one indeed
expects from a handle. With appopriate constructors and destructors it
could be made dangling-pointer safe. It would probably make 'Access
attribute and anonymous access types superfluos in most cases. Though there
would definitely be a problem with recursive types to solve.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: [announcement] SYSAPI and SYSSVC for Windows

[Dave Thompson]

On Sun, 21 Dec 2003 14:42:09 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

> Ekkehard Morgenstern wrote:
<snip>
> >> A *number of* standards, fascinating! (:-))
> > 
Aside from the "development under actual use" period, C has had two
full standards (89/90 and 99) and one Normative Amendment (95),
compared to two for Ada. Not *that* different.

> > For Ada, there's also an '83 and a '95 rationale. ;)
> 
> Ada 95 practically includes Ada 83, with very minor exceptions. Rationale is
> not the standard, it is rather comments to the standard. BTW, there is also
> AARM - Annotated Ada Reference Manual.
> 
There was a rationale in C89 (the ANSI-only standard), and is a draft
still being worked on last I looked for C99, but neither of them as
complete or IMO clear, much less integrated, as the ARM annotations.

> >> Come on! C++ does not have:
> >> 
> >> 1. multiple dispatch;
> > 
> > True, except for constructors and destructors. They're always called for
> > all derived classes of an object.
> 
> This is not multiple dispatch. MD is when, for example:
> 
> type Matrix is tagged ...;
> function "+" (X, Y : Matrix) return Matrix;
>    -- This is dispatching in X, Y and the result
> 
Or more generally types not in the same hierarchy like the "standard"
  procedure Eat (X: Animal; Y: Food);

> In C++ only one (hidden) parameter can be dispatching. All others are
> contravariant, which leads to numerous nasty pitfalls
> 
No, in C++ child method parameters are the same type. In fact, trying
to make an overrider covariant instead hides the parent method, which
seems to be a fairly common bug. The *return* type (which in C++ does
not contribute to dispatching) can be covariant, but only as a pointer
or reference; as you note there are no polymorphic/classwide *values*
in C++. The only *contra*variance is in pointer-to-member conversions,
to which Ada has no direct analog I know of.

<snip>
> >> 5. functions returning class-wide objects on the stack;
> > 
> > True, but you can return a reference to an object. (I'm not sure if
> > passing a reference to a temporary object would work)
> 
> This won't help, because of 4. The same type name is sometimes denotes
> class-wide, sometimes specific in C++. In declarations it is always
> specific, so you cannot do:
> 
For an actual object it is always specific; for a pointer or reference
always polymorphic/classwide iff the class has any 'virtual' methods
(i.e. has a vtable = is tagged and not just a record/struct/data).

> declare
>    X : Object'Class := Get_From_File; -- Any descendant of Object
> 
> To achive same effect, you have to use the heap:
> 
Or other programmer-managed storage like static, a private pool, etc.
But not automatic, which is the point.

>    X_Ptr * Object = Get_From_File (); // internally calls new
>    ...
>    free (X_Ptr); // do not forget to release it
> 
You presumably meant free(Object). In fact, officially you must use
delete iff it was allocated with new* and free() iff it was allocated
with C-style malloc-or-friends; implementations of these are not
required to be interchangeable, though they usually if not always are.
(* and even worse delete [] if the new was actually of an array, even
though that may be hidden inside the other module. Which is a good
reason to provide and use an e.g. do_delete method instead.)

- David.Thompson1 at worldnet.att.net