Conference bulova::decw_jan-89_to_nov-90

Try the "condensed font" option under the customize window menu.

Ken

    Changing to condensed font only makes the window smaller. It does not
    reduce the size of the dxterm core size.
    
    It would appear my question was to ambigous. My customer is complaing
    about the amount of memory required by dxterm vs xterm. By my figuring
    more than 2.5MB vs 1MB.
    
    Patrick.

Oh, that "size".  This is really disk size, rather than memory size. 
The binary is large because of UIL, but most of it is never paged in
(check the RSS size through ps).  It's probably not possible to reduce
the disk size until Ultrix supports shared libraries.  If this is
important to you, you should beat on the Ultrix base system folks.

Ken

Re: .4

Are you sure about the swap space?  I could be wrong, but I thought
Ultrix paged off the original binary.  The swap area only contains
dynamic virtual memory allocated at run time.

Ken

The data sizes for much larger the DXterm are much larger than for the Xterm.

thomas     854  0.7  7.3 3624 1396 p4 S N   0:01 dxterm
thomas     262  0.0  1.1 1672  196 ?  S     0:16 xterm

About two years ago I made a request to have a stripped-down version
of dxterm for people doing simple stuff.....only to be lashed at in here.

I regreted opening my big mouth ;-)

Kris....

Another thing to remember is that dxterm, dxwm, dxsession, and dxue are
all linked together in the same binary.  This saves disk space and, if
you use more than one of these, they will share their text segments,
saving RAM.  This may be a hack, but it does get you many of the
benefits of shared libraries.

Other dx* clients are also linked together like this.  Check the inode
numbers in /usr/bin.

Ken

I don't think that a `striped down' version would solve the problem, what is
needed is a dxterm SYSGEN facility.  That way we could each select the specific
options that we want.  Don't need any control sequence processing, no problem,
select VT05 mode only.  Don't want cursor blink, instead of disabling the code,
why not get rid of it entirely.  If you only want terminal windows that are
58 by 80, then get rid of the code for resizing and the code to select the
compressed font.

My experience with a number of different software products is that when a given
version has been significantly enhanced or rewritten, or even just slightly
enhanced, that there is a request for removing the unneeded features that
make it big and slow, but be sure to keep xyz.  For RSX we ended up with
something like 100 options for the exec alone, many of which removed less than
0.1% of the code, but of course if you didn't take the 10 options that amounted
to 50%, then the 20 0.1% options now amounted to 5% additional reduction.

And on the other side of the coin, while the complaints about the size are
numerous, few QARs against decterm/dxterm are going to be resolved by removing
options....

The obvious question is why don't you use xterm if dxterm is so objectionable?
Not only is it smaller, but the code is available and if you want, you can
strip out even more and make is smaller still, or you can selectively add
features that dxterm has and post the changes so that everyone can benefit...
And if you did it right, you'd place all the new features in conditionals
so that it could be tailored.