Rampup tweaking

[Richard Steinfeld]

I'm trying RamPup -- a utility that displays and releases memory. It's
handy and free-standing (no install neccessary). But every time it
loads, it's in a window that's too small for it's display, requiring
horiontal and vertical dragging. The author says there's no support.

Anyone have any ideas about how to get it to come up big enough?

There are a pair of buttons which are either a godsend or hell,
depending. These buttons do a slam-dunk exit from everything -- turn off
your computer. One just kills it: blam! A nasty exit, like you'd do from
a blue screen. The other one does a "graceful exit." There's no "are you
sure?" step. Just "blam." So, if you click one of these by accident, you
may be real sad. You might like to hide these two buttons, but I don't
know how to do this. Sorry.

Richard

 

[B. R. 'BeAr' Ederson]

I'm trying RamPup -- a utility that displays and releases memory. It's
handy and free-standing (no install neccessary). But every time it
loads, it's in a window that's too small for it's display, requiring
horiontal and vertical dragging. The author says there's no support.

You can't be serious about that??! Using a lousy written utility for
system tweaking tasks?? Btw., it's a shareware program. So the
no-support claim of the author doesn't look too nice...

Anyone have any ideas about how to get it to come up big enough?

Use Resource Hacker by Angus Johnson:

www.angusj.com/resourcehacker

Open RamPup.exe and scroll down to RCData->TFRMMAIN->0. Adjust the first
'Width' and 'Hight' values in the right pane to whatever size you like.
Then scroll down to the buttons you want to kill from the form. These
are also found under RCData->TFRMMAIN->0 because they are children of
the main form. Delete all the button object entries you'd like to
remove. Lets say you want to remove the <Reboot> button you need to
delete the following code:

| object tbtReboot: TToolButton
| Left = 129
| Top = 2
| Hint = 'Reboot|Close and Restart Windows'
| ImageIndex = 4
| ParentShowHint = False
| ShowHint = True
| OnClick = tbtRebootClick
| end

After that hit the <Complile Script> button. Don't forget to save your
changes (File->Save).

BeAr

 

[Richard Steinfeld]

You can't be serious about that??! Using a lousy written utility for
system tweaking tasks?? Btw., it's a shareware program. So the
no-support claim of the author doesn't look too nice...

Oh, I just got this straight.
Turns out that I downloaded this program two years ago and just got
around to trying it. At that time, whaddaya know: it was freeware! And I
checked the home page; now it's sure enough, some sort of inexpensive
payware.

But is it "lousy?" The range of memory recovery seems limited, but
probably quite enough to get people out of binds. I haven't needed to
use it seriously yet, but so far, the only poor writing I can see is in
the user interface -- no confirm step for the "dump everything" buttons.
I sure wouldn't set it up this way, especially since the coder didn't
let on how the user can confugure it, and despite the program indeed
using a settings file (that has one entry in it).

Use Resource Hacker by Angus Johnson:

www.angusj.com/resourcehacker

Open RamPup.exe and scroll down to RCData->TFRMMAIN->0. Adjust the first
'Width' and 'Hight' values in the right pane to whatever size you like.
Then scroll down to the buttons you want to kill from the form. These
are also found under RCData->TFRMMAIN->0 because they are children of
the main form. Delete all the button object entries you'd like to
remove. Lets say you want to remove the <Reboot> button you need to
delete the following code:

| object tbtReboot: TToolButton
| Left = 129
| Top = 2
| Hint = 'Reboot|Close and Restart Windows'
| ImageIndex = 4
| ParentShowHint = False
| ShowHint = True
| OnClick = tbtRebootClick
| end

After that hit the <Complile Script> button. Don't forget to save your
changes (File->Save).

BeAr

Thanks. This looks quite interesting!

Richard

 

[Richard Steinfeld]

You can't be serious about that??! Using a lousy written utility for
system tweaking tasks?? Btw., it's a shareware program. So the
no-support claim of the author doesn't look too nice...

So, if it's lousy, can anyone recommend a more considerate memory
recovery utility?

Richard

 

[B. R. 'BeAr' Ederson]

On Thu, 18 Aug 2005 01:34:39 -0700, Richard Steinfeld wrote:

[RamPup]

But is it "lousy?" The range of memory recovery seems limited, but
probably quite enough to get people out of binds. I haven't needed to
use it seriously yet, but so far, the only poor writing I can see is in
the user interface

As long as you don't get the source code to check against (or do an
in-depth disassembly analysis) you can only judge the quality of a
program by its behavior while running. If a developer shows serious
lack in developing an - at least reasonable - user interface, than I
can't believe (s)he will do a better job on such *very* difficult
topics as the memory management.

The program is written in Delphi. The creation of an user interface
is straight forward inside that development environment.

BeAr

 

[B. R. 'BeAr' Ederson]

On Thu, 18 Aug 2005 01:37:01 -0700, Richard Steinfeld wrote:

[RamPup]

So, if it's lousy, can anyone recommend a more considerate memory
recovery utility?

