Universal Virtual Machine 
Author Message
 Universal Virtual Machine


Quote:

> > ... We had discussion about this in the past, its only time before a
third-party
> > makes a VM that emulates the Microsoft .NET bytecode.  David Simmons
even
> > went as far as saying that it might be a technology he himself may
posess or
> > it may not be a difficult task to support this on any good VM.  However,
he
> > also pointed out, that creating all the frameworks that Microsoft is
going
> > to be shipping with Microsoft .NET is going to be a much more monumental
> > task..

> I don't get this. You are supposed to be able to use 'any' language
> with  the .NET . If the frameworks are there, you should be able to call
> them from Smalltalk, without having to write them yourself. Even  going
> to another platform, you should be able to run the libraries already
> created in a .NET language and port them.  ?  All you need is .NET
> Virtual Machine, right ?  Just like Java libraries are mostly written in
> Java, and all you need is the VM.

I think your confusion stems from the way the comment was worded. There are
actually two separate ideas entangled here.

First, is what it would take to build a non Microsoft version of .NET. Which
is what Ian's comment was basically referring to.

The Second, is the question of what is required to change Smalltalk such
that it can be implemented for (some version of) .NET to allow full access
to, and integration with, the frameworks and services of .NET.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

- Show quoted text -

Quote:

> -Panu



Tue, 05 Aug 2003 05:20:55 GMT  
 Universal Virtual Machine

Quote:
> One thing that has disappointed me about .NET and Java is that these VMs
do
> not appear to provide good support for Smalltalk.

> [ re. .NET -- I have been a little confused by some of David Simmons'
posts.
> Although he has been quite helpful and informative, I am left with the
> impression that .NET will support SmallScript, but not Smalltalk as most
of
> us in this group understand Smalltalk.]

Sorry for creating that confusion. Maybe this post will help?

