Do you still use "RS232" or something else?

On 1/16/2011 7:37 PM, nospam wrote:
> D Yuniskis<not.going.to.be@seen.com>  wrote:
>
>> E.g., instead of typing in a date, the user can pick a month from
>> a "year at a glance" calendar.  That causes that month to be displayed
>> (e.g., february.html) and he can now pick a *day*.  All you have to do
>> is watch to see which links get activated (which "files" get requested).
>
> USB storage is a block device so you don't see file requests you would have
> to do reverse directory searching to find the file owning a block, and you

That is trivial.  *You* are creating the files.  *You* are supplying
the VTOC to the browser/OS.  The filenames need not be meaningful
to the user -- they just have to be unique and easily mapped
to recognizable accesses.  E.g., files could be named "1", "2", "3",...
and each be one block long *and* (coincidentally?) arranged on
the medium such that file N is at block N thereby making the
mapping process easily invertible.

Remember, you aren't trying to be a generic, repurposable storage
device.  Rather, just trying to act like an "address decoder".
Similar to hanging a '138 on some address lines and using the
decoded *strobe* outputs to "do things" regardless of the "data"
on the bus at the time...

> would have take measures to stop the browser caching, and the OS will cache

You're fetching a web page.  Does the browser ignore "Expires" because
it considers "file://" URL's to be "different" than other URL's?
I didn't notice anything allowing that behavior in the spec...

