From: 	Andreas Raab

Andreas>Richard,
RichardSmol> *ack* and I tried the thing with my ol' soundblaster pro!

Andreas>If you've got a C compiler at hand you may try to recompile the VM for 8 bit sound support. All you basically need to do is modifying the BYTES_PER_SAMPLE definition in sqWin32Sound.c

Here we have a good example where we can see that implementing such things in primitives inhibit the modification of the "primitivized" code.

The aproach of having OS-wrappers for all OS (like Windows, Mac, Unix,...) is more evolutive and simple.
Changes can be done in Smalltalk with our tools (senders, implementors, inspectors, CHBrowsers).

A time ago I have done a framework for Object Oriented Metrics that includes design metrics.
One of the metrics (method complexity) computes the complexity of each compiler node assigning it a complexity index.
When I need to assign the complexity index for API calls and for Primitives, I assigned them the values:  API=5 Primitive=9.
A primitive is a too complex structure compared with an API because an API includes the types of the arguments in its definition and the intent is to do a little atomic work. But primitives are normally complex in it protocoll and in it side effects.
Primitives inhibit user evolution/experimentation.

Remember-------
"Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression.
...........
Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework"
-----Daniel H.H. Ingalls  Design Principles Behind Smalltalk - Byte 1981

I think that a good way to evolve is to have a mechanism to build dynamically a Squeak image in layers of compatibility, ALL OF THEM written in Smalltalk (provably the lower level ones compiled to binary code during packaging). The concept is similar to Visual Smalltalk SLLs (or Parcels in Visual Works).
We can load an OS-dependent parcel dynamically.

Sound and Sockets are interesting frameworks, but they are not part of a base Smalltalk image. If we can load/unload them (fast) as a parcel; then each user(men or object) can built the image from requirements.

Again, I think that all our problems solves if we can manage
	(1) External calls, External structures & callbaks.
	(2) Image built from subspaces.
	(3) Exceptions (for more secure works).
This is a great amount of work.
I have implemented External calls and External structures for Windows API calls.
The implementation is easy to port to other OS (like OS/2 and so Unix) but I can't do it because I want to implement callbaks.

Comments will be welcome.
Ale.