Then again, it is really long and almost certainly controversial so it may
actually do the opposite :-(

Hopefully those who choose to comment upon it, will comment on selected
sections in separate posts rather than bundling it all together :) [which of
course I didn't do]

Quote:

> Whether .NET supports Smalltalk or not is not relevant.

Well, its relevant to me as the person who has developed Smalltalk for .NET
and has worked long and hard with Microsoft to continue to ensure that .NET
has the necessary elements to support Smalltalk.

Quote:
> It is proprietary
> and closed (I wonder if Microsoft understands that .NET is supposed to be
> the operating system, not something you package with Windows or Windows CE
> or whatever they're calling it now).

Your comments regarding "proprietary" and "closed" are not "strictly
speaking" correct. The .NET specification is open and becoming a standard
via the ECMA process. A standard which is likely to be ratified and adopted
before the end of this year; in a process which involves many companies
including (and perhaps most notably) Sun Microsystems.

http://www.*-*-*.com/

http://www.*-*-*.com/

The idea that Microsoft may not understand that .NET is "supposed to be an
operating system" is coming from left field.

I.e., Microsoft created and defined .NET, so de-facto they "defined" what it
is "supposed to be".

More to the point, I would contend that they intentionally designed it as a
technology to enable them to break their technology base free of both the
INTEL and Windows OS Family ties [and perhaps the Justice Department focus].
Which means they defined a "platform", which is not the same thing as an
"operating system".

Microsoft's .NET itself is very real and it really works. Microsoft has
barely begun marketing it. It will be at least as pervasive as COM, ActiveX,
Visual Basic, and IE/ASP/IIS Scripting. The heat in this area just has not
been turned up by Microsoft because they are, as usual, being
(instinctually) wily/smart about preparing all the adjunct software they own
or believe is key for the .NET. Once they reach that stage, they'll crank up
the heat and .NET will be de-facto reality.

In my judgment, one thing to understand about Microsoft is that their
*typical* "pragmatic" pattern, unlike companies such as Sun and Apple, is to
have solved a problem and implemented a solution that "to their
satisfaction" corresponds to what they think/believe they are promoting.
Their rationale is that by the time the world starts to care Microsoft has a
huge lead or {*filter*} position that everyone else has to try and
overcome/catch up to.

That's part of how COM/ActiveX/OLE was able to completely crush Apple's
OpenDoc (and IBM's SOM) component technology [which is/was competition to
CORBA]. And .NET is just the next evolution of the COM/ActiveX/OLE
components and systems interop scalability story.

I would suggest that .NET is about Microsoft's efforts to keep moving
towards a {*filter*} position regarding internet (and enterprise) deployment
and systems platform technology. I.e., .NET platform versus JVM platform
versus Apache/Linux collective, In my opinion, for Microsoft, it was never
about the language of Java -- that's why those who made or make noise about
C# are just missing the whole point.

Quote:

> Neither does the Java VM support Smalltalk the way we know it today
(Bistro
> is a nice idea, but I don't think it's Smalltalk).

> In general, languages like Java, C#, and even Bistro and SmallScript
(IMHO)
> seem to be taking Smalltalk in the opposite direction it should be going.

What does Java or C# have to do with where Smalltalk is or is *not* going?

Where is SmallScript taking Smalltalk, that it should not be going?

    Smaller?
    Faster?
    More portable?
    Applicable to more of today's software tasks?
    More interoperable with other languages and systems?
    More capable of supporting multiple dialects/libraries
         simultaneously (incl non-Smalltalk)?
    More expressive for explicit enforcement of contracts?
    More scalable and deployable via the namespace, module,
         and interface technology QKS defined?
    More approachable and mainstream via familiar constructs
         from languages such as python, jscript, and c++?
    Retaining Smalltalk syntax/source compatibility.

The wrong directions are backwards and status quo.

There is a lot of important pioneering/implementation work that has been
done in the non st-80 derived dialects; and still continues to be done to
keep Smalltalk growing, evolving and competitive as a technology and as a
marketplace.

For example, take Smalltalk MT which has pioneered important new techniques
for Smalltalk implementation with their static compilation and its ability
to make small components/modules. It has significantly opened the
possibilities for Smalltalk applicability.

Quote:
> And Smalltalk definitely needs to be going somewhere. For example, Self
> seems like a step in the right direction to me. But Self was buried by
Java
> and it doesn't appear to have much energy right now.

> Boris' recent posts regarding Lisp (here and in comp.lang.lisp) have me
> intrigued about things like meta-object capabilities. In our own work on
> Visual Knowledge, the modeling constructs provided by "vanilla" Smalltalk
> have proved inadequate and we have tried to extend those in creative ways
> (e.g. by developing a rather baroque, but useful prototyping system).

> IBM was trumpeting a UVM as part of their VisualAge offerings a year or
two
> ago, but I haven't seen much reference to that of late.

> What I am thinking of is an open source project to create a standard VM
for
> Smalltalk but that also supports other languages, such as Java and perl,
and
> more importantly, new language directions for Self-like and MOP extensions
> to Smalltalk. Similar to the Transmeta architecture (except all in
> software), one could define pluggable byte code dictionaries that the VM
> could swap in as required.

As far as pluggable byte code sets, both SmalltalkAgents(r) on QKS' Mac and
Win32 VM's had them. It is not the ideal model you want to use for a VM
design. It has importance only if you're building an interpreter and
interpreters should have CISC instruction sets to achieve best performance
and overall design characteristics. We demonstrated and explored this key
design area when we worked with Apple and IBM on our UVM system (AOS) in
the early 90's.

A jitter requires a different instruction set design that should be neither
CISC or RISC, but rather lend itself to supporting fast analysis and
optimization [of which, in my opinion, the JVM set is a poor example].

On today's technology (where memory is cheaper and processors and their
caches are the driver) a jitter approach has many more desirable
characteristics. It is just more complicated to build well enough to make it
better than a good interpreter (Dolphin ST is an example here). A jitter
also has the "potential" to be better and more desirable than a static
compiler -- but the competitive challenges and some of the basic tradeoffs
make it even harder to develop a jit that is better than a static system (a
hybrid approach may in fact be the best model).

Microsoft's .NET technology investment is a pragmatic foray/exploration into
this very space -- especially for implementing languages such as C++ (where
they have a good static compiler).

A VM with a pluggable jitter framework/architecture is the approach I've
used in the AOS design. With that architecture I can readily use a
cross-jitter to translate from one byte code set to another and then jit
that into native code. So there is no reason to have "pluggable" byte code
dictionaries.

The goal is not one of having "pluggable" byte code sets, but rather to have
a rich object model and efficient structured access to the metadata such as
type information and well structured information for analyzing data flow in
an instruction/opcode stream. The AOS current architecture of pluggable
jitters is similar to but not exactly the same as byte code dictionaries.
The AOS platform on which our native SmallScript runs has four jitters
within it. Only one of them actually generates native cpu code, the others
are cross-jitters of one form or another.
----------

Regarding UVM thoughts, let me make a few comments. I've been in the UVM
area for many years. I originally designed our VM in 1990-1991 to host a
variety of dynamic languages. In those days the term "platform" had not
become popularized and we called our Agents Object System (AOS) UVM platform
a "backplane" (stemming from my minicomputer and EE/VLSI background :).

We danced with Apple for three plus years and signed a system deal with them
in 1996 to make our VM the UVM for all the MacOS dynamic and scripting
languages other than Java -- A deal that Sun indirectly contributed to
screwing up, one day after signing, by assisting Apple's stock plummet to a
junk bond status which froze all Apple investment and technology funds. But
that is another of the sad Smalltalk history stories...

Today that is water (stained with my BST) under the bridge.

So, back to the present day:

SmallScript and its virtual machine (AOS) will be free.
However, the AOS will not be open sourced.

The VM is part of a separate technology known as the Agents Object
System(tm)[AOS(tm)]. The AOS ...

read more »



Tue, 05 Aug 2003 10:21:57 GMT  
 Universal Virtual Machine
 This post is a response to David's observations or concerns that I may have
made glib statements about .NET or SmallScript that are confusing or
inaccurate. It may be partly off-topic, but I want to ensure my
clarifications are in the original posted groups.

Please direct all followups to comp.lang.smalltalk.advocacy (also please do
not post complaints regarding availability of that newsgroup).


Quote:

> > One thing that has disappointed me about .NET and Java is that these VMs
do
> > not appear to provide good support for Smalltalk.

> > [ re. .NET -- I have been a little confused by some of David Simmons'
posts.
> > Although he has been quite helpful and informative, I am left with the
> > impression that .NET will support SmallScript, but not Smalltalk as most
of
> > us in this group understand Smalltalk.]

> Sorry for creating that confusion. Maybe this post will help?

> Then again, it is really long and almost certainly controversial so it may
> actually do the opposite :-(

> Hopefully those who choose to comment upon it, will comment on selected
> sections in separate posts rather than bundling it all together :) [which
of
> course I didn't do]

Thanks for doing this. I have seen some very long posts from you in the past
and it is probably my own impatience that has led to my confusion.

I would like to split up your post, but not necessarily to respond to every
point. There is some useful stuff here that should be put up in a Smalltalk
and .NET FAQ.

- Show quoted text -

Quote:
> > Whether .NET supports Smalltalk or not is not relevant.

> Well, its relevant to me as the person who has developed Smalltalk for
.NET
> and has worked long and hard with Microsoft to continue to ensure that
.NET
> has the necessary elements to support Smalltalk.

> > It is proprietary
> > and closed (I wonder if Microsoft understands that .NET is supposed to
be
> > the operating system, not something you package with Windows or Windows
CE
> > or whatever they're calling it now).

> Your comments regarding "proprietary" and "closed" are not "strictly
> speaking" correct. The .NET specification is open and becoming a standard
> via the ECMA process. A standard which is likely to be ratified and
adopted
> before the end of this year; in a process which involves many companies
> including (and perhaps most notably) Sun Microsystems.

> http://msdn.microsoft.com/net/ecma/

> http://www.gotdotnet.com

> The idea that Microsoft may not understand that .NET is "supposed to be an
> operating system" is coming from left field.

> I.e., Microsoft created and defined .NET, so de-facto they "defined" what
it
> is "supposed to be".

Fair points. I apologize for the FUD. My perception of .NET is that is a
technology platform to allow MS to extend their reach to hardware devices
beyond the PC as we know it, as you suggest below. But my assumption is that
they want to extend their OS entrenchment to these devices as well.

Therefore, it is not the .NET VM that is a problem for me, but rather my
belief that .NET will require the presence of MS operating system services
in order to be useful. When I first heard of .NET, I thought of products
like VB, Word and Excel (which I have heard are pCode-based), and of course
Perl and Smalltalk, that would be good candidates for a VM implementation.

My perception of MS and the CE market is that MS is "hurting" because of the
porting efforts required to get not only CE running on all these different
devices, but also each application that needs to be redeployed for each
hardware vendor. The solution provided by .NET will allow MS (and more
importantly application developers) to have their products run on all such
devices without a recompile (or worse, a porting effort). But my assumption
is that these devices will still require the presence of a commercial MS
operating system.

Also, my bias stems from discussions I have read on the MSDN web site
regarding C# and C++ and the "controversy" around the fact that C# does not
provide "synchronous or deterministic destructors" (see
http://msdn.microsoft.com/library/Welcome/dsmsdn/deepc10192000.htm) [Warning
to Smalltalkers: do not look at this link if you have just had lunch].

The C++ development community is important to MS, and they are the primary
market for C#. Based on what you have said it is not likely that MS will
break the language independence in .NET in order to satisfy these concerns.
I especially appreciate your lobbying efforts with MS to ensure that MS
supports dynamic languages like Smalltalk (and beyond!).

But in its desire to be all things to all programmers, the logical concern
is that .NET (like Windows) will be extraordinarily complex and consequently
take years to stabilize. Maybe this is a problem with all software. But is
especially difficult to deal with in commercal software (see David's
comments below regarding the balance of free tools and funding for tool
development).

Until recently, I have been quite positive about Microsoft operating systems
and applications. In fact, I still believe the level of quality and
usefulness of their products is unsurpassed. But in the software industry,
upgrade revenues are like the goose that laid the golden egg. Microsoft has
thousands of clever people whose sole job appears to be finding ways of
tricking their customers into upgrading software that works perfectly well
for them, wasting valuable time and eroding the value proposition that these
products allegedly provided in the first place.

Hence my comment that .NET "should be" the operating system. When you buy or
build computer hardware, you need an O/S. To use that hardware you must
license an O/S. If that O/S is commercial software, there is a conflict on
the part of the vendor between selling product upgrades and providing a
stable platform for development and deployment. I remember reading a quote
recently that the only purpose of an O/S is to provide such a platform. To
me, a standard VM should be an important part of such an O/S.

And also, my point regarding the irrelevance of Smalltalk on .NET was not
intended to be insulting to you or your efforts (I apologize for the
crassness of this remark, and also commend you for not flaming me into a
black patch of dirt). My point was really that .NET is not relevant to me
based on the assumption that it is tied to Microsoft's commercial O/S
endeavors.

If .NET will work on Unix and Macintosh platforms without requiring a
commercial software license from Microsoft, I will be impressed. But I have
seen no unequivocal statement from Microsoft that this will be the case. In
spite of their attempts to deflect criticism around their commercial
practices, I believe that MS is founded on a simple principle that he who
controls the O/S, controls everything else. To give that up would be
anathema.

Quote:
> More to the point, I would contend that they intentionally designed it as
a
> technology to enable them to break their technology base free of both the
> INTEL and Windows OS Family ties [and perhaps the Justice Department
focus].
> Which means they defined a "platform", which is not the same thing as an
> "operating system".

To me, a "platform" is more than just software.

[ other comments regarding .NET ]

- Show quoted text -

Quote:
> > Neither does the Java VM support Smalltalk the way we know it today
(Bistro
> > is a nice idea, but I don't think it's Smalltalk).

> > In general, languages like Java, C#, and even Bistro and SmallScript
(IMHO)
> > seem to be taking Smalltalk in the opposite direction it should be
going.

> What does Java or C# have to do with where Smalltalk is or is *not* going?

> Where is SmallScript taking Smalltalk, that it should not be going?

>     Smaller?
>     Faster?
>     More portable?
>     Applicable to more of today's software tasks?
>     More interoperable with other languages and systems?
>     More capable of supporting multiple dialects/libraries
>          simultaneously (incl non-Smalltalk)?
>     More expressive for explicit enforcement of contracts?
>     More scalable and deployable via the namespace, module,
>          and interface technology QKS defined?
>     More approachable and mainstream via familiar constructs
>          from languages such as python, jscript, and c++?
>     Retaining Smalltalk syntax/source compatibility.

> The wrong directions are backwards and status quo.

[ lots of good stuff about UVMs, jitters and the history AOS ]

These are all noble and useful objectives, however, there is one overriding
characteristic about Smalltalk that I value above everything else, and that
is its simplicity of expression.

<imho>
As with my concerns about .NET, extra "language" features (such as DBC,
Namespaces, etc.) inhibit learning and understanding, especially by people
who are learning to program. In fact, these features are often marginally
useful and serve as a mechanism for entrenchment of old ideas and may
unintentionally inhibit the growth of new ideas.

The *right* direction is greater simplicity and flexibility, while opening
up the object/class/method/inheritance mechanisms to be explored in
Smalltalk itself, rather than burying them in the depths of the VM.

Maybe the right direction *is* backwards. Maybe we should be looking more
closely at Smalltalk-72 instead of Smalltalk-80.
</imho>

- Show quoted text -

Quote:
> ------------
> Back to the question of what is "Smalltalk" and the idea of what a
standard
> Smalltalk library base could or should be...

> The various dialect specific class libraries are proprietary in one form
or
> another. (I consider "Open Source" to be as proprietary as any other
source
> license since it has restrictions on its use).

> If your goal is a good framework base to provide a standard set of
> additional services, then that standard base should be based on a true
> bsd-style source license. I.e.,a freely redistributable (without
limitation)
> set of core library

...

read more »



Wed, 06 Aug 2003 02:16:20 GMT  
 Universal Virtual Machine
David Simmons wrote (abridged**n :-)):

Quote:
> Ahhh, shewh. That was a long and almost certainly a controversial post. I'm
> sure I'm not ready for all the questions and responses it may raise...

> -- Dave Simmons [www.qks.com / www.smallscript.com]
>   "Effectively solving a problem begins with how you express it."

I read the whole post because I found it interesting, but I suspect
that not many others will read all of it. Have you considered
collecting your better posts into a book, perhaps published online?
Especially since deja has disappeared. If I tend towards verbosity,
I can point to a greater example. :-)

One issue you raised, and that c.l.s. has discussed pretty heavily,
is to what extent SmallScript is Smalltalk. Since there are many ways
to answer this question, it might be worth making it a little more
rigorous. Your explanation has included terms such as ST (Smalltalk),
SS (SmallScript), VM, UVM, EE (execution engine), MOP (meta object
protocol), CL (computer language), DCL (dynamic computer language),
SSL (static computer language), SY (syntax), CLIB (class library).
Some of these abbreviations are mine. There's also VI (virtual image),
which may relevant. Would it help you explain SS better if you wrote
out relations between these terms? Perhaps it would be more clear than
plain English. I don't know. Anyway, here are a few examples.

inheritance     SS = ST + new-SS-state + new-SS-behavior (SS is kind of ST)
composition     new-SS-state = ...
composition     new-SS-behavior = ...
composition     SS = ST + new-component1 +... (SS includes ST as a subset)
composition     new-component1 = ...
dependence      SS-VM is the minimal VM necessary to run SS
dependence      UVM is a sufficient VM to run SS
dependence      UVM is sufficient to run DCL or SSL
what-relation?  How are SS-VM and UVM related?
composition     VM = EE + MOP
inheritance     SS is a kind of DCL
composition     SS = SS-SY + SS-CLIB + SS-objects + what else?
inheritance     VM-for-Linux is kind of VM
instantiation   can't think of good examples
other-relations ...

I know many of these are muddled, but I just wonder whether it is
possible to formalize SmallScript's definition more tersely. If a
decent response would be verbose, perhaps these ideas would help
your private thinking. What I fear is that computer languages and
IDEs are so complex that they can't be easily described in these
terms.



Wed, 06 Aug 2003 03:46:27 GMT  
 Universal Virtual Machine

Quote:
> This post is a response to David's observations or concerns that I may
have
> made glib statements about .NET or SmallScript that are confusing or
> inaccurate. It may be partly off-topic, but I want to ensure my
> clarifications are in the original posted groups.

> Please direct all followups to comp.lang.smalltalk.advocacy (also please
do
> not post complaints regarding availability of that newsgroup).

[...lots snipped to get these posts smaller :) ...]