Note that there are browser *bugs* that you have to work around
but, IME, those fixes are trivial -- especially if you have no
concern over the size/content of the "actual files" (since they
aren't *really* files but, rather, just "file accesses").

> the files anyway (can't think of a way to stop that), and the OS cache may

IIRC, "Expires" was explicitly designed to tell *everything* between
the "source" and "browser" NOT to cache the data.  I.e., the onus is
on the browser to tell the OS to "go back to the source" for each
new reference to the URL.

> well read ahead into other files, and anti-virus scanners will probably
> read everything in a directory as soon as you touch it.

I have no idea how anti-virus software works (my products are immune
to virii and I don't use it "personally").  Are you claiming that
*any* reference by *any* piece of software to *any* storage medium
leaves the door open for a virus scanner to poke around *everything*
on that medium?

This should be easy to test.  Put a few tens of thousands of 10KB files
on a USB stick in a folder.  Access *one* file in that folder.
See how long the device stays "busy".

Better yet, do something similar with a floppy (smaller files) and see
if the drive stays busy for "a second" or "minutes".  Hmmm... I wonder
if I have any tools that will log these accesses?  I think there may
be one of the SysInternals suite that can watch a medium and log all
accesses to it.  If so, I should be able to put N bogus pages on a
thumb drive and watch to see what the browser *actually* does!

>> Or, a piece of Java that gets a value and does a *specific*
>> "write" to the device (puts the value in a certain place in
>> a certain form).
>
>> The advantage of Java is that it lets you "effectively"
>> install a driver *without* Administrator privilege (because
>> that "driver" runs in Java's sandbox and doesn't tinker
>> with the rest of the host like a "real" driver would)
>
> Being in a sandbox it won't have permission (without administrator
> privileges to give it) to write to any storage device.

On Jan 17, 12:40=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:
> > the files anyway (can't think of a way to stop that), and the OS cache =
may
>
> IIRC, "Expires" was explicitly designed to tell *everything* between
> the "source" and "browser" NOT to cache the data. =A0I.e., the onus is
> on the browser to tell the OS to "go back to the source" for each
> new reference to the URL.

The problem is the OS sees any USB file storage as single ownership
and
therefore it can cache with impunity.  And re-read requests will be
satisfied
from the read cache if possible, no differently than it would do from
a local
hard drive.  After all the OS will see all writes to the device so it
will know
if it has been changed.

> > well read ahead into other files, and anti-virus scanners will probably
> > read everything in a directory as soon as you touch it.
>
> I have no idea how anti-virus software works (my products are immune
> to virii and I don't use it "personally"). =A0Are you claiming that
> *any* reference by *any* piece of software to *any* storage medium
> leaves the door open for a virus scanner to poke around *everything*
> on that medium?

Worse than that, simply inserting the device into a USB port *may*
initiate a full scan.  It depends on the product and possibly scan
settings.  It is after all a foreign untrusted media.  And, yes, I've
seen it
done.  In some cases the it observed since the OS will refuse to
allow
the device to be shut down because the virus scanner is accessing it.

Robert

Hi Robert,

On 1/17/2011 10:41 AM, Robert Adsett wrote:
> On Jan 17, 12:40 pm, D Yuniskis<not.going.to...@seen.com>  wrote:
>>> the files anyway (can't think of a way to stop that), and the OS cache may
>>
>> IIRC, "Expires" was explicitly designed to tell *everything* between
>> the "source" and "browser" NOT to cache the data.  I.e., the onus is
>> on the browser to tell the OS to "go back to the source" for each
>> new reference to the URL.
>
> The problem is the OS sees any USB file storage as single ownership
> and therefore it can cache with impunity.

Hmmm... it *thinks* it can cache with impunity.  E.g., how does it
deal with "smart devices" that *look* like mass storage devices?
E.g., cameras, MP3 players...

Or, do those devices just inherently "have problems"?

Is the behavior inherent in the *driver* interface or at the
filesystem level?  Are *any* hooks exported to control it?
Which OS's make this assumption?  (I've seen nothing that
explicitly *allows* it to be made -- hmmm, wrong choice of word)

> And re-read requests will be satisfied
> from the read cache if possible, no differently than it would do from
> a local
> hard drive.  After all the OS will see all writes to the device so it
> will know if it has been changed.

It sees all writes *only* if it's assumption about being the
sole owner is correct.  What about SMART data on drives?  What
hook tells the OS that it *can't* cache that information (since
the drive *will* be updating it WHILE the OS is accessing the
drive)?

>>> well read ahead into other files, and anti-virus scanners will probably
>>> read everything in a directory as soon as you touch it.
>>
>> I have no idea how anti-virus software works (my products are immune
>> to virii and I don't use it "personally").  Are you claiming that
>> *any* reference by *any* piece of software to *any* storage medium
>> leaves the door open for a virus scanner to poke around *everything*
>> on that medium?
>
> Worse than that, simply inserting the device into a USB port *may*
> initiate a full scan.  It depends on the product and possibly scan
> settings.  It is after all a foreign untrusted media.  And, yes, I've
> seen it
> done.  In some cases the it observed since the OS will refuse to
> allow
> the device to be shut down because the virus scanner is accessing it.

So, timestamps of *every* file on the media will change?
I.e., how do you control wear on non-volatile media?  You
are saying that every "in use" block will be read.  Each
time the volume is mounted.  What does that portend for
solid state drives?

This seems like an interesting thing to "play" with!  Maybe
I'll drag some tools onto my laptop and fiddle with it on
the plane...

Hi Oliver,

On 1/17/2011 1:31 AM, Oliver Betz wrote:
> D Yuniskis wrote:
>
>>>> If you can live with the (short) distance limitations of USB, what if
>>>> you made your device look like a mass storage device.  I.e., damn
>>>> near every USB host out there will recognize a USB "disk drive".
>>>>
>>>> User can mount the drive (which is often automatic) and then access
>>>> X:\index.html to interact with it.  That *static* page (i.e., a "file"
>>>> on your device) can have links to:   X:\status.html, X:\log.html,
>>>> X:\diagnostics.html, etc.  You don't even need a "web server" in
>>>> your device -- instead, you watch to see which "files" are accessed
>>>> and in which order.
>>>
>>> The OS will assume exclusive access, therefore cache data. I think it
>>> will be difficult to establish a dynamic data exchange.
>>
>> This is not true.  E.g., look at HP's (laughable) "Secure Web Console"
>> which implements a "secure" terminal emulator to a serial port (from
>> the network).
>
> I don't know this product, but I know that data from a USB mass
> storage device _gets_ cached.

That's what others have said.  I haven't empirically verified
it -- in particular, how it is handled in browsers (which are
supposed to be able to work-around caching).

> I'm afraid that your approach doesn't
> work. And if it worked, it would be _very_ complicated on the
> microcontroller side.

*Any* interface that is commonplace on contemporary machines
will be "complicated" (if you rule out installing software on
the host).

Modern machines are rapidly moving to higher speed, higher
abstraction, interfaces.  USB, Firewire, Ethernet, Bluetooth...
All have significant "stack sizes" on the client side.

If you want something that can be accessed from the host
*without* installing software, then you have to rely on some
*existing* software -- e.g., to date, you have been relying
on HyperTerminal (the only thing on a PC that gives the user
the ability to "talk" to a serial port).

You could telnet to a remote device -- but then your device
needs to support TCP.  Since the serial port is becoming
extinct, you can't "SLIP" (et al.) leaving Ethernet.  But,
the hardware and software costs of Ethernet are beyond your
product's price point/capabilities.

Parallel ports are gone so you can't PLIP (or "whatever").

PC's don't usually have FW ports -- OTOH, Mac's do.  Regardless,
FW puts you in the same boat as USB (which is more ubiquitous
from the client's side/implementation)

Wireless technologies require a device that has wireless
capabilities (how about a WiFi phone as the user interface?).
And, requires a significant footprint in your device.

Floppies are gone (I designed one device that used floppies
as a transport medium for configuration -- but it also
required a special application to write the floppies lest
the user make syntactical errors).

The IDE interface is internal and obsolescent.

Using SATA puts you in the same boat as the "USB mass storage"
device.  The same can be said for any other "sneakernet" style
interface (SD, MS, etc. cards).

PCMCIA interfaces tend only to be available on laptops.
And, not *universally* so.  Regardless, if you deal with a
"memory style" interface, you're back in the above boat.
Anything else requires software on the host.

PS/2 interfaces are obsolescent and, regardless, would undoubtedly
require some application on the host to interact with such an
"atypical" device.

Most USB devices require "administrator privilege".  I think
even new (non-network) printers can't be installed without it.
Mass storage and HID seem to be the only exceptions.

Mass storage has more options available to "talk to it".
HID requires something to interpret the information sent.

If your constraints remain inflexible (no software to install,
small footprint in the device, etc.), then the only idea I
can offer would be a device with two USB ports -- host mode
on one of them.  Insert device as a keyboard wedge (PS/2 would
be far cheaper but requires obsolescent keyboards) and instruct
the user to open, for example, "Notepad".

Then, push characters into notepad -- in effect, using it as a
"text display".  Respond to keystrokes from the keyboard that
is now plugged into your device and update the "display"
accordingly.

This is far too much of a kludge, for me!  :-/  Too many things
can go wrong if, for example, the focus shifts...

Find a robust USB-serial dongle and give your users instructions
on how to install the drivers.  Purchase a lifetime supply of
these dongles and sell them to your users at "cost".  (this is not
an unreasonable approach; I have known many companies that relied
on third party products to buy up lots of "new stock")

If your market can bear the "support cost", *buy* them a customized
laptop that boots directly to *your* application (and nothing else!).

>>> And transferring arbitrary numbers from a web browser to a "mass
>>> storage" device will be also somewhat weird.
>>
>> It's just a "write" or, even a "GET".
>
> Maybe with JavaScript (which could be blocked because the USB storage
> is considered unsafe), not with plain HTML.
>
>> With the presentation capabilities of a browser, you can approach
>> data entry differently.
>>
>> E.g., instead of typing in a date, the user can pick a month from
>> a "year at a glance" calendar.  That causes that month to be displayed
>> (e.g., february.html) and he can now pick a *day*.  All you have to do
>> is watch to see which links get activated (which "files" get requested).
>>
>> Or, use a "slider" to set a numeric value instead of typing in
>> a value.
>
> Harder for arbitrary numbers>  8 bit or strings.
>
>> Or, a piece of Java that gets a value and does a *specific*
>> "write" to the device (puts the value in a certain place in
>> a certain form).
>
> Do you remember when Microsoft considered chm files from network
> shares harmful? I don't expect Java or JavaScript being available.
>
> Oliver

Hi Dimiter,

On 1/17/2011 1:33 AM, Didi wrote:
> On Jan 17, 12:34 am, Tilmann Reh<usenet2007nos...@autometer.de>
> wrote:
>>
>>>> I'm not sure that the recurring cost of 232 is significantly lower
>>>> than a small MCU implementing a USB stack.  I have yet to add USB to a
>>
>>> For the MCU side, USB can be cheaper then EIA-232.
>>
>> It depends - when talking about larger controllers (like ARMs, for
>> example), USB generally does not really add cost.
>
> I would resist as far as I can to include USB (even though I think of
> ARM as of a controller :-) )simply because it implies a third party
> approval.
>   Technically for debugging it will not buy you much if anything -
> RS232 speeds and a terminal are plenty.

I think the OP's point is that getting (reliable and available) serial
ports on computers is becoming increasingly difficult.  E.g., it
is similar to "finding a 5in floppy".

While you can purchase USB-serial dongles, installing one on a
machine requires having administrator privileges (PC-speak).  So,
it is a "less desirable" approach than it has been hysterically.

>   I really see no reason why one would use USB unless doing work for
> MS.
> Where speed matters, we have ethernet - with all the mature and
> flexible internet protocols on top.

Yes, but the OP doesn't want to bear the cost of the NIC and stack.
E.g., I use lighterweight protocols to connect "dumb peripherals"
(e.g., motes) to a more "capable" host and then have that *host*
export a more versatile interface to the user -- acting as an
intermediary (i.e., the motes can be regarded as part of the
host instead of as separate entities)

> If speed does not matter, RS232 is just fine.

... unless it isn't available!  :>

For "human" interaction, I have found EIA232 to always be fast
enough.  Especially with a good presentation layer mediating.
Even at something as slow as 19200 baud, you can repaint an entire
screen in a second (or less).

OTOH, if you are transfering *data* (configuration files,
log files, firmware updates, etc.) it can be painfully slow!
I grumble anytime I have to push/pull data to/from my Unisite
over the serial port -- which can be necessary with bigger
ROMs, etc.

Hi Oliver,

On 1/17/2011 12:37 PM, D Yuniskis wrote:
> You could telnet to a remote device -- but then your device
> needs to support TCP. Since the serial port is becoming
> extinct, you can't "SLIP" (et al.) leaving Ethernet. But,
> the hardware and software costs of Ethernet are beyond your
> product's price point/capabilities.

Actually, this approach might not be a bad one!

Your "problem" is obsolescent serial ports and flakey USB-serial
dongles (and the "permissions" required to install them).
I.e., this implies that your customers are willing to buy
"an interface" to the existing serial port on your device(s).

USB-oriented interfaces have costs associated that you don't
want/like (recurring costs if you move that functionality
into the device; nonrecurring costs if you force the user
to "install something").

[I'm still pushing the browser approach]

Why not give the user an ethernet interface that is NOT part
of your device?  I.e., instead of buying a USB-serial dongle,
have them buy a "one port terminal server".

Yes, this is (considerably) more expensive than a USB serial
dongle "commodity" product.  But, they only need one of these
for each system that wants to "troubleshoot" your device(s).
Since "whatever" will have to be cabled to your device,
they can simply cable *this* to your device (and "this"
to their network/PC).

You can then telnet to the device and have it act as an EIA232
bridge.

You could eventually design a low-cost version that deals
with your needs exclusively (to make this more affordable
to the user).  You could even opt to design *your* device
to present a web interface to the user -- and translate
the user's interactions with it's "served pages" into
explicit EIA232 "commands".

This is similar to my placing a "capable host" above my
motes -- except, in your case, that "capable host" looks
even more like an "exclusive agent" ("host" when viewed from
your device; "smart device" when viewed from the user's
*host*).

<shrug>  Again, without an understanding of your market, I
can't analyze the cost-benefit tradeoffs.

But, you could pick up *a* "one port terminal server" and
get a feel for how easy it would be to use...

On Jan 17, 2:08=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Robert,
>
> On 1/17/2011 10:41 AM, Robert Adsett wrote:
>
> > On Jan 17, 12:40 pm, D Yuniskis<not.going.to...@seen.com> =A0wrote:
> >>> the files anyway (can't think of a way to stop that), and the OS cach=
e may
>
> >> IIRC, "Expires" was explicitly designed to tell *everything* between
> >> the "source" and "browser" NOT to cache the data. =A0I.e., the onus is
> >> on the browser to tell the OS to "go back to the source" for each
> >> new reference to the URL.
>
> > The problem is the OS sees any USB file storage as single ownership
> > and therefore it can cache with impunity.
>
> Hmmm... it *thinks* it can cache with impunity. =A0E.g., how does it
> deal with "smart devices" that *look* like mass storage devices?
> E.g., cameras, MP3 players...
>
> Or, do those devices just inherently "have problems"?

They don't generally write to the storage while plugged into a PC so
it's not a problem.

I know of people who have tried doing as you suggest and the result
was data corruption.

>
> Is the behavior inherent in the *driver* interface or at the
> filesystem level? =A0Are *any* hooks exported to control it?
> Which OS's make this assumption? =A0(I've seen nothing that
> explicitly *allows* it to be made -- hmmm, wrong choice of word)

Windows at least.  USB is a master slave arrangement.  I think it's
inherit in the definition of the drive profile that the host is the
single owner of the storage (it can reformat after all).  But I've
never looked it up.

> > And re-read requests will be satisfied
> > from the read cache if possible, no differently than it would do from
> > a local
> > hard drive. =A0After all the OS will see all writes to the device so it
> > will know if it has been changed.
>
> It sees all writes *only* if it's assumption about being the
> sole owner is correct. =A0

That's the point.

>What about SMART data on drives? =A0What
> hook tells the OS that it *can't* cache that information (since
> the drive *will* be updating it WHILE the OS is accessing the
> drive)?

What are you referring to? I don't know of any drive that updates file
data while running in a PC.

> > Worse than that, simply inserting the device into a USB port *may*
> > initiate a full scan. =A0It depends on the product and possibly scan
> > settings. =A0It is after all a foreign untrusted media. =A0And, yes, I'=
ve
> > seen it
> > done. =A0In some cases the it observed since the OS will refuse to
> > allow
> > the device to be shut down because the virus scanner is accessing it.
>
> So, timestamps of *every* file on the media will change?

Don't know, haven't verified.  Just seen that it happens.  Not with
all combinations of tools but it does happen.

Robert

On 17.01.2011 20:08, D Yuniskis wrote:
> On 1/17/2011 10:41 AM, Robert Adsett wrote:

>> The problem is the OS sees any USB file storage as single ownership
>> and therefore it can cache with impunity.
>
> Hmmm... it *thinks* it can cache with impunity. E.g., how does it
> deal with "smart devices" that *look* like mass storage devices?
> E.g., cameras, MP3 players...

The same.  Which is why the saner ones of those types of devices switch 
modes when connected to a PC.  They stop being cameras or whatever, and 
become pure mass storage devices.

> Which OS's make this assumption?

They're all entitled to making it.  You don't get to both have the cake 
and eat it.  If your device claims to be a mass storage device, it _has_ 
to behave like one.

> It sees all writes *only* if it's assumption about being the
> sole owner is correct. What about SMART data on drives?

USB mass storage doesn't have that.  SMART is a side channel of hard 
drive interfaces.

On 17/01/11 20:08, D Yuniskis wrote:
> Hi Robert,
>
> On 1/17/2011 10:41 AM, Robert Adsett wrote:
>> On Jan 17, 12:40 pm, D Yuniskis<not.going.to...@seen.com> wrote:
>>>> the files anyway (can't think of a way to stop that), and the OS
>>>> cache may
>>>
>>> IIRC, "Expires" was explicitly designed to tell *everything* between
>>> the "source" and "browser" NOT to cache the data. I.e., the onus is
>>> on the browser to tell the OS to "go back to the source" for each
>>> new reference to the URL.
>>
>> The problem is the OS sees any USB file storage as single ownership
>> and therefore it can cache with impunity.
>
> Hmmm... it *thinks* it can cache with impunity. E.g., how does it
> deal with "smart devices" that *look* like mass storage devices?
> E.g., cameras, MP3 players...
>
> Or, do those devices just inherently "have problems"?
>

I think you are misunderstanding the issues here.  A "mass storage 
device" USB class is a mass storage device - like a hard disk.  When a 
computer is accessing it, it does so in exactly the same way as if it 
were accessing a hard disk.  That means the computer assumes full 
control over all writes to the disk while it is mounted.  (There are 
some filesystems that allow for multiple systems to write concurrently 
to the same disk, but you can be sure that you won't find them on Windows!).

So no, cameras, MP3 players, etc., have no problems - they play by the 
rules and don't try to write to the disk while it is mounted on a host 
system.  They normally won't even try to read from the disk while it is 
mounted, although that can be done safely to some extent, if you are 
/very/ careful (some systems use that as a method for updating firmware, 
for example).

> Is the behavior inherent in the *driver* interface or at the
> filesystem level? Are *any* hooks exported to control it?
> Which OS's make this assumption? (I've seen nothing that
> explicitly *allows* it to be made -- hmmm, wrong choice of word)
>

This behaviour is inherent in the definition of a storage device.  All 
OS's will assume they have complete control over the file system when it 
is mounted, with the possible exception of ancient DOS systems that 
didn't do much caching.  Non-windows systems typically make 
significantly better use of caching than Windows does, so you will see 
the effect more there.

>> And re-read requests will be satisfied
>> from the read cache if possible, no differently than it would do from
>> a local
>> hard drive. After all the OS will see all writes to the device so it
>> will know if it has been changed.
>
> It sees all writes *only* if it's assumption about being the
> sole owner is correct. What about SMART data on drives? What
> hook tells the OS that it *can't* cache that information (since
> the drive *will* be updating it WHILE the OS is accessing the
> drive)?
>

SMART data is not part of the file system, and is not read as blocks 
from the disk.  It is read using specific ioctls (i.e., disk commands 
that don't correspond to block reads).

The host /is/ the sole owner of the disk itself, and thus it makes a 
safe assumption that it knows about all writes.

>>>> well read ahead into other files, and anti-virus scanners will probably
>>>> read everything in a directory as soon as you touch it.
>>>
>>> I have no idea how anti-virus software works (my products are immune
>>> to virii and I don't use it "personally"). Are you claiming that
>>> *any* reference by *any* piece of software to *any* storage medium
>>> leaves the door open for a virus scanner to poke around *everything*
>>> on that medium?
>>
>> Worse than that, simply inserting the device into a USB port *may*
>> initiate a full scan. It depends on the product and possibly scan
>> settings. It is after all a foreign untrusted media. And, yes, I've
>> seen it
>> done. In some cases the it observed since the OS will refuse to
>> allow
>> the device to be shut down because the virus scanner is accessing it.
>
> So, timestamps of *every* file on the media will change?
> I.e., how do you control wear on non-volatile media? You
> are saying that every "in use" block will be read. Each
> time the volume is mounted. What does that portend for
> solid state drives?
>
> This seems like an interesting thing to "play" with! Maybe
> I'll drag some tools onto my laptop and fiddle with it on
> the plane...

If you run anti-virus software, you have very little control over it. 
It can do anything other privileged software can do.  So if the AV 
authors think it is a good idea to read every file on a USB stick when 
it is inserted, then that's what it will do.

On 17/01/11 17:10, hamilton wrote:
> On 1/17/2011 8:57 AM, David Brown wrote:
>> On 17/01/2011 16:21, hamilton wrote:
>>> On 1/17/2011 3:33 AM, David Brown wrote:
>>>> On 17/01/2011 09:33, Oliver Betz wrote:
>>>>> David Brown wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Ah, Hyperterminal bashing. I also did so years ago. But it's not
>>>>>>> justified. There is a flaw in newly created sessions, and there
>>>>>>> is an
>>>>>>> easy workaround (save .ht and re-open). Besides this, it is not so
>>>>>>> bad.
>>>>>>>
>>>>>>> Which terminal program do you suggest to be sent to customers?
>>>>>>>
>>>>>>> Any pealr I didn't list on
>>>>>>> http://wiki.oliverbetz.de/owiki.php/TerminalPrograms ?
>>>>>>
>>>>>> You already have my favourite, Tera Term Pro, on your list. But you
>>>>>
>>>>> Might be your favourite, but not what I consider a lightweigt solution
>>>>> for the occasional user. Does it still install special fonts?
>>>>>
>>>>
>>>> I don't know about the special fonts (never noticed if it needs them or
>>>> not), but I agree that it is not the most lightweight solution - I
>>>> dislike the extra couple of programs it installs by default. However,
>>>> once it is in place, it is simple and fast to use, and has plenty of
>>>> features for when you need them.
>>>
>>> I just checked my TeratermPro install directory.
>>>
>>> Total size is about 5MB.
>>>
>>
>> Current versions are about 10 MB.
>
> I saw my install directory was at 13MB, unitl I looked and saw the
> install file was in there at 5.3MB.
>

I just did a quick check of the size of the files in the directory - I 
didn't look at exactly what they were.  But it's not important if it is 
5 MB or 10 MB - it is still much larger than a simple terminal emulator 
(unsurprisingly, since it is /not/ just a simple terminal emulator).

>>
>>> What do you consider lightweight ?
>>
>> It's not so much the size of the program that makes it "lightweight".
>> It's the number of extra bits and pieces, and the number of changes it
>> makes around your system. I don't know off-hand how much TTP writes to
>> the registry, but by default it installs a couple of extra programs such
>> as "collector". It's that sort of thing that means TTP is no longer
>> "lightweight", as it used to be. I am not saying it is bloated, and I
>> find it very useful - but it is just not as lightweight as it could be.
>
> I will check again, but I thought TTP did not use registry entries !?!
>

Maybe, maybe not - I haven't looked.  I was just trying to say that 
having lots of registry entries is something that makes a program "not 
lightweight", even if it happens to be small in size.  Other "not 
lightweight" characteristics (that TTP mostly doesn't have) include 
requirements for particular software (exact service pack numbers, dotnot 
libraries, etc.), changes to environment variables, extra startup 
program entries, extra programs, requirements to reboot the machine 
under installation or removal, etc.

TTP has extra unnecessary programs (such as "collector") that are 
installed by default, and start up automatically.  It is therefore not a 
lightweight program, by my definition.  It also has lots of features 
beyond being a simple terminal emulator, it is therefore not a 
lightweight terminal emulator (even if you don't install the optional 
software).

I am not saying that TTP is bloated, or that it is /bad/ that it is not 
lightweight.  I find some of TTP's extra features (such as the ssh 
client and the macros) very useful.

>
>>
>>>
>>> Were talking Windoze here, nothing in WXP in that small.
>>>
>>> What I would like to see is a term program that displays hex values.
>>>
>>
>> RealTerm is one such program that I have used, though there are probably
>> many more. Generally if I need to view serial communication in hex, I
>> need to do more than just view it - perhaps interpret the data,
>> calculate CRCs, etc. So I often use Python and pyserial and write some
>> suitable capture scripts if I need something more than I can get from
>> TTP.
>
> I have not used Python, maybe its time I join the 21st century ;-)
>
> Thanks
>
> hamilton