Implementing expected core OS functionality
- From: "James Foster" <james@xxxxxxxxxx>
- Date: Thu, 24 Nov 2005 09:37:06 -0800
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.
.
- Follow-Ups:
- Re: Implementing expected core OS functionality
- From: rush
- Re: Implementing expected core OS functionality
- From: Stefan Schmiedl
- Re: Implementing expected core OS functionality
- Prev by Date: Re: Name Space Support
- Next by Date: Re: Implementing expected core OS functionality
- Previous by thread: getIdleSeconds suggestion
- Next by thread: Re: Implementing expected core OS functionality
- Index(es):
Relevant Pages
|