tiny tabbed rtf editor: kPad

  • Thread starter Thread starter omega
  • Start date Start date
O

omega

kPad, by Konstantin Boukreev
http://www.codeproject.com/wtl/kpad.asp?print=true

This is the tiniest freeware rtf editor I've yet to see.

In shareware, radsoft.net has rixedit and family, which are surely the
smallest of all time. In freeware, Notehalf might be mentioned. It is
160k. Well, not counting its vb dependencies, ie the 1.4mb msvbvm60.dll.
Either way, those are both SDI, one document per instance. kPad is tabbed.

I am convinced kPad is the smallest functional tabbed rtf editor out there.
It is 104k. Then UPX, that brings it down to 54k (!).

It does richtext: those basics, such as font styles and colors. It does
not do OLE, such as pics insertion.

It has persistent settings, including your preferred background color. It
keeps a recents docs list under the File manu.

It has internal drag-drop, where you can move text around with your mouse.

It is hyperlink aware. I tested with "http://" and with "file:".

It will of course open .txt. But its orientation is .rtf. By this, I mean
that it will offer up formatting commands on opened .txt files, and that
the New File command defaults to giving a name with an .rtf extension.
OTOH, it is flexible in the Open dialog, which defaults initially to *.*.

On the New File operation, it is has a good, considerate autonaming
feature. It automatically provides you provisional, unique names.
New1.rtf, New2.rtf, New3.rtf, etc.

While this is a demo, a beta, I haven't been able to spot any problems
or significant shortcomings.

The only small matter I've noticed. When I drag a document onto a link
for it, the display is an SFN (shortf~1.rtf) instead of the LFN. Only
that one circumstance. It of course can read and write LFNs, and things
are fine in the Open/Save interactions.

You can open files from the explorer by dropping them onto its document
window. There is one thing I noticed. It was fine with that up to about
a 300k size, but GPF'ed on me with files larger than that. When I tried
those same test files in the Open/Save, it was fine.

About filesize max. That might be fairly intertwined with the strength of
your hardware. Largest file I tried was 1.5mb, and it did manage to open
that, but got pale and sweaty in the struggle for a bit, until at last
succeeding in heaving it up.

That was a text file. I don't think I have any simple .rtf files that are
that large. My larger ones have embedded pictures, which a non-OLE rtf
editor like this cannot display. Here is a small result, though. It was
fine with a 500k .rtf I handed it. Then on a multimeg .rtf, it failed,
displayed only a fraction of it.

About the richtext files this can read and write. Again no OLE/pics. And
too: the files need to be the low-end of the rtf file format. It does not
handle tables very well (alignment is skewed and so on). But hey, At 104k,
I don't really expect the sophistication found in those editors that are
closer to the scale of word processors.

Conclude. I recommend this for fans of SMALL. I stand by the assertion that
no tabbed rtf editor gets close to how compact this is.

Eh, but about the download. In case you've not previously used codeproject.
You need to make an email identity + password, which they store in a cookie,
and required for getting files from them. You can use an imaginary email
address (there is not a confirm process), and do not have to fill out long
BS forms (zipcode etc). So the signup is pretty brief, other than entailing
some extra clicking until you have created your codeproject cookie.

Here is the URL again:

http://www.codeproject.com/wtl/kpad.asp?print=true
 
omega said:
kPad, by Konstantin Boukreev
http://www.codeproject.com/wtl/kpad.asp?print=true

This is the tiniest freeware rtf editor I've yet to see.
Eh, but about the download. In case you've not previously used codeproject.
You need to make an email identity + password, which they store in a cookie,
and required for getting files from them. You can use an imaginary email
address (there is not a confirm process), and do not have to fill out long
BS forms (zipcode etc). So the signup is pretty brief, other than entailing
some extra clicking until you have created your codeproject cookie.

A search on Google yields the following presumably unofficial mirror:
http://www.neowulf.net/Pub/
 
Ulrich Neumann said:
kPad, by Konstantin Boukreev
http://www.codeproject.com/wtl/kpad.asp?print=true

