Excel-RS232 via Cheapcomm: Where?

The Real Andy wrote:

> On Thu, 27 Sep 2007 00:48:17 GMT, Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
> 
> 
>>Robert Adsett wrote:
>>
>>
>>>In article <LovKi.9066$JD.147@newssvr21.news.prodigy.net>, Joerg says...
>>>
>>>
>>>>I am not a fan of .NET. It seems to have serious backwards compatibility 
>>>>issues. Case in point: New scope SW came, must have .NET. Installed 2.0, 
>>>>did not work. Inquired -> Must use 1.1 because 2.0 is not compatible. 
>>>>Great. <shaking head>
>>>
>>>
>>>That appears to be Microsofts latest approach to solving version 
>>>dependancy issues.  Just run a separate copy of every version.  So if 
>>>you have a program using version 1 and another program using version 2 
>>>you get both copies in memory.
>>>
>>>It appears they've given up on the idea of actually getting it right.  I 
>>>don't know if it's a reasoable approach but it sure rubs the wrong way.
>>>
>>
>>ROFL! That was a good one. But it sure looks like it. Now if it was only 
>>.NET that would be one thing. The world would keep spinning without it. 
>> However, it seems there is now an "oh s..t" experience even with Vista.
>>
>>Anyhow, I have become very careful WRT adopting all this newfangled 
>>stuff from up there. Ordered a new desktop today. With XP. Surprisingly 
>>the sales guy at the small biz desk told me right off the bat before I 
>>had even brought it up "And you want XP on there, right?"
>>
>>It's not that I am dissing MS for everything. They did produce some nice 
>>and useful SW packages. Office being one of them, but also MS-Works.
>>
>>
>>
>>>Just in case you were wondering why disk and memory requirements keep 
>>>climbing w/o bound.
>>>
>>
>>Bloat without bounds. Funtionality doesn't grow in proportion though. 
>>This whole problem with RS232 into spreadsheet was a non-issue in the 
>>DOS days. I used MS-Works. It had a built-in terminal program that could 
>>pipe in the data, a spreadsheet, a word processor and a database. So 
>>when I wanted to recreate and decode a datastream out of my logic 
>>analyzer (to diagnose ADC distortion effects) I grabbed a serial cable, 
>>plugged it in, and bingo. No .NET, no Active-X, no DLL hassles. It 
>>simply worked.
> 
> 
> Yes, but back in the DOS days there was no braodband, and there was no
> fancy monitors and digital cameras. there was no CD's (maybe just) and
> no MP3's. There was no portable music players and skype. There was
> text based word processors and dot matrix printers. Monochrome screens
> (4 colours if you were lucky) and speakers that beep instead of
> playing music.
> 

Hey, I had a Freecom CD box, 16 colors, and a well functioning HP 
DeskJet. Later a HPII LaserJet. Web sites were not fluffified but 
practical. Case in point: Sabre. Since I flew an enormous amount of 
miles some airlines allowed me to call my flights in directly. Sabre was 
strictly ASCII based, meaning blazingly fast over the 7-8K my modem 
could realistically yield. Then Sabre was bought up and it was all over, 
it suffocated in new fluff :-(


> Now tell me functionality has not increased. 
> 

For engineers who design electronic circuits it hasn't increased too 
much. Ok, there is a whole lot more content on the web now versus back 
then. But when I look at my design process I see this:

    DOS:

The OS is nearly unconditionally stable and blazingly fast. Laptops ran 
6hrs on an old technology NiCd battery no sweat.

OrCad 3.22 (MUCH better than today's)
MS-Word 5.0 (imported schematics and graphics just fine)
MS-Works 2.0 (did all the biz books)
Mosaic browser (the best I ever had, never crashed, not once)
CompuServe email client (also the best, did _not_ do single file)
MS C-Compiler 7.0 (if I wanted to be dangerous...)

    Windows today:

OS is totally sluggish, need two PCs at any given time to reach same 
productivity as with DOS. Laptops slurp up the charge of an expensive 
LiIon battery in under 2hrs, a large percentage of which is wasted in 
Windows overhead activity. Crashes galore.

Eagle (OrCad costs 3x of the DOS version, crashes too much IME)
MS-Word 2000 (Ok, but does crash once in a while)
MS-Works for Windows (Ok, but slow, too much fluff)
Mozilla (Crashes much less than IE but bloated)
Thunderbird (Ok, but also a bit largish)
IAR Suite because I went to uC (Pretty nice, actually)

So, there.

Look at how often the word crash occurs in each category. I know that 
the picture changes for someone like a marketing pro or graphics artist 
but for a HW designer the main difference is that both reliability and 
speed took a dump.


> 
>>Heck, if I have my druthers one day I may just go back to that MS-Works 
>>program. It's still here, on a 5-1/4 floppy. I wonder if the COM ports 
>>can be addressed from a DOS window.


-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg <notthisjoergsch@removethispacbell.net> writes:
> AFAIU you need to have a VB copy on each PC it gets installed
> on. Sure, you can then remove it but that scrapes the fringes of the
> legit range. Also, IT folks dislike installing programs that don't
> come from major SW design houses.

You know, I'm not the world's most fervent Microsoft admirer by a long
shot, but I would find it hard to describe them as anything other than
a "major SW design house".

-=Eric

Eric Schwartz wrote:

> Joerg <notthisjoergsch@removethispacbell.net> writes:
> 
>>AFAIU you need to have a VB copy on each PC it gets installed
>>on. Sure, you can then remove it but that scrapes the fringes of the
>>legit range. Also, IT folks dislike installing programs that don't
>>come from major SW design houses.
> 
> 
> You know, I'm not the world's most fervent Microsoft admirer by a long
> shot, but I would find it hard to describe them as anything other than
> a "major SW design house".
> 

It wasn't about them. It was about me (or rather someone more versed in 
programming) writing VB Code. That would be a not so major SW design 
house ;-)

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:
>>> Your are probably right. However, that's a "version control" scheme 
>>> that is totally foreign to me.
> Yes. What were they thinking? In order to remain compatible it seems you 
> must install the old versions along with the latest. Man, the FDA would 
> rip me apart in the air if I ever designed something like that.