Generally spoken: you don't need one. Windows does a fairly good job
on memory management issues itself. Sure there are still possibilities
for improvement. But these mostly depend on a special usage of the
system (like file server or computing server). In that case you'll
find registry tweaks which *might* help a bit. In all other cases
those tweaks do no harm at best, slow your over-all performance or
even make your system instable.

The same goes with most so called 'memory managers'. Some (like
the 'famous' SoftRAM in times of Win95) do nothing at all. Others
just change some of the mentioned registry settings, fill the RAM
with nonsense to get more free physical RAM (which is plainly a
wrong approach because of the ways Windows handles memory itself),
and so on.

There are few things to *really* improve memory management. Even
the placement of the Swap file on a very fast separate disk (which
generally *is* a good way to speed up Windows can screw up, if
the disks are set up using wrong hardware transfer methods inside
the computer BIOS).

Of course, there still is the possibility to write a complete new
and better memory manager. That's the thing MS always tries to do
when releasing a new operating system. But I didn't hear of a good
free third-party memory manager for Windows, myself. Up to now...
;-)

BeAr

 

[Richard Steinfeld]

On Thu, 18 Aug 2005 01:34:39 -0700, Richard Steinfeld wrote:

[RamPup]

But is it "lousy?" The range of memory recovery seems limited, but
probably quite enough to get people out of binds. I haven't needed to
use it seriously yet, but so far, the only poor writing I can see is in
the user interface

As long as you don't get the source code to check against (or do an
in-depth disassembly analysis) you can only judge the quality of a
program by its behavior while running. If a developer shows serious
lack in developing an - at least reasonable - user interface, than I
can't believe (s)he will do a better job on such *very* difficult
topics as the memory management.

The program is written in Delphi. The creation of an user interface
is straight forward inside that development environment.

I assume that you've tried the program and perhaps have more experience
with it than I do.

I feel that your statement about a developer and the interface is
reasonable and rational. However, in my experience on software
development projects, I've found that there's a tendency for the
programmers to treat the interface almost as an afterthought. It's
almost as if the user, too, is an afterthought. Coders attentions often
seem to be fastened upon the code itself, whether all the routines work
and interact properly, and that the program not abend. I don't think
that software engineers are trained to pay much attention to the needs
of the end user and the user's experience with their product.

As a result, we are afflicted with major commercial programs that are
almost user-hostile. For example, most programmers I've observed type
with one or two fingers. And they write word processing programs for
people who also type with one or two fingers. In this category, I find
that software now actually handles worse than it did in the days of DOS.

So, my thinking is that as long as the interface isn't hostile, the
underlying functionality is probably better than the implementation of
the screen and the keyboard. It's unfortunate. However, I think that
you've got a point -- I don't know why RamPup comes up with a screen
larger than its window, which forces this user to have to go in with the
mouse and pull each of the borders outward, and must do so every time
the window is called up (what a pain). Or those two "gotcha" buttons. I
would not design the interface like that, and I hope you wouldn't either.

Richard

 

[B. R. 'BeAr' Ederson]

On Thu, 18 Aug 2005 08:45:21 -0700, Richard Steinfeld wrote:

[RamPup]

I assume that you've tried the program and perhaps have more experience
with it than I do.

Why should I??! Despite the fact that it is shareware and it covers
an area of system tools, from which I don't expect *any* doing more
good than harm, it states that its main purpose is keeping an amount
of RAM free. I already wrote, that this is plainly wrong behavior.

The Windows memory management is optimized to put all available RAM
to sensible usage. (Up to the upper border of RAM it can manage...)
If you free some of your physical RAM periodically using a tool like
RamPup, you could have bought a computer with less RAM in the first
place.

in my experience on software development projects, I've found that
there's a tendency for the programmers to treat the interface almost as
an afterthought.

Of course that's common, esp. among system programmers. But even
if such people often make ugly, hard to control interfaces, they
do it in a *skilled* way. The results will not look like tawdry
child's play, but rather spartanic and dull.

It's unfortunate. However, I think that you've got a point -- I don't
know why RamPup comes up with a screen larger than its window, which
forces this user to have to go in with the mouse and pull each of the
borders outward, and must do so every time the window is called up (what
a pain).

Oh, that's simply because the program was written on a system using
a small screen font. (Normally only used on very low screen resolution
like 640x480). In that environment no resize is necessary. But that's
also a good indicator for non-professional programs. One of the first
things when you do windows programming is looking for a large screen.
You need place for all parts of the IDE, references, program outputs
and so on. (Best are multi monitor solutions.)

Programs 'optimized' for 640x480 are usually a good indicator of the
first programming steps of children, because they used to start with
a cheap 14" or 15". Of course, as times are changing and computer
equipment gets cheaper, the value of *this* indicator abates...

Or those two "gotcha" buttons.

Typical child's play.

I would not design the interface like that, and I hope you wouldn't either.

No. I *don't*. ;-)

BeAr