You need to make an email identity + password, which they store in a cookie,
[...]

A search on Google yields the following presumably unofficial mirror:
http://www.neowulf.net/Pub/

I'd done a quick search on Google too. Mainly to see if the author had a
homepage, and had continued kPad development (no luck). My search hadn't
yielded an external download location - so I appreciate the link. Always
better to be able to access directly, not hassle with signups & cookies.
 
Ulrich Neumann said:
A search on Google yields the following presumably unofficial mirror:
http://www.neowulf.net/Pub/

In the htm index for the apps neowulf lists, yields a good grin re the
office suites warning...

"OpenOffice.org

WARNING: use of OpenOffice may cause you to stop wasting money
on other office suites. It has all the power of M$ Office Pro,
plus MORE (especially if you download an add-on or template)."

http://www.neowulf.net/Freeware.htm
 
omega said:
kPad, by Konstantin Boukreev
http://www.codeproject.com/wtl/kpad.asp?print=true

This is the tiniest freeware rtf editor I've yet to see.

Interestingly, it's tiny in file size but its memory footprint is not
that tiny. Output of "pslist -m":

Name Pid VM WS Priv Priv Pk Faults NonP Page
kPad 1764 36200 6992 2224 2648 3159 6 28

In conclusion, after looking at quite a few text editors I think there
is no real correlation between file size and memory footprint.
I would be very happy if somebody could confirm this as I am not sure
how reliable my testing method is.

Ulrich
 
Ulrich Neumann said:
Interestingly, it's tiny in file size but its memory footprint is not
that tiny.

I haven't measured. I can say that it would not be completely standalone.
It would be using the MS richedit control. The version of that DLL I load
most is 400k - then there is one version of it that is 900k.
Output of "pslist -m":

Name Pid VM WS Priv Priv Pk Faults NonP Page
kPad 1764 36200 6992 2224 2648 3159 6 28

In conclusion, after looking at quite a few text editors I think there
is no real correlation between file size and memory footprint.
I would be very happy if somebody could confirm this as I am not sure
how reliable my testing method is.

The way I test is more direct and simple. I read my free physcial memory
count before I load the app. Then the drop in memory count after the app
is loaded. Specifically, I use Memload to do that artithmetic for me, its
"snapshot" function (don't know if that one's 2000/XP compatible).

To avoid the matter of shared modules (such as richedit) affecting the
memory drop count, then one method I take is to reboot in between testing
apps. At those reboots I have nothing in startup (other than a few DLLs
hooked into the explorer). Also, for very serious, I set my vcache to zero,
so there is not confusion with I/O things caching into RAM and thereby
affecting its totals.

Separately from that, I have a couple of process monitors that tell me a
count for memory that a program is using. They separate out what modules
the program loads that are shareed and what modules are private. Their
readings have very close relation to physical size of executables and
their loaded modules. (Then in addition there is a field called stacks.
Whose meaning I don't understand, but anyway, it is a small number.)

I'd think that those numbers I get from those utilities ought be similar
to the "priv" field you get from pslist. However, in my tests, it was Scite
that was definitely victor as far as memory over the NoteTabs.

Finally, I have one or two procmonts that give great big numbers, 20-80+
megabytes. I might compare the numbers I got there with those large VM
numbers that PSlist is giving you. Also, yesterday I tried a commandline
tool that gave something like total mapped memory per process, and those
numbers might be for the some sort of thing.

I don't expect to understand the pslist output too deeply. I did download
the msft reskit 2000 chapter that talks a little on the subject. But,
every time I've read that subject, it gets quicly very technical, my eyes
tending to glaze over after the first few paragraphs, so I'm not expecting
today to suddenly have bright enlightenment.

Anyway, I'll post to the other thread later at least my main results. The
testing of Scite v NoteTab. The results from the intuitive method for me:
How much did my RAM drop when I loaded the app?

I'll see when I get there how far to get into posting my process monitor
output. Or what I can or cannot work out when comparing with your (NT only
tool) pslist output.

.. . .

The reason the post might take me a while to get to, that was that I wrote
down numbers with pen and paper. In afterthought, I could have hunted down
for note-taking an editor that doesn't load any extra modules (eg richedit
dlls), but did not. Now my challenge is to decipher what I wrote with my
totally illegible hand-writing.
 
