Implementing expected core OS functionality

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementing expected core OS functionality

James Foster-3
Proposal: Implement KernelLibrary>>getTickCount

Justification: Kernel32.dll represents the "kernel" or core functionality of
the host operating system. Most documentation and sample code on Windows
will reference core functionality and for purposes of backwards
compatability, it is often the "least common denominator." Dolphin has
outstanding integration with the native OS capabilities and for the most
part does an excellent jobs of wrapping the Windows API. Because of this
integration, Dolphin provides a wonderful platform for studying the OS API
and I can often port C code easily to Smalltalk without having to think
about integer sizes, types, signs, casting, etc. When I read an article
comparing different APIs, I can often very easily try out the differernt
examples even though they are given in a different language. Likewise, when
studying the MSDN documentation, I will come across a suggested
implementation that references a particular API. When Dolphin provides a
wrapper for that API, then I can continue to just think Smalltalk in my head
even though I'm reading C. I can go to a workspace and try out a call to the
API and see what comes back. When a fundamental API is missing, I'm left
with wondering what I've misread and trying to sort out the stdapi or cdecl
issues.

The MSDN documentation on GetTickCount() suggests that if you need a higher
precision timer you can use the multimedia library, and it would be an
interesting exercise to write some Smalltalk code that compares the two
approaches. I understand that the developers of the base library might think
that a particular API need not be included since another one is available
that should serve better. I respectfully disagree. First, to the extent it
is complete, the base class library can serve as excellent documentation of
the Windows API. Second, code being copied from another language or library
might reference the particular API. Third, one might want to compare
different approaches, and as a learning exercise verify that the newer one
is better.

If a particular API is much better known and used than another approach
(Google references to GetTickCount are 3X those to TimeGetTime), then
including the more popular approach seems to be justified. If another API is
"better," then reference could be made to that fact in the comments.

I can think of three possible reasons why a kernel API would be missing from
the base class library. First, because the provider of the base class
library has limited resources and that particular API is of low priority. As
a developer myself I can certainly understand this limitation. On the other
hand, if someone provides the code to you then the cost should be
significantly reduced. The second reason is that the provider of the tool
wishes to protect the customer from making the "mistake" of writing bad
code. While I understand that this philosophy forms the basis for such Java
design decisions as closed classes, I thought that this attitude was
generally foreign to the Smalltalk community. The only other reason I can
think of for excluding popular core OS functionality is because it would
take up too much space. While I very much appreciate the compact size of the
Dolphin-To-Go EXE, I don't see that this argument applies as well to a
development environment. One of the selling points of "more mature" dialects
(e.g., VisualWorks), is that the base class library is more "complete."
Advertising of these products may make reference to the thousands of classes
and tens of thousands of methods.


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

Stefan Schmiedl
On Thu, 24 Nov 2005 09:37:06 -0800, James Foster wrote:

> Likewise, when studying the MSDN documentation, I will come across a
> suggested implementation that references a particular API. When Dolphin
> provides a wrapper for that API, then I can continue to just think
> Smalltalk in my head even though I'm reading C. I can go to a workspace
> and try out a call to the API and see what comes back. When a
> fundamental API is missing, I'm left with wondering what I've misread
> and trying to sort out the stdapi or cdecl issues.

But once you've done that you've learned much more than just how to use
just another arcane API function.

> One of the selling points of "more mature" dialects (e.g., VisualWorks),
> is that the base class library is more "complete." Advertising of these
> products may make reference to the thousands of classes and tens of
> thousands of methods.

One of the major critiques of those "mature" dialects is that there is
just too much of them, so it's too hard for new users to find their way
around.

I'm all for Keeping it Small and Simple.

Regards,
s.


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

James Foster-3
"Stefan Schmiedl" <[hidden email]> wrote in message
news:[hidden email]...

> On Thu, 24 Nov 2005 09:37:06 -0800, James Foster wrote:
>
>> Likewise, when studying the MSDN documentation, I will come across a
>> suggested implementation that references a particular API. When Dolphin
>> provides a wrapper for that API, then I can continue to just think
>> Smalltalk in my head even though I'm reading C. I can go to a workspace
>> and try out a call to the API and see what comes back. When a
>> fundamental API is missing, I'm left with wondering what I've misread
>> and trying to sort out the stdapi or cdecl issues.
>
> But once you've done that you've learned much more than just how to use
> just another arcane API function.
>
Are you arguing that we'd all be better off coding in assembly since then we
have a much better appreciation for the fact that a bit-shift is a better
way to multiply by 2? I did that 30 years ago and am glad to be beyond it.

>
>> One of the selling points of "more mature" dialects (e.g., VisualWorks),
>> is that the base class library is more "complete." Advertising of these
>> products may make reference to the thousands of classes and tens of
>> thousands of methods.
>
> One of the major critiques of those "mature" dialects is that there is
> just too much of them, so it's too hard for new users to find their way
> around.
>
While I agree that there is a steep initial learning curve for Smalltalk, I
don't agree that excluding a few commonly-referenced APIs from Kernel32.DLL
makes things that much easier. To the extent that Dolphin is positioned as a
substitute for VisualBasic, it seems to me that a complete coverage of
Windows APIs is worthwhile. Telling those VB users that they need to go
study MSDN documentation to find a replacement for some code that they are
porting seems to me to be the wrong approach if the goal is to make their
transition easier.