Let me guess - you design devices which have one, or maybe two, interfaces,
being mostly in simple master-slave relationships?

Now try considering a system of 30,000-50,000 separate components, each one
with a dependency on from 5 to 50 of the others, each one potentially with
flaws and outstanding change requests, and you get some concept of the
configuration complexity. We're talking hundreds of millions of times more
configuration risk (in terms of ramifications of a change in any one of those
interfaces) than you have in your devices.

I'm not saying your devices aren't more complex internally, or that each
interface isn't complex in itself, and it's probable that *that* complexity
is higher than each of the elements of a generalized software runtime, but
they still aren't even on the same planet when you consider configuration
risk.

It doesn't help that the Windows APIs are at least an order of magnitude
more numerous than strictly required... but that's exactly why the .NET
runtime was necessary... it forms a new platform that's vastly simpler
than the old one, and can move off Intel architectures to boot (vis Mono).

Clifford Heath.

Clifford Heath wrote:

> Joerg wrote:
> 
>>>> Your are probably right. However, that's a "version control" scheme 
>>>> that is totally foreign to me.
>>
>> Yes. What were they thinking? In order to remain compatible it seems 
>> you must install the old versions along with the latest. Man, the FDA 
>> would rip me apart in the air if I ever designed something like that.
> 
> 
> Let me guess - you design devices which have one, or maybe two, interfaces,
> being mostly in simple master-slave relationships?
> 

They are a bit more complicated than that but not five-digit. The 
largest ones I design typically still have less than 100 locations that 
need to exchange data. But some of those are realtime to the point 
where, for example, another section of the whole system needs to trigger 
on an ECG signal within spec'd accuracy. Failure to do so in timely 
fashion can cause some grief.


> Now try considering a system of 30,000-50,000 separate components, each one
> with a dependency on from 5 to 50 of the others, each one potentially with
> flaws and outstanding change requests, and you get some concept of the
> configuration complexity. We're talking hundreds of millions of times more
> configuration risk (in terms of ramifications of a change in any one of 
> those
> interfaces) than you have in your devices.
> 
> I'm not saying your devices aren't more complex internally, or that each
> interface isn't complex in itself, and it's probable that *that* complexity
> is higher than each of the elements of a generalized software runtime, but
> they still aren't even on the same planet when you consider configuration
> risk.
> 
> It doesn't help that the Windows APIs are at least an order of magnitude
> more numerous than strictly required... but that's exactly why the .NET
> runtime was necessary... it forms a new platform that's vastly simpler
> than the old one, and can move off Intel architectures to boot (vis Mono).
> 

I don't dispute the need for something like .NET. It's just that I find 
the implementation not to be as organized as I'd like it or as agencies 
may request that our systems live up to.

-- 
Regards, Joerg

http://www.analogconsultants.com