Quote:
> > > Neither does the Java VM support Smalltalk the way we know it today
> (Bistro
> > > is a nice idea, but I don't think it's Smalltalk).

> > > In general, languages like Java, C#, and even Bistro and SmallScript
> (IMHO)
> > > seem to be taking Smalltalk in the opposite direction it should be
> going.

> > What does Java or C# have to do with where Smalltalk is or is *not*
going?

> > Where is SmallScript taking Smalltalk, that it should not be going?

> >     Smaller?
> >     Faster?
> >     More portable?
> >     Applicable to more of today's software tasks?
> >     More interoperable with other languages and systems?
> >     More capable of supporting multiple dialects/libraries
> >          simultaneously (incl non-Smalltalk)?
> >     More expressive for explicit enforcement of contracts?
> >     More scalable and deployable via the namespace, module,
> >          and interface technology QKS defined?
> >     More approachable and mainstream via familiar constructs
> >          from languages such as python, jscript, and c++?
> >     Retaining Smalltalk syntax/source compatibility.

> > The wrong directions are backwards and status quo.

> [ lots of good stuff about UVMs, jitters and the history AOS ]

> These are all noble and useful objectives, however, there is one
overriding
> characteristic about Smalltalk that I value above everything else, and
that
> is its simplicity of expression.