Ulrich Neumann said:
Output of "pslist -m":

Incidentally, right now I've come across a tool from the msft reskit
that sounds to generate fields similar to those provide by Sysinternal's
pslist -m parameter.

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/vadump-o.asp

| Vadump.exe: Virtual Address Dump
|
| VaDump creates a listing that contains information about the memory
| usage of a specified process. That list includes the following:
|
| * Each address, along with its size, state, protection, and type.
| * Total committed memory for the image, the .exe file, and each .dll
| file, including system .dll files.
| * Total mapped-committed, private-committed, and reserved memory.
| * Information about the working set and about paged and nonpaged pool
| usage.

Page also states this: "You can use VaDump to make sure virtual address
space is not over-allocated." Not something that sounds to me to be of
typical concern. That second item in the list, total committed memory,
that's the area where I'd be most inclined to look. Except if it is not
separating shared versus private. Total mapped-committed, well, those
numbers that I got from a CLI tool were just huge and irrelevant to me.
The private-commited, okay, but that's something that I'd still need to
try and read explanation about.

I don't have 2000/XP, though, so this is another tool that whose output
I cannot attempt to test and assess myself. And again, I still value
most my simplistic approach to the matter. RAM before minus RAM after.
It is more within the range of what is understandable to me. :)
 
omega said:
Incidentally, right now I've come across a tool from the msft reskit
that sounds to generate fields similar to those provide by Sysinternal's
pslist -m parameter.
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/vadump-o.asp

Here are the results for Mini NoteTab, NoteTab Light, Scite and kPad.
Well, actually it's just an excerpt since the total output varies
between 12 and 24 kB per text editor.

*Mini NoteTab*

Total Mapped Commitment 2465792
READONLY: 995328
READWRITE: 131072
EXECUTEREAD: 1339392

Total Priv Commitment 962560
READONLY: 4096
READWRITE: 946176
EXECUTEREADWRITE: 12288

Dynamic Reserved Memory 12804096

PageFaults: 1133
PeakWorkingSetSize 3768320
WorkingSetSize 3764224
PeakPagedPoolUsage 22312
PagedPoolUsage 21736
PeakNonPagedPoolUsage 3704
NonPagedPoolUsage 3064
PagefileUsage 1359872
PeakPagefileUsage 1359872

*NoteTab Light*

Total Mapped Commitment 2732032
READONLY: 1257472
READWRITE: 135168
EXECUTEREAD: 1339392

Total Priv Commitment 860160
READONLY: 4096
READWRITE: 839680
EXECUTEREADWRITE: 16384

Dynamic Reserved Memory 20258816

PageFaults: 1828
PeakWorkingSetSize 5414912
WorkingSetSize 5398528
PeakPagedPoolUsage 25612
PagedPoolUsage 24396
PeakNonPagedPoolUsage 4496
NonPagedPoolUsage 3792
PagefileUsage 1384448
PeakPagefileUsage 1384448

*Scite*

Total Mapped Commitment 2498560
READONLY: 1011712
READWRITE: 147456
EXECUTEREAD: 1339392

Total Priv Commitment 1572864
READONLY: 4096
READWRITE: 1540096
EXECUTEREADWRITE: 28672

Dynamic Reserved Memory 26320896

PageFaults: 2418
PeakWorkingSetSize 8224768
WorkingSetSize 8224768
PeakPagedPoolUsage 39080
PagedPoolUsage 34000
PeakNonPagedPoolUsage 9716
NonPagedPoolUsage 6720
PagefileUsage 3174400
PeakPagefileUsage 3256320

*kPad*

Total Mapped Commitment 2482176
READONLY: 1011712
READWRITE: 131072
EXECUTEREAD: 1339392