James


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

Stefan Schmiedl
On Thu, 24 Nov 2005 10:31:23 -0800, James Foster wrote:

> "Stefan Schmiedl" <[hidden email]> wrote in message
> news:[hidden email]...
>> On Thu, 24 Nov 2005 09:37:06 -0800, James Foster wrote:
>>
>>> Likewise, when studying the MSDN documentation, I will come across a
>>> suggested implementation that references a particular API. When Dolphin
>>> provides a wrapper for that API, then I can continue to just think
>>> Smalltalk in my head even though I'm reading C. I can go to a workspace
>>> and try out a call to the API and see what comes back. When a
>>> fundamental API is missing, I'm left with wondering what I've misread
>>> and trying to sort out the stdapi or cdecl issues.
>>
>> But once you've done that you've learned much more than just how to use
>> just another arcane API function.
>>
> Are you arguing that we'd all be better off coding in assembly since then
> we have a much better appreciation for the fact that a bit-shift is a
> better way to multiply by 2? I did that 30 years ago and am glad to be
> beyond it.

No need to exaggerate, James. We're not living in a binary world.
Besides the fact that assembler coding is for wusses (see
http://ars.userfriendly.org/cartoons/?id=19990508), I actually
do have windows applications in production, which I developed in
Forth. But that's besides the point.

The point is that you can't realistically expect any platform to
wrap *all* APIs that are out there. So sooner or later you'll have
to do it for yourself. And why not learn it in a well-documented, hence
easy situation like a WinAPI call?

>>
>>> One of the selling points of "more mature" dialects (e.g.,
>>> VisualWorks), is that the base class library is more "complete."
>>> Advertising of these products may make reference to the thousands of
>>> classes and tens of thousands of methods.
>>
>> One of the major critiques of those "mature" dialects is that there is
>> just too much of them, so it's too hard for new users to find their way
>> around.
>>
> While I agree that there is a steep initial learning curve for Smalltalk,
> I don't agree that excluding a few commonly-referenced APIs from
> Kernel32.DLL makes things that much easier. To the extent that Dolphin is
> positioned as a substitute for VisualBasic, it seems to me that a complete
> coverage of Windows APIs is worthwhile. Telling those VB users that they
> need to go study MSDN documentation to find a replacement for some code
> that they are porting seems to me to be the wrong approach if the goal is
> to make their transition easier.

IMO copy&paste'ing a wrapper for a WinAPI function is not that hard
for a VB programmer used to copy&paste WinAPI declarations into his
VB code. This is dwarfed by the real problem: the paradigm shift between
writing object-flavored Basic scripts and working in a live object-based
environment like a Smalltalk image.

s.


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

Schwab,Wilhelm K
Stefan,

> IMO copy&paste'ing a wrapper for a WinAPI function is not that hard
> for a VB programmer used to copy&paste WinAPI declarations into his
> VB code. This is dwarfed by the real problem: the paradigm shift between
> writing object-flavored Basic scripts and working in a live object-based
> environment like a Smalltalk image.

Agreed.  And as much as I'd like to be wrong, we are not going to get
the average VB programmer to switch to Smalltalk just by giving them
comprehensive API wrappers.

Q: How many psychologists does it take to change a light bulb?
A: Only one, but the bulb has to want to change ;)


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

Sean M-7
In reply to this post by James Foster-3
> Proposal: Implement KernelLibrary>>getTickCount
> generally foreign to the Smalltalk community. The only other reason I can
> think of for excluding popular core OS functionality is because it would
> take up too much space. While I very much appreciate the compact size of
> the Dolphin-To-Go EXE, I don't see that this argument applies as well to a
> development environment. One of the selling points of "more mature"
> dialects (e.g., VisualWorks), is that the base class library is more
> "complete." Advertising of these products may make reference to the
> thousands of classes and tens of thousands of methods.

I'm just curious how much Windows integration you think has been done to
VisualWorks?

BTW, if you are using GetTickCOunt as a timing mechanism, you should look
into the API that Time microsecondsToRun: uses (QueryPerformanceCounter)
because it is a much higher resolution timer.

I can probably think of one reason why OA haven't included GetTickCount,
because they've already got access to the performance counter api, so why
bother wasting their time with a much less accurate timing mechanism?

As for your argument as to why all those other methods should be included
into the base product. While I understand your point of view, my point of
view differs. I haven't needed to access any of the api's you have needed so
I haven't missed them.

I guess I'm wondering why not add them yourself?

And as far as this lack of win32 API in base class library stuff being a
barrier to VB programmers picking up Smalltalk, firstly a) The majority of
VB programmers would have never delved into API calls to begin with, and b)
those that have either cut and paste their way to victory, or they actuially
know what they're doing and can transcribe the C signatures into VB. I would
think that 99% of the people on this newsgroup are very comfortable with
adding api calls to the KernalLibrary et al, and the 1% that aren't, can
either ask here, or look at the other example calls that have already been
done and hack their way to success.