I thoroughly agree. Simplicity is elegance -- that has been the motto that
drove QKS Smalltalk's evolution from before day 1.

User experience will determine the reality of the following statements
----------------------------------------------------------------------
I designed SmallScript to extend Smalltalk's capabilities. Which means that
if Smalltalk can express and do all that you need to do, then you don't need
to learn the additional elements or features of SmallScript.

I.e., DBC, namespaces, etc are not essential and they can be ignored.

However, I think that both namespaces and interfaces are important concepts
that should be part of the learning experience. Learning about error
handling early and developing good habits regarding exceptions vs return
codes is equally important.

I have not found namespaces to be a problem for newbies to programming or
Smalltalk. A typical explanation is to give them a parallel to
folders/directories and the rest follows pretty naturally.

We'll see about interfaces. However, people tend to grasp the idea of
"roles" very quickly.

Generally speaking, the  extended capabilities of SmallScript have been
designed based on the 90/10 rule. 90% of the development problems being
solved don't require the extended SmallScript features, etc. But for the 10%
that do, you have the power to be precise and explicitly declare or control
what is supposed to happen.

One of the biggest reasons I like Smalltalk in particular and dynamic
languages in general is that they allow me to think more about the problem
rather than about how what I have to do to express it in my programming
language. That makes the process more fluid, and enables me to be more
productive.

