[comp.windows.ms] Smalltalk V /Windows

katz@cs.ucf.edu (Katz) (02/16/91)

I just got my copy of Smalltalk V for windows 3.0.  If you considered using smalltalk to write windows applications, then don't, unless you have 3MB RAM, 25MHZ
386, and customers who don't mind upgrading their hardware to match that, _JUST TO RUN YOUR PROGRAMS_.

Smalltalk for windows comes on two high density disks.  It uncompresses to 3MB on your hard drive, and _surprise_ takes 3MB of RAM.  You can run it in two, but
it's REEEEEAAAAAAAAAAALLLLLLLLLLLYYYYY SLLLLLLLOOOOOOOOOOOOOOOOOWWWWWWWWWW.

It took 30 seconds to load up on my 16MHZ 386SX with 2Mb RAM.

Also, as far as creating EXE files, guess what?  They're about 3Mb too.  It seems that creating an EXE file just takes your smalltalk image file and most of the
smalltalk environment and globs it into one huge file.  It does seem to trim off
some of the unused classes, though, so smaller programs will typically be 1Meg.

Also, unless you have enough RAM to load the entire class image into memory,
the editor and menus will be extremely unresponsive.  With 2Mb, just moving the
mouse outside the editor window and back in causes 5 seconds or so of disk
access.

Fortunately, Digitalk has a 60 day money back guarantee, which I will excercise
on Tuesday.

--
Dave Katz
katz@eola.cs.ucf.edu

andrew@b11.ingr.com (Poor Mr. Potter) (02/22/91)

katz@cs.ucf.edu (Katz) writes:

>I just got my copy of Smalltalk V for windows 3.0.  If you considered
>using smalltalk to write windows applications, then don't, unless you
>have 3MB RAM, 25MHZ....

>Dave Katz
>katz@eola.cs.ucf.edu

Is the slowness really attributable to lack of CPU speed, or do you
suppose it might be caused by trying to load a 3mb application into a
2mb memory?  I have plenty of memory but only 16MHz CPU.  

Andrew



--
Andrew Potter                           |  "t-crosser
Intergraph Corp	        205-730-8673    |  	i-dotter"
uunet!ingr!b23b!entropy!andrew          |  		Dr. Seuss

pwt@otter.hpl.hp.com (Peter Toft) (02/22/91)

I've also just received ST/V for Windows.  Though I've not yet done any
development using it, running the demos hasn't indicated much of a performance
problem when compared to my other Windows Apps.

Admittedly, I'm using a 486 with 10Mb of memory. But it's the relative
performance that counts.

As for memory usage, using the HELP, ABOUT dialogue in the program manager
indicated 6444K free before loading ST, 5023K after.

Just my 1/2p worth, and nothing to do with my employer, etc...

Peter Toft.

ergo@netcom.COM (Isaac Rabinovitch) (03/07/91)

In <10960018@otter.hpl.hp.com> pwt@otter.hpl.hp.com (Peter Toft) writes:


>I've also just received ST/V for Windows.  Though I've not yet done any
>development using it, running the demos hasn't indicated much of a performance
>problem when compared to my other Windows Apps.

>Admittedly, I'm using a 486 with 10Mb of memory. But it's the relative
>performance that counts.

