Clifford Heath wrote:> Joerg wrote: > >> 40MB to get to the ports, wow ... > > > Getting to the ports might be all *you* wanted, but the runtime provides > an entire JIT compiler-interpreter and its runtime library, i.e. it's an > entire platform, and actually quite small for what it is. >I just don't understand why Billy's folks restricted mscomm.ocx. It prevents tons of Excel and Office sales into labs from happening. From a revenue POV that is like shooting themselves in the foot.>> Your are probably right. However, that's a "version control" scheme >> that is totally foreign to me. > > > So you'd expect that old DOS program to still work under Vista, would you?Honestly I do not care because I won't let Vista into the business here. I did run some in XP. Actually I have to because some of the old filter design routines don't come any other way. The usual, a prof had an excellent group that wrote all this. Then he got older, retired, new prof came in, had other priorities on his mind and the project withered away. If XP wouldn't have run it I would just downgrade to Win2K. The only price a biz user really pays is that some stuff might then only be driveable in plain vanilla modes.> Myself, I'd rather that the platform moves on occasionally, and that means > breaking compatibility with programs that depend on bugs and design flaws > in the old version. At least with .NET you have the option of running old > programs on the old runtime, and new ones with the new one. It's not as > though they've released hundreds of versions, after all - there are only > two in play currently and a third coming. >In the med biz we don't like such moves. Our liability insurers don't either ;-) -- Regards, Joerg http://www.analogconsultants.com
Excel-RS232 via Cheapcomm: Where?
Started by ●September 19, 2007
Reply by ●September 26, 20072007-09-26
Reply by ●September 27, 20072007-09-27
In article <%QCKi.29677$eY.9501@newssvr13.news.prodigy.net>, Joerg says...> Clifford Heath wrote: > > You should be congratulating MS for finally doing something positive about > > solving DLL hell, not castigating them for your mistake. > > > > Your are probably right. However, that's a "version control" scheme that > is totally foreign to me. And I bet in my line of biz (FDA regulated) > the Federales wouldn't let that fly. With our SW newer versions must > support the old stuff. Just imagine the ER doc loading a patient file > because he urgently needs to get some info, then a message pops up > "Requires DICOM version x.xx, please contact your IT administrator".Or, a handheld device that needs to communicate with some sort of controller. Regardless of version upgrades in either they must still work together. An old handset must work with new controllers and vice versa. Carrying around two handsets is not an option. Robert -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●September 27, 20072007-09-27
Joerg <notthisjoergsch@removethispacbell.net> writes:> Clifford Heath wrote: > >> Joerg wrote: >> >>> 40MB to get to the ports, wow ... >> >> >> Getting to the ports might be all *you* wanted, but the runtime provides >> an entire JIT compiler-interpreter and its runtime library, i.e. it's an >> entire platform, and actually quite small for what it is. >> > > I just don't understand why Billy's folks restricted mscomm.ocx. It > prevents tons of Excel and Office sales into labs from happening. From > a revenue POV that is like shooting themselves in the foot. > > >>> Your are probably right. However, that's a "version control" scheme >>> that is totally foreign to me. >> >> >> So you'd expect that old DOS program to still work under Vista, would you? > > > Honestly I do not care because I won't let Vista into the business > here. I did run some in XP. Actually I have to because some of the old > filter design routines don't come any other way. The usual, a prof had > an excellent group that wrote all this. Then he got older, retired, > new prof came in, had other priorities on his mind and the project > withered away. > > If XP wouldn't have run it I would just downgrade to Win2K. The only > price a biz user really pays is that some stuff might then only be > driveable in plain vanilla modes.For your own use, you might want to look at vmware. There is a free "server" version and a pay "workstation" version. You can setup complete "virtual machines" running dos, windows 98, whatever you like. It's very slick. The virtual machines can actually access hardware, serial ports for sure maybe parallel ports too. I actually use this on linux, but you can run it under windows too. For the customer stuff, I guess the win32 API is the way to go - assuming you can access this from visual basic (or VBA for office programs?). There are only a couple of functions you need IIRC. I might have a look at this myself - we have some custom windows software for collecting data from serially connected equipment (using modbus). It would be neat to be able to send someone a spreadsheet and have this talk to the devices "directly". But I don't know if this is really practical, and it will probably break on vista or office 2007 etc. -- John Devereux
Reply by ●September 27, 20072007-09-27
On Thu, 27 Sep 2007 01:14:58 GMT, Joerg <notthisjoergsch@removethispacbell.net> wrote:>Clifford Heath wrote: > >> Joerg wrote: >> >>> 40MB to get to the ports, wow ... >> >> >> Getting to the ports might be all *you* wanted, but the runtime provides >> an entire JIT compiler-interpreter and its runtime library, i.e. it's an >> entire platform, and actually quite small for what it is. >> > >I just don't understand why Billy's folks restricted mscomm.ocx. It >prevents tons of Excel and Office sales into labs from happening. From a >revenue POV that is like shooting themselves in the foot. >They dont restrict it. If you package it up using VB, then you can distribute it freely. IF you have any questions about distributing it as part of excell then send an email to MS legal, they will give you the answer. What you are doing is outside the realms of what Excel was designed to do, why dont you just obtain a second hand copy of VB and use that? You can then package up the ocx and install it on any pc you want.> >>> Your are probably right. However, that's a "version control" scheme >>> that is totally foreign to me. >> >> >> So you'd expect that old DOS program to still work under Vista, would you? > > >Honestly I do not care because I won't let Vista into the business here. >I did run some in XP. Actually I have to because some of the old filter >design routines don't come any other way. The usual, a prof had an >excellent group that wrote all this. Then he got older, retired, new >prof came in, had other priorities on his mind and the project withered >away. > >If XP wouldn't have run it I would just downgrade to Win2K. The only >price a biz user really pays is that some stuff might then only be >driveable in plain vanilla modes. > > >> Myself, I'd rather that the platform moves on occasionally, and that means >> breaking compatibility with programs that depend on bugs and design flaws >> in the old version. At least with .NET you have the option of running old >> programs on the old runtime, and new ones with the new one. It's not as >> though they've released hundreds of versions, after all - there are only >> two in play currently and a third coming. >> > >In the med biz we don't like such moves. Our liability insurers don't >either ;-)
Reply by ●September 27, 20072007-09-27
On Thu, 27 Sep 2007 10:05:01 +0100, John Devereux <jdREMOVE@THISdevereux.me.uk> wrote:>Joerg <notthisjoergsch@removethispacbell.net> writes: > >> Clifford Heath wrote: >> >>> Joerg wrote: >>> >>>> 40MB to get to the ports, wow ... >>> >>> >>> Getting to the ports might be all *you* wanted, but the runtime provides >>> an entire JIT compiler-interpreter and its runtime library, i.e. it's an >>> entire platform, and actually quite small for what it is. >>> >> >> I just don't understand why Billy's folks restricted mscomm.ocx. It >> prevents tons of Excel and Office sales into labs from happening. From >> a revenue POV that is like shooting themselves in the foot. >> >> >>>> Your are probably right. However, that's a "version control" scheme >>>> that is totally foreign to me. >>> >>> >>> So you'd expect that old DOS program to still work under Vista, would you? >> >> >> Honestly I do not care because I won't let Vista into the business >> here. I did run some in XP. Actually I have to because some of the old >> filter design routines don't come any other way. The usual, a prof had >> an excellent group that wrote all this. Then he got older, retired, >> new prof came in, had other priorities on his mind and the project >> withered away. >> >> If XP wouldn't have run it I would just downgrade to Win2K. The only >> price a biz user really pays is that some stuff might then only be >> driveable in plain vanilla modes. > >For your own use, you might want to look at vmware. There is a free >"server" version and a pay "workstation" version. You can setup >complete "virtual machines" running dos, windows 98, whatever you >like. It's very slick. The virtual machines can actually access >hardware, serial ports for sure maybe parallel ports too. I actually >use this on linux, but you can run it under windows too. > >For the customer stuff, I guess the win32 API is the way to go - >assuming you can access this from visual basic (or VBA for office >programs?). There are only a couple of functions you need IIRC. I >might have a look at this myself - we have some custom windows >software for collecting data from serially connected equipment (using >modbus). It would be neat to be able to send someone a spreadsheet and >have this talk to the devices "directly". But I don't know if this is >really practical, and it will probably break on vista or office 2007 >etc.Office 2007 uses the same technology (VBA) but i just had a look and i cant see the com control object. It may still be shipped with office but its not immediately visible.
Reply by ●September 27, 20072007-09-27
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. Now tell me functionality has not increased.>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.
Reply by ●September 27, 20072007-09-27
The Real Andy wrote:> On Thu, 27 Sep 2007 10:05:01 +0100, John Devereux > <jdREMOVE@THISdevereux.me.uk> wrote: > > >>Joerg <notthisjoergsch@removethispacbell.net> writes: >> >> >>>Clifford Heath wrote: >>> >>> >>>>Joerg wrote: >>>> >>>> >>>>>40MB to get to the ports, wow ... >>>> >>>> >>>>Getting to the ports might be all *you* wanted, but the runtime provides >>>>an entire JIT compiler-interpreter and its runtime library, i.e. it's an >>>>entire platform, and actually quite small for what it is. >>>> >>> >>>I just don't understand why Billy's folks restricted mscomm.ocx. It >>>prevents tons of Excel and Office sales into labs from happening. From >>>a revenue POV that is like shooting themselves in the foot. >>> >>> >>> >>>>>Your are probably right. However, that's a "version control" scheme >>>>>that is totally foreign to me. >>>> >>>> >>>>So you'd expect that old DOS program to still work under Vista, would you? >>> >>> >>>Honestly I do not care because I won't let Vista into the business >>>here. I did run some in XP. Actually I have to because some of the old >>>filter design routines don't come any other way. The usual, a prof had >>>an excellent group that wrote all this. Then he got older, retired, >>>new prof came in, had other priorities on his mind and the project >>>withered away. >>> >>>If XP wouldn't have run it I would just downgrade to Win2K. The only >>>price a biz user really pays is that some stuff might then only be >>>driveable in plain vanilla modes. >> >>For your own use, you might want to look at vmware. There is a free >>"server" version and a pay "workstation" version. You can setup >>complete "virtual machines" running dos, windows 98, whatever you >>like. It's very slick. The virtual machines can actually access >>hardware, serial ports for sure maybe parallel ports too. I actually >>use this on linux, but you can run it under windows too. >> >>For the customer stuff, I guess the win32 API is the way to go - >>assuming you can access this from visual basic (or VBA for office >>programs?). There are only a couple of functions you need IIRC. I >>might have a look at this myself - we have some custom windows >>software for collecting data from serially connected equipment (using >>modbus). It would be neat to be able to send someone a spreadsheet and >>have this talk to the devices "directly". But I don't know if this is >>really practical, and it will probably break on vista or office 2007 >>etc. > > > Office 2007 uses the same technology (VBA) but i just had a look and i > cant see the com control object. It may still be shipped with office > but its not immediately visible.Was the same in '97. They do not allow the use of mscomm unless you also buy a VB Pro license. At least that's how I understood it. Makes absolutely no business sense on the part of Microsoft but then again a lot of things don't make sense. -- Regards, Joerg http://www.analogconsultants.com
Reply by ●September 27, 20072007-09-27
John Devereux wrote:> Joerg <notthisjoergsch@removethispacbell.net> writes: > > >>Clifford Heath wrote: >> >> >>>Joerg wrote: >>> >>> >>>>40MB to get to the ports, wow ... >>> >>> >>>Getting to the ports might be all *you* wanted, but the runtime provides >>>an entire JIT compiler-interpreter and its runtime library, i.e. it's an >>>entire platform, and actually quite small for what it is. >>> >> >>I just don't understand why Billy's folks restricted mscomm.ocx. It >>prevents tons of Excel and Office sales into labs from happening. From >>a revenue POV that is like shooting themselves in the foot. >> >> >> >>>>Your are probably right. However, that's a "version control" scheme >>>>that is totally foreign to me. >>> >>> >>>So you'd expect that old DOS program to still work under Vista, would you? >> >> >>Honestly I do not care because I won't let Vista into the business >>here. I did run some in XP. Actually I have to because some of the old >>filter design routines don't come any other way. The usual, a prof had >>an excellent group that wrote all this. Then he got older, retired, >>new prof came in, had other priorities on his mind and the project >>withered away. >> >>If XP wouldn't have run it I would just downgrade to Win2K. The only >>price a biz user really pays is that some stuff might then only be >>driveable in plain vanilla modes. > > > For your own use, you might want to look at vmware. There is a free > "server" version and a pay "workstation" version. You can setup > complete "virtual machines" running dos, windows 98, whatever you > like. It's very slick. The virtual machines can actually access > hardware, serial ports for sure maybe parallel ports too. I actually > use this on linux, but you can run it under windows too. >Thanks, I forgot about that.> For the customer stuff, I guess the win32 API is the way to go - > assuming you can access this from visual basic (or VBA for office > programs?). There are only a couple of functions you need IIRC. I > might have a look at this myself - we have some custom windows > software for collecting data from serially connected equipment (using > modbus). It would be neat to be able to send someone a spreadsheet and > have this talk to the devices "directly". But I don't know if this is > really practical, and it will probably break on vista or office 2007 > etc. >Yes, exactly, it'll be customer stuff so has to run on whatever their IT guys have blessed. And that will be the usual Windows/Office setup. Sometimes MS thoroughly messes up, like with .NET or Vista, but with Office they have (so far, knock on wood ...) not wrecked backward compatibility. If they did the repercussions from the business community would be severe. There is a lot more legacy stuff in business that remains crucial and will be used for years to come. Many of their financial files and routines date all the way back to the 80's. -- Regards, Joerg http://www.analogconsultants.com
Reply by ●September 27, 20072007-09-27
The Real Andy wrote:> On Thu, 27 Sep 2007 01:14:58 GMT, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > > >>Clifford Heath wrote: >> >> >>>Joerg wrote: >>> >>> >>>>40MB to get to the ports, wow ... >>> >>> >>>Getting to the ports might be all *you* wanted, but the runtime provides >>>an entire JIT compiler-interpreter and its runtime library, i.e. it's an >>>entire platform, and actually quite small for what it is. >>> >> >>I just don't understand why Billy's folks restricted mscomm.ocx. It >>prevents tons of Excel and Office sales into labs from happening. From a >>revenue POV that is like shooting themselves in the foot. >> > > > They dont restrict it. If you package it up using VB, then you can > distribute it freely. IF you have any questions about distributing it > as part of excell then send an email to MS legal, they will give you > the answer. > > What you are doing is outside the realms of what Excel was designed to > do, why dont you just obtain a second hand copy of VB and use that? > You can then package up the ocx and install it on any pc you want. >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. With an Excel file that's different even if they have to click ok for macros because it is still considered a file. Although a heavily VBA-laden file is in reality software.> >>>>Your are probably right. However, that's a "version control" scheme >>>>that is totally foreign to me. >>> >>> >>>So you'd expect that old DOS program to still work under Vista, would you? >> >> >>Honestly I do not care because I won't let Vista into the business here. >>I did run some in XP. Actually I have to because some of the old filter >>design routines don't come any other way. The usual, a prof had an >>excellent group that wrote all this. Then he got older, retired, new >>prof came in, had other priorities on his mind and the project withered >>away. >> >>If XP wouldn't have run it I would just downgrade to Win2K. The only >>price a biz user really pays is that some stuff might then only be >>driveable in plain vanilla modes. >> >> >> >>>Myself, I'd rather that the platform moves on occasionally, and that means >>>breaking compatibility with programs that depend on bugs and design flaws >>>in the old version. At least with .NET you have the option of running old >>>programs on the old runtime, and new ones with the new one. It's not as >>>though they've released hundreds of versions, after all - there are only >>>two in play currently and a third coming. >>> >> >>In the med biz we don't like such moves. Our liability insurers don't >>either ;-)-- Regards, Joerg http://www.analogconsultants.com
Reply by ●September 27, 20072007-09-27
Robert Adsett wrote:> In article <%QCKi.29677$eY.9501@newssvr13.news.prodigy.net>, Joerg > says... > >>Clifford Heath wrote: >> >>>You should be congratulating MS for finally doing something positive about >>>solving DLL hell, not castigating them for your mistake. >>> >> >>Your are probably right. However, that's a "version control" scheme that >>is totally foreign to me. And I bet in my line of biz (FDA regulated) >>the Federales wouldn't let that fly. With our SW newer versions must >>support the old stuff. Just imagine the ER doc loading a patient file >>because he urgently needs to get some info, then a message pops up >>"Requires DICOM version x.xx, please contact your IT administrator". > > > Or, a handheld device that needs to communicate with some sort of > controller. Regardless of version upgrades in either they must still > work together. An old handset must work with new controllers and vice > versa. Carrying around two handsets is not an option. >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. <banging head on table> -- Regards, Joerg http://www.analogconsultants.com