Oh perhaps Object Arts should just redevelop the entire environment in VB to
gain that intimacy with the underlying O/S which it is clearly lacking! (I
hope everyone got the joke)


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

TimM-3
In reply to this post by Schwab,Wilhelm K
James -

Why not take these suggestions, put them a package of your own - and use
loose methods to extend where you see fit. Make it available to download -
and if lots of people download, its a great candidate for the next release.
If not- people who do need it will know where to go to get it.

The environment is so extendable - thats what makes it fun.

Tim


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

Janos Kazsoki
In reply to this post by James Foster-3
James,

your suggestions are nice and useful. Make a (or more) downloadable
Goodie from them and people will like them, and they will visit your
homepage often to see if there is something new gem. (Especially if it
is a member of the Dolphin Ring)

Best regards,
Janos


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

rush
In reply to this post by James Foster-3
James,

How about putting this, along side few more things that you need  into a
goodie? I think this informal goodie process works quite well for Dolphin.
It has several good points:

- you do not have to wait for OA to publish your goodie
- feature gets voted (in a way) by people by using it or not.
- implementation gets time to mature
- feature need not be used by people who do not need/want it
- over the time great goodies get intgrated in to the image, or even better
implementation is offered in the base image
- you get into the hall of fame of goodies authors :)

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/


Reply | Threaded
Open this post in threaded view
|

Re: Implementing expected core OS functionality

Blair McGlashan-3
In reply to this post by James Foster-3
"James Foster" <[hidden email]> wrote in message
news:43860869$[hidden email]...

> "Stefan Schmiedl" <[hidden email]> wrote in message
> news:[hidden email]...
>>...
>> One of the major critiques of those "mature" dialects is that there is
>> just too much of them, so it's too hard for new users to find their way
>> around.
>>
> While I agree that there is a steep initial learning curve for Smalltalk,
> I don't agree that excluding a few commonly-referenced APIs from
> Kernel32.DLL makes things that much easier. To the extent that Dolphin is
> positioned as a substitute for VisualBasic, it seems to me that a complete
> coverage of Windows APIs is worthwhile.

Complete coverage of the entire Win32 API would be a vast, and ongoing (even
now) undertaking. Our point of view is that we'll only typically include an
API where we can provide a more reasonable OO abstraction over the top of
it. Adding such abstractions for the entire Win32 API would probably require
more effort than even MS have available. Writing good abstractions is also
really hard, requiring a deep understanding of both the API as well as
experience and skill in building object models. The abstraction for the
Scintilla control (not part of Win32, but something with a very large non-OO
API) took ages to write and it evolved through many iterations. Even now it
is not perfect or complete.

Personally I don't think adding the APIs as an end in itself is worthwhile.
Occassionally we will add an API without an abstraction purely because we
want to exploit a certain feature in the IDE or class library and don't
necessarily have the time or experience to write a proper abstraction.

>...Telling those VB users that they need to go study MSDN documentation to
>find a replacement for some code that they are porting seems to me to be
>the wrong approach if the goal is to make their transition easier.
>

I've never done a feature comparison, but I doubt there is much in the way
of core features of VB that Dolphin doesn't cover. Other stuff is either
OCXs (which you could equally use with Dolphin), or involves going out to
the Win32 API, and most VB programmers will have done this because VB does
not itself wrap much of that API (far less than Dolphin I'd wager). I'd be
surprised if you could find a VB programmer of even moderate experience who
didn't expect to have to use that text file of API declarations on
occassion, and refer to MSDN (or some VB website) for information on how to
use a Win32 API.

As far as APIs that are not currently wrapped by Dolphin are concerned we
provide two things:
1) A pattern for the naming of external methods that means that two
individuals wrapping the same method are likely to come up with the same
definition; and
2) An ever expanding type-library that I make available from time to time.
This is based on the old VB Win32 type library hosted by The Mandelbrot Set,
but I've corrected the corruptions in that needed because VB didn't support
unsigned integers, etc. Its also includes more of the up-to-date APIs. I'd
really like to turn this into a community project, but since it's sources
includes copyrighted material from Microsoft I don't think I could legally
do that.

My preferred approach whenever I want to wrap a Win32 API is to either
generate it from this type library if it is already defined in there, or I
extend the type library. I would always do this in preference to writing the
ExternalLibrary methods by hand in Dolphin because experience has shown that
the manually written methods and structures have a lot of errors in them,
the auto-generation process is repeatable, it is frequently much less work
as well.

In Dolphin X6 you will find a wrapping of the GDI+ subsystem which is the
result of a collaborative effort. This started off by generating the raw API
(there is a flat API underlying the C++ classes) from a type library built
from the C header files. The API is huge. The collaborators (acknowledged in
the package comment) then did the greater work of building abstractions,
tests and examples over the top of this.

Regards

Blair