Total Priv Commitment 741376
READONLY: 4096
READWRITE: 704512
EXECUTEREADWRITE: 32768

Dynamic Reserved Memory 17805312

PageFaults: 2408
PeakWorkingSetSize 6541312
WorkingSetSize 6352896
PeakPagedPoolUsage 32176
PagedPoolUsage 28832
PeakNonPagedPoolUsage 7192
NonPagedPoolUsage 5992
PagefileUsage 2150400
PeakPagefileUsage 2666496

The Working Set values are more or less similar to those of pslist.
Regarding the other values I am unable to see any similarities to
pslist.

However, if you compare these (vadump) values

*Mini NoteTab*
Total Mapped Commitment 2465792
Total Priv Commitment 962560
Dynamic Reserved Memory 12804096

*kPad*
Total Mapped Commitment 2482176
Total Priv Commitment 741376
Dynamic Reserved Memory 17805312

*NoteTab Light*
Total Mapped Commitment 2732032
Total Priv Commitment 860160
Dynamic Reserved Memory 20258816

*Scite*
Total Mapped Commitment 2498560
Total Priv Commitment 1572864
Dynamic Reserved Memory 26320896

to these (pslist) values

Name Pid VM WS Priv Priv Pk Faults NonP Page
MININOTE 1804 25080 3588 1332 1332 1114 2 21
NoteTab 860 34252 5164 1336 1348 1799 3 23
kPad 1764 36200 6992 2224 2648 3159 6 28
SciTE 540 46060 9460 4216 4256 3495 7 36

it becomes quite clear that Mini NoteTab comes first, NoteTab Light and
kPad share the second place, whereas Scite comes third (or is it fourth
technically spoken?) regarding low memory consumption.

Ulrich
 
omega said:
The way I test is more direct and simple. I read my free physcial memory
count before I load the app. Then the drop in memory count after the app
is loaded. Specifically, I use Memload to do that artithmetic for me, its
"snapshot" function (don't know if that one's 2000/XP compatible).

Do you mean this one here? http://www.snapfiles.com/get/memload.html
If so, only the right pane of the Memload window seems to work in
2000/XP. There are no details about processes. I am not so sure about
the snapshot function since that number (and thus the other values as
well) is changing constantly even though I am not touching the computer.

But...
To avoid the matter of shared modules (such as richedit) affecting the
memory drop count, then one method I take is to reboot in between testing
apps. At those reboots I have nothing in startup (other than a few DLLs
hooked into the explorer). Also, for very serious, I set my vcache to zero,
so there is not confusion with I/O things caching into RAM and thereby
affecting its totals.

.... I am not doing all this, so that might be an explanation.
If you can be absolutely sure that no other application or dll is
influencing the snapshot value during your testing, then everything
should be fine. So please excuse my underlying scepticism. But maybe
this is just nitpicking.
The reason the post might take me a while to get to, that was that I wrote
down numbers with pen and paper. In afterthought, I could have hunted down
for note-taking an editor that doesn't load any extra modules (eg richedit
dlls), but did not. Now my challenge is to decipher what I wrote with my
totally illegible hand-writing.

*grin*
That's why I try to avoid writing with pen and paper as much as
possible. ;-)

Ulrich
 
Ulrich Neumann said:
Here are the results for Mini NoteTab, NoteTab Light, Scite and kPad.
[...]

I have been lately researching avidly on the topic, eg the value / lack
of value in the working set number...and all the other numbers. There is
in particular this intense complication with the OS's paging activities.
It is all very complex! Right now, instead of getting nearer to a reply,
I am being pulled backward by riptide into big seas. The more I read
on the subject, the further I drift from being able to make out a clear
picture at the shoreline.

Thus, I'll probably hold off until tomorrow or so to make any comments
on this subject of measuring memory load. Maybe then I'll have a few shots
of tequila first, so that I would not be nervous if I have to resort to
just making some stuff up. 8-o
 
Back
Top