Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: D Yuniskis on 18 May 2010 23:48 Hi Joel, Joel Koltner wrote: > "Vladimir Vassilevsky" <nospam(a)nowhere.com> wrote in message > news:2aidnYGi4ZZA3m7WnZ2dnUVZ_oydnZ2d(a)giganews.com... >> BTW, one can write pretty extensive GUI programs for Windows using >> pure win32 API calls; the code size will be only few hundred kilobytes >> or so. > > Yeah, Steve Gibson (http://www.grc.com/intro.htm) is into that -- > writing his software in assembly language and calling the GDI API directly. I think that's indicative of some *other* "problem" :> Sort of like walking 12 miles to work each day :-/ > 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? 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. > 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. 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., average_rainfall = (read(./rain/today) + read(./rain/yesterday)) / 2 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! :> )
From: Robert Baer on 19 May 2010 00:06 Joel Koltner wrote: > "Vladimir Vassilevsky" <nospam(a)nowhere.com> wrote in message > news:2aidnYGi4ZZA3m7WnZ2dnUVZ_oydnZ2d(a)giganews.com... >> BTW, one can write pretty extensive GUI programs for Windows using >> pure win32 API calls; the code size will be only few hundred kilobytes >> or so. > > Yeah, Steve Gibson (http://www.grc.com/intro.htm) 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. > > ---Joel > So..write your own DLLs to support only what you need; tain't that hard..
From: Joel Koltner on 19 May 2010 12:41 Hi Didi, "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message news:hsvmlu$k95$1(a)speranza.aioe.org... > 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. This one here--> http://www.vitanuova.com/inferno/index.html ? I'll check it out; thanks for the idea. > 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*. Sounds pretty slick! ---Joel
From: John Larkin on 19 May 2010 14:31 On Tue, 18 May 2010 20:50:31 -0500, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: > > >D Yuniskis wrote: > >> Hi Tim, >> >> Tim Williams wrote: >> >>> "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote in message >>> news:2cDIn.136868$pj7.90918(a)en-nntp-15.dc1.easynews.com... >>> >>>> It's around 1,500 lines of PowerBASIC code. >>>> >>>> John's program compiles to about 61kB. >>> >>> >>> 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. >> >> >> Play with Inferno sometime. It's *scary* how small the executables >> are! (of course, the cost of the VM isn't included there!) > >The largest program I wrote so far is ~300k of the executable code; >that's from ~2M sources in C++. > >BTW, one can write pretty extensive GUI programs for Windows using pure >win32 API calls; the code size will be only few hundred kilobytes or so. > >VLV 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. John
From: D Yuniskis on 19 May 2010 16:01
Hi Joel, Joel Koltner wrote: > Hi Didi, Um, "Don". Didi is someone else! ;-) (Hi Dimiter! :>) > "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message > news:hsvmlu$k95$1(a)speranza.aioe.org... >> 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. > > This one here--> http://www.vitanuova.com/inferno/index.html ? I'll > check it out; thanks for the idea. Yes. I think the sources are on sourceforge. But, you should be able to find links there. >> 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*. > > Sounds pretty slick! I think if you play with it, you'll be amused at what you can do in such an environment. |