It is one of the driving reasons for adding syntax to Smalltalk for
simplifying expression when interacting with the world outside of Smalltalk.

    Such as:
        parenthetical/functional messages -> foo(...)

        Interfaces -- where classes *are* interfaces
        Types -- where classes *are* types
        Namespaces -- where classes *are* namespaces

If I want to call the ::MessageBox(...) function in the User32.DLL I can
directly call it, or any arbitrary DLL function, via a self contained script
of the form:

------
class name=User32 dll='User32'.
eval [                "<- the 'eval' keyword is optional"
    User32.MessageBox(
        0,
        'TITLE',
        'Message',
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
------

Or I could choose to extend the <String> class with:

------
class name=User32 extends=Module dll='User32'.
method class=String [
alert: msg

    User32.MessageBox(
        0,
        self,
        msg,
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
------

Any class can be a repository of external methods/code within a
DLL/shared-library. So, the "extends=Module" is not necessary. But it is
good to group modules under the same inheritance family if you want to
implicitly inherit its interfaces for other module features.

Or I could have more explicitly written with our own type marshalling
information and calling conventions, etc:

------
module name=User32 dll='User32'.
method class=User32
[
  <$native=stdapi;Integer>
  MessageBox(<void> a,
             <String> title,
             <String> message,
             <Integer> modeFlags)
].
class name=String imports='+User32'.
method class=String
[
  alert: msg

    MessageBox(
        0,
        self,
        msg,
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
------

The following is not a good way to have designed this service. But, for the
purposes of this simple example it does show how I could have written it
using an interface:

------
interface name=IUIInteraction dll='User32'.
method class=IUIInteraction
[
  alert: msg

    MessageBox(
        0,
        self,
        msg,
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
class name=String implements='+IUIInteraction'.
------

With any of those different forms, I could then send any <String> instance
the message #alert:.
------
[
    'Improper input encountered' alert: 'WARNING'.

    "OR via the message aliasing semantics
     while also using the dot message notation"

    'Improper input encountered'.alert('WARNING').
].
------

The result is a 20 line script. Which could be built as a literally
miniscule DLL or EXE.

The 10% case of this would be if we wanted to handle MessageBoxA vs
MessageBoxW explicitly (perhaps it is obvious that the VM system is doing
something for use with regard to Wide vs Ascii method invocation and
marshalling).

===================
On the other hand, there is the 10% case where I'm calling an external
method that wants a pointer to a given type, and may need to dispatch
through some external vtable vector.

What we want is to implement interface methods with COM support for:
------
[
    someObject as: someInterfaceClass.
]
------

As you'll see below, we have complex issues (the 10% case). We need to pass
a reference to our container that will hold the result
<anInterfaceInstance>, and we would like to have the system automatically
marshal arguments and invoke COM style vtable services, as well as update an
<anInterfaceInstance> to hold an instance of that class rather than the
native ppvObject. The story for <IDispatch> dispInterfaces is similar but
that is another topic...

NOTE:
If we used <HResult> instead of <HRESULT> as the return value's type
descriptor in the method that follows, the marshalling machinery would map
the value into an exception/warning as appropriate.

We could, of course, change that behavior by rewriting the marshalling code
in the <HResult> class. Doing so would also mean that the #as: method should
be written differently.

The reverse (external vtable callback) invocation case (for the
QueryInterface method we wrote below) of mapping thrown exceptions into
<HRESULT> values is handled for us by the JITTER.

We also note that the <Interface> type currently treats '*' indirections as
the <Integer> type. So a pointer can be a negative value to minimize
<LargeInteger> object mapping.

So, we would write the additional methods:
(with that extra stuff because this is the 10% case)

------
method class=Interface [<$vtable=0;HRESULT>
QueryInterface(<GUID> interfaceId, <OUT Interface*> anObject)
    anObject := stObject as: interfaceId primaryValue.
   ^S_OK
].

method class=Interface [
as: <Interface.class> anInterfaceClass

   "Check for the self case -- subclasses may refine this method"
    if (anInterfaceClass == self class) return self "this".

   "If we are not a wrapper on an external object, and noting
    that interfaces don't wrapper interfaces"
    ffiHandle ? "#ifNil:" [^stObject as: anInterfaceClass].

   "Otherwise, invoke the external query interface routine"
    |ppvObject|
    |hResult| := QueryInterface(aBehavior md_uuid, <&>ppvObject).

   "If successful, return a wrappered instance"
    if (hResult = S_OK)
        return(aBehavior fromPPVHandle: ppvObject).

   "Otherwise, signal an exception and be sure to return <nil>
    in case the exception is caught and resumed."
    COMException signal: hResult.
   ^nil
].
------

Again, its a 28 line script (with comments) but we did have to know a bit
more syntax to accomplish our goals. I.e., we did have to understand how:
the annotation for the <$vtable> directive works (especially ...

read more »



Wed, 06 Aug 2003 07:16:45 GMT  
 Universal Virtual Machine

Quote:

> The SmallScript language is a separate technology from .NET and the AOS
> version of it is unrelated and completely independent of the .NET
> technologies.

So when/why would we use the AOS implementation instead of the .NET
implementation? (or visa-versa)

Nevin Pratt



Wed, 06 Aug 2003 10:49:53 GMT  
 Universal Virtual Machine
Sorry if this may be a little OT. But it's short and replies to a specific
point.


...

Quote:
> If .NET will work on Unix and Macintosh platforms without requiring a
> commercial software license from Microsoft, I will be impressed. But I have
> seen no unequivocal statement from Microsoft that this will be the case. In
> spite of their attempts to deflect criticism around their commercial
> practices, I believe that MS is founded on a simple principle that he who
> controls the O/S, controls everything else. To give that up would be
> anathema.

AFAIK not only MS is pushing for .NET to be standard (and C# too, but this is
not the concern here), but it was directly concerned that it does get ported to
at least a Unix platform. Surprise surprise: that's Linux.

Again AFAIK MS have an agreement with Corel that Corel, if asked so by MS within
2 years, will port .NET to Linux. And will do it within 1 year. And then keep
the port up to date within no more than 6 months from any MS released update to
.NET for at least 5 yers.

Corel promises to put on .NET duty no less than 1/2 of it's developlment
efforts.

Therefore you will probably not have to pay MS for .NET per se (you may for .NET
on Windows, of course). However, strictly speaking, nowere is written that the
port will be free, even if I doubt that either MS or Corel would bet a dime on
any non free SW for Linux! So logic tells me that the port will actually be
free.

In any case the real point in making .NET standard means that anybody could port
it to whatever OS.

How successfull .NET will be is just another question, but it looks like MS is
really on focus to make .NET as usefull as it can be, as open as it can be and
as universal as it can be. And even as free as it can be.

Eventually they have TONS of technology that is .NET ready (or almost). And
they'll get cash flowing from that door.

Andrea Ferro
-------------------------------
Urka s.r.l.
DVD Authoring and Premastering



Mon, 11 Aug 2003 03:13:34 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Universal Virtual Machine

2. Universal Virtual Machine

3. IBM Universal Virtual Machine progress?

4. Universal Virtual Machine

5. A "Universal Virtual Machine"

6. Virtual 8086 Mode/Virtual Machine Monitor (VMM)

7. Virtual 8086 Mode/Virtual Machine Monitor (VMM)

8. SIMPEL Virtual Machine (a toy machine and assembler)

9. Universal Machine - Fact Or Fiction

10. Universal Machine ?

11. Universal LAN Modem Access On 386 Machines

12. Universal Turing Machine

 

 
Powered by phpBB® Forum Software