I released the "turbo" button on my machine (bringing it down to
10Mhz, which is slower than a lot of 286's these days), and it was
still quite responsive.  Have heard that it degrades over time,
though.  If true, compressing the image should fix it, and it wouldn't
affect distributed versions of your programs.

I think of a lot of Smalltalk's reputation for slugishness, especially
on PCs, comes from the problems of adapting it to run on top of
simple-minded operating systems.  Digitalk didn't help when they
neglect to implement any decent scrolling or searching mechanism.
This time, they've simply used standard Windows facilities, and it
makes a difference.  (This sort of standardized support for
applications makes me think of Windows 3.0 as the first "real"
operating system for PCs!)

I *do* get in trouble if I start and stop ST several times though.
Keep running out of memory, as if it were not releasing all its
memory on exit.  Typical kind of first-release problem -- I hope.

One thing that *really* bothers me is that any program you create with
ST/Windows starts up with a window advertising that the program was
written with Smalltalk V -- and every window label gets "Smalltalk/V"
prepended to it.  The first is slightly obnoxious, the second is just
plain stupid.  
-- 

	ergo@netcom.com 			Isaac Rabinovitch
	netcom!ergo@apple.com			Silicon Valley, CA
	{apple,amdahl,claris}!netcom!ergo

   (specific statement withheld at this time for operational reasons)

jwh@bodwin.citi.umich.edu (Jim Howe) (03/07/91)

In article <27207@netcom.COM> ergo@netcom.COM (Isaac Rabinovitch) writes:
>
>One thing that *really* bothers me is that any program you create with
>ST/Windows starts up with a window advertising that the program was
>written with Smalltalk V -- and every window label gets "Smalltalk/V"
>prepended to it.  The first is slightly obnoxious, the second is just
>plain stupid.  
>

I agree with you on both of these points.  I work with Smalltlk V/PM
and it does the same thing.  You can fix the window label problem
quite easily, however.  There is a global variable called WindowLabelPrefix
that is set to the string "Smalltalk/V".  In a workspace simply
assign a different value to that variable.  You could also modify
the "label:" method found in ApplicationWindow.  This all works in
V/PM and I assume that it will work in V/Windows.


James W. Howe			   internet: jwh@citi.umich.edu
University of Michigan             uucp:     uunet!mailrus!citi.umich.edu!jwh
Ann Arbor, MI   48103-4943         

objtch@extro.ucc.su.oz.au (Peter Goodall) (03/08/91)

ergo@netcom.COM (Isaac Rabinovitch) writes:

>In <10960018@otter.hpl.hp.com> pwt@otter.hpl.hp.com (Peter Toft) writes:


>>I've also just received ST/V for Windows.  Though I've not yet done any
>>development using it, running the demos hasn't indicated much of a performance
>>problem when compared to my other Windows Apps.

>>Admittedly, I'm using a 486 with 10Mb of memory. But it's the relative
>>performance that counts.

>I released the "turbo" button on my machine (bringing it down to
>10Mhz, which is slower than a lot of 286's these days), and it was
>still quite responsive.  Have heard that it degrades over time,
>though.  If true, compressing the image should fix it, and it wouldn't
>affect distributed versions of your programs.

>I think of a lot of Smalltalk's reputation for slugishness, especially
>on PCs, comes from the problems of adapting it to run on top of
>simple-minded operating systems.  Digitalk didn't help when they
>neglect to implement any decent scrolling or searching mechanism.
>This time, they've simply used standard Windows facilities, and it
>makes a difference.  (This sort of standardized support for
>applications makes me think of Windows 3.0 as the first "real"
>operating system for PCs!)

>I *do* get in trouble if I start and stop ST several times though.
>Keep running out of memory, as if it were not releasing all its
>memory on exit.  Typical kind of first-release problem -- I hope.

I believe it is a problem with the memory manager in Win3 - We do have
several complex systems from different sources at work together here.

>One thing that *really* bothers me is that any program you create with
>ST/Windows starts up with a window advertising that the program was
>written with Smalltalk V -- and every window label gets "Smalltalk/V"
>prepended to it.  The first is slightly obnoxious, the second is just
>plain stupid.  
>-- 

This is the label: method on class Application window
As you will see the prefix to the label is in a global variable
called WindowLabelPrefix - very easy to fix!

ST>label: aString
ST>        "Set the window label of the receiver to aString."
ST>    label := aString isEmpty
ST>        ifTrue: [aString]
ST>        ifFalse: [WindowLabelPrefix, ' ', aString].
                     ^^^^^^^^^^^^^^^^^^
ST>    handle isNil ifTrue: [^self].
ST>    handle = NullHandle ifFalse: [self setWindowText: label].


    Here is what that global contains:
         'Smalltalk/V'

    Don't   ever think anything is hard-wired into a Smalltalk
    system until you have looked.

    Conditional branches for example are not part of the language.
    They are written in Smalltalk. Look at the classes True and False!


I'm not sure about th opening credits yet, I've been too busy to look.




>	ergo@netcom.com 			Isaac Rabinovitch
>	netcom!ergo@apple.com			Silicon Valley, CA
>	{apple,amdahl,claris}!netcom!ergo

>   (specific statement withheld at this time for operational reasons)


----------------------------
Peter Goodall

Smalltalk Systems Consultant
ObjecTech P/L
162 Burns Bay Rd,
LANE COVE , NSW, AUSTRALIA
objtch@extro.ucc.su.oz.au

press@venice.SEDD.TRW.COM (Barry Press) (03/08/91)

In article <objtch.668381712@extro> objtch@extro.ucc.su.oz.au (Peter Goodall) writes:
>I'm not sure about th opening credits yet, I've been too busy to look.

It's in a DLL; you can simply supply your own if you provide the equivalent
API.  The API has two function calls, one to put up the dialog box and one
to pull it down.  I don't recall if the documentation is in a .txt file or
in the manual, but it's there.

-- 
Barry Press                                 Internet: press@venice.sedd.trw.com

degood@hpavla.avo.hp.com (John DeGood) (03/09/91)

ergo@netcom.COM (Isaac Rabinovitch) writes:

> I *do* get in trouble if I start and stop ST several times though.
> Keep running out of memory, as if it were not releasing all its
> memory on exit.  Typical kind of first-release problem -- I hope.

From README.TXT on my Smalltalk/V Windows disks:

> 4.  KNOWN PROBLEMS
> 
> We are aware of a rare problem where Windows brings up a
> message box reporting 'Insufficient Memory' when trying to
> run another application after exiting Smalltalk.  When this
> problem occurs, continue to run the application.  The
> application will eventually be loaded on the second or third
> attempt.
> 
> Copyright 1991   Digitalk, Inc.

I don't think this is necessarily a Digitalk problem:  I've seen it
after running other large Windows applications, and after trying several
tries the "Insufficient Memory" message goes away.

John DeGood
degood@hpavla.avo.hp.com    -or-   ...!hplabs!hpavla!degood
Hewlett-Packard Avondale (Pennsylvania) Division -- present
Hewlett-Packard Little Falls (Delaware) Division -- mid '92
(215) 268-5523