Re: [announcement] SYSAPI and SYSSVC for Windows

From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 12/19/03 

Date: Fri, 19 Dec 2003 18:06:22 +0100

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

Relevant Pages

  • Re: Ada exception block does NOT work?
    ... > parent language in not checking certain core operations. ... generally exceptions ... > But as we know from SPARK, use of Ada in such environments ... >> have propagated out of the scope of their definitions. ...
    (comp.lang.ada)
  • Re: Ada exception block does NOT work?
    ... >> Ada has had exceptions, well integrated with the rest of the language, ... >> since Ada 80. ... > language that has no history issue like this. ... An exception at is handled by the handler, ...
    (comp.lang.ada)
  • Re: Ada exception block does NOT work?
    ... > Note that those other languages can throw regular objects as exceptions, ... Well Ada 83 had exceptions but not objects with dispatching so exceptions ... is far better integrated into the language then in C++. ... In Ada can clone any object without the aid of ...
    (comp.lang.ada)
  • Re: Ada exception block does NOT work?
    ... I don't know the full history of Java, but I suppose that it had exceptions from the very beginning. ... Whether those languages tried to mimic the syntax from C++ does not matter at all when it comes to discussion how well the mechanism is integrated into the language. ... One could say that *this* is the point of good integration and that Ada's exceptions are a conceptual patch that did not integrate with the rest of the object model, leading to two separate spaces of language entities instead of only one. ... Note that I'm learning Ada and I'm likely to misunderstand things. ...
    (comp.lang.ada)
  • Re: Ada exception block does NOT work?
    ... creating a new object on the free store can result in failure due to inability of the system to allocate memory. ... feeling that dealing with exceptions is something you just put in very special places, while in Ada you are more inclined to considering exceptions everywhere. ... sure about the "integration with the language" issue. ...
    (comp.lang.ada)