So I wrote this little screen capture utility for Tek 1180x scopes, mostly as a learning exercise as I want to mess around with GNURadio some... plus aiming a digital camera at a scope to obtain, e.g., test documentation was getting a little old.
All my program does is to pretend to be a "printer" and displays the scope's screen when you hit its "hardcopy" button. It's around 1,000 lines of Python code.
John Larkin wrote a program -- over a decade ago -- that is somewhat similar in that it reads waveform data out of the same scope and plots it... although he lets you acquire multiple waveforms and performs jitter calculations on the actual data. It's around 1,500 lines of PowerBASIC code.
John's program compiles to about 61kB.
My program, once it's packaged up to include the Microsoft run-time libraries and Python stuff and the GUI crap ends up being just shy of... SEVEN MEGABYTES.
Sheesh!
Although -my program has the advantage that it will run under Windows 7. :-) (Linux too, for that matter... and presumably Macs, although I don't have one of those to test with...)
I've got some microcontroller source here, about 3.8kLOC in C, makes 13,688 bytes object code. Seems like an awful lot, I wonder if I've accidentially included any libraries I don't want.
Tim
--
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms
is into that -- writing his software in assembly language and calling the GDI API directly.
Personally I like using somewhat "higher level" GUI toolkits -- I've used wxWidgets a couple of times now, and one of its claims to fame is that it's no harder to make arbitrarily resizeable windows/dialogs/etc. than it is to use the old school fixed-size approach that, e.g., Visual BASIC and most of Windows until quite recently is known for. (I can't tell you how many times I've been presented with a dialog box that's too narrow to show, e.g., the full path & name of a file and desperatiely wished I could re-size it, but noooooo...)
I'm also somewhat attracted to its cross-platform nature, given that there is some stuff on Linux that I like to mess around with. Why learn multiple GUI toolkits when you can just learn one and use it on Macs, Windows, and Linux?
Of course the downside of all this is what started this thread -- incredibly large distributables even for very modest programs. Although these days even if you wrote the program in assembly and got it down to, say, 10kB, it'd still be invoking many megabytes of DLLs that come with Windows, like it or not.
I think that's indicative of some *other* "problem" :>
Sort of like walking 12 miles to work each day :-/
You *really* should play with Inferno. I think you will be amused at what you can do, how quickly you can do it *and* how "portable" it is. E.g., I run it on a PC, a Sun box and NetBSD -- next, I will build a "native" (i.e., bare iron) version.
REALLY look at inferno! You can download it (free) and run it under windows. Unlike all the other bloated applications out there, this thing fits in *one* place in the file hierarchy and I think only makes one entry in the registry (the path to the "inferno root", IIRC). There are some (toy) demos that you can play with in the release. You can then look at the sources for those (the sources for EVERYTHING are there for you to use) and see how insanely trivial everything is. And, how *small*.
Limbo -- the programming language typically used in Inferno -- is a bit odd. It will look like C in lots of ways. But, NOT like C in many others. (Thank Ritchie for that, too!)
It's biggest win (IMO) is how easily you can create distributed applications. *Without* having to go through all the pain of writing "servers", marshalling arguments, etc.
I have an application here that has N distributed nodes. Each node has some combination of barcode readers, displays, touchpanels, keyboards, printers and scales (as in "you weigh
8.5 stone"). From the user's perspective (which is all that matters, come the end of the day), you can do anything from anywhere. I.e., I can print on printer A a weight obtained from scale B while I am invoking that command from machine C. And, you can begin a transaction at one place and finish it at some *other* place (think about how you would do that writing the app in C or C++!). E.g., I can start typing something on display A, get called away from this to do soomething at the other end of the building and finish what I was typing on display *Z*.
(you would have to see the application to appreciate all the magic involved :< )
My home automation system (mentioned in one of these threads) also relies on this ability. So, the "irrigation controller" can "mount" some portion of the "weather station" in its namespace and directly access the data "served" by the weather station AS IF it was available local to the irrigation system. E.g.,
where /rain/today et al. are values observed and computed by the "weather station".
Likewise,
write(./zone/1, "ON")
scribbles *in* the "water server" that I need the valve for zone 1 turned on. The water server can watch /zone/* and, if any are "ON", it can activate the master valve -- until all are "OFF".
(sorry, I am not doing this justice. You really have to understand the mindset involved in solving problems this way --not the sort of thing you pick up from a few rants in a newsgroup! :> )
To be fair you should compare like with like. If John's program had a full Windows compliant GUI bound into it then it too would be larger. But even so I doubt if it would tip the scales at over 1MB. PowerBASIC is pretty smart about only linking in essential components.
You pay a price in size when you link in MS libraries. And ISTR Python requires a bytecode interpretter to run it. That is lurking in amongst your executable byte count. Does PY2EXE make a better fist of it?
It is the fate of all GUI programs to be vastly oversized. Smart linkers can help sometimes.
The point here though is that on machines with upwards of 4GB and terabyte disks a size of 7MB isn't really an issue any more. And if the physically larger program can be developed more reliably and quickly than the compact one then there may be reasons to prefer it. This is particularly true if multiplatform compatibility is required.
On a sunny day (Wed, 19 May 2010 08:34:50 +0100) it happened Martin Brown wrote in :
I use xforms exclusivly on Linux for GUI: some more compex GUI with graphics:
formatting link
It is about 2 MB.
formatting link
It also has a C source generator for if you are in a hurry. Linux of course. MS windows is not platform with any future., better to stay clear of it.
DNS attack in progress, now for a while:
Rejected IPs: 213.239.206.103 count= 0 repeat_count= 3 time=Sun May 9 12:59:14 2010 last seen=Sun May 9 12:59:13 2010 72.32.196.103 count= 0 repeat_count= 3 time=Tue May 11 22:01:05 2010 last seen=Tue May 11 22:01:04 2010 74.208.170.81 count= 0 repeat_count= 198 time=Tue May 11 22:32:06 2010 last seen=Thu May 13 09:51:34 2010 65.55.226.140 count= 0 repeat_count= 3 time=Thu May 13 02:16:36 2010 last seen=Thu May 13 02:16:35 2010 91.202.63.130 count= 0 repeat_count= 17 time=Thu May 13 12:16:16 2010 last seen=Thu May 13 14:40:58 2010 91.202.63.129 count= 58 repeat_count= 283 time=Thu May 13 15:11:59 2010 last seen=Wed May 19 12:40:29 2010 91.212.135.135 count= 0 repeat_count= 144 time=Sat May 15 00:37:59 2010 last seen=Wed May 19 10:57:07 2010 91.212.135.106 count= 0 repeat_count= 124 time=Sun May 16 01:26:56 2010 last seen=Sun May 16 23:30:11 2010 91.212.135.110 count= 0 repeat_count= 5 time=Wed May 19 11:07:28 2010 last seen=Wed May 19 11:28:08 2010
9 IP addresses rejected MS WINDOWS SUCKS
My postings must be upsetting somebody, now that would not be a MS payed hacker? MS WINDOWS SUCKS MS WINDOWS SUCKS MS WINDOWS SUCKS MS WINDOWS SUCKS MS WINDOWS SUCKS
a bus is bloat if you only need to transport two people, a bus is the smart choice if you you only want to maintain one vehicle, sometimes need to transport two sometimes 20 and have plenty of room in the garage
7MB is with PyInstaller -- which is actually pretty slick; I'm liking it more than Py2EXE. If I tell it to use PYS to compress everything, it gets down to
6MB, but the start-up time is noticeably longer then, as it decompresses everything on-the-fly, so it's not really worth it IMO.
Got anything bigger than a postage stamp there, Jan? That image is way too tiny to see any detail.
I'm afraid I wouldn't take that bet -- like it or not, Windows isn't going away any time soon, and there really are some good applications available for Windows that aren't available on Linux or even Macs. (E.g., Microwave Office, Street Atlas USA...)
I sort of like the appearance of a real photo of a scope screen. Less sterile than a screen cap and perfect plotting. There are people around here who disagree.
There's nothing really wrong with 7 megabytes for a PC app. Disks are pushing a terabyte and memory sticks are a gig, so it really doesn't matter any more. But I think my program is seriously faster than yours, mostly because I'm importing integer sample values from the scope and you're extracting a printer image. Not to mention that PowerBasic is brutally fast.
I fetched my waveform samples in ASCII, so it takes a second or two to get a waveform from the scope. I should have done binary mode, which would have been about 3x faster.
Some day maybe I'll rewrite it for the 32-bit compiler, and do binary transfers and nicer graphics.
Some of my PBCC utilities (Windows console apps) with basic screen menus but not official Windows gui stuff, compile to numbers like 32K. I have a test program for a digital delay generator, full of menus and RS232/ethernet access to the DUT, that's 44K.
Our pretty extensive material control system is a 400 kbyte EXE, 18K line source file. The size isn't so important as are the speed and reliability.
I was surprised just how slow the scope is -- turns out that changing from
9600bps to 19200bps makes a negligible difference in the screen capture time; it might be 59 seconds rather than 62, but the major bottleneck is definitely in the scope's own internal processing.
These days people might expect draggable cursors for the zonewidths (but it probably wouldn't be worth the effort to give it to them :-) ), but other than that I think you'd be looking at a pretty straightforward conversion, at least if you use a fixed-size graph.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.