Searching \ for '[OT] Industrial applications - DOS or Windows?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=industrial+applications
Search entire site for: 'Industrial applications - DOS or Windows?'.

Exact match. Not showing close matches.
PICList Thread
'[OT] Industrial applications - DOS or Windows?'
1999\09\20@131024 by John Waters

picon face
<x-flowed>Hi All,

As a system integrator, I used to build control systems for customers using
industrial/embedded PCs, but as Windows has replaced DOS in the commercial
sector, unless I packaged my product as a proprietary system, many of my
customers will query if they are advanced enough since they are still
running on DOS. However, to me, I still find DOS the most economical and
programmer friendly o.s. to use in many industrial applications, especially
when a graphical user interface is not needed.
Am I making a wrong decision of retaining a phasing out o.s. in my product?
Or can anyone suggest me some ways to make my customers confident in my DOS
based systems?

Cheers
John




______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

</x-flowed>

1999\09\20@200023 by Antonio L Benci

flavicon
picon face
part 0 2744 bytes content-type:text/x-vcard; name=Nino.Benci.vcf; charset=us-ascii (decoded 7bit)

There are too many situations where simplicity is the goal. Most control
systems that i design only provide 1Mbyte RAM, floppy interface and a
basic LCD and pushbutton interface, here Windows(TM) would be an
unwanted overkill and have too much overhead to warrant it use...

The other matter is cost. A simple DOS based x386 controller is really
cheap and there are lots of excellent low cost tools available,
FirstBasic, Pacific C, Turbo Pascal. For data acquisition and process
control do you really need a PIII with 128 Mbyte ram and 12 GB harddisk
and Win95/98 ???

John Waters wrote:
{Quote hidden}

Just present them a development cost comparison which takes into account
the system and on going maintenance costs... Once you've done this you
may find that for your design requirements DOS is fine and reasonably
robust... If you can, get a hold of 'Embedded Systems Programming' a
Miller Freeman Publication. This magazine provides a very good overview
of development tools and methods for embedded systems...

Cheers
Nino
--
******************************************************
* Antonio (Nino) Benci                               *
* Professional Officer / Electronic Services Manager *
* Monash University - Dept of Physics                *
* Wellington Rd, Clayton. 3168                       *
* Victoria, Australia.                               *
* TEL    - 61 3 9905 3649, FAX - 61 3 9905 3637      *
* Mobile - 0414 764 763 (private and ah only)        *
* EMAIL  - spam_OUTnino.benciTakeThisOuTspamsci.monash.edu.au (work)       *
*        - .....fleatechKILLspamspam@spam@excite.com (private)             *
* WWW    - http://www.physics.monash.edu.au/                *
******************************************************

Content-type: text/x-vcard; name=Nino.Benci.vcf; charset=us-ascii
Content-description: Card for Antonio L Benci
Content-disposition: attachment; filename=Nino.Benci.vcf
Content-transfer-encoding: 7BIT

Attachment converted: wonderland:Nino.Benci.vcf (TEXT/CSOm) (0000C9D8)

1999\09\20@230135 by McMeikan, Andrew

flavicon
face
I would have thought it obvious, use Linux

       cya,    Andrew...

PS: there is a real time version of Linux just for this sort of thing.  You
can still run dos under it to.

> {Original Message removed}

1999\09\21@013653 by Wes Johnston

flavicon
face
DOS will continue to work until 2038... and LOTS of C programs will stop
working then too.  Win2000 won't run a dos app in a window, you have to exit
windows to run ONE dos app.... for dedicated PC, I wouldn't sweat it...
we've got another 39 years of use from DOS.  From a slightly different
perspective, we are presently running a console as an interface to the
computers that run our papermachines with a  DOS app that I wrote a few
years ago - a simple terminal emulator with a few custom bells and whistles.
The only problem we are having is that the PCs use RLL drives and don't
support IDE drives.  As they fail, we are replacing them with win95 PC's I
am finding that win95 running on a p3 500mhz allows a 16 bit DOS app to
steal 100% cpu time.  In other words, a single DOS app is bringing a p3
500mhz to its knees.  Perhaps this is a consideration for your system, I
don't know.  I remember in win3.11 you could control the time slice of any
app, but in win95/98 , you can't that I've seen yet.

As an example of how long you can use a dedicated system... The computers I
work on at work are Honeywell level 6's, have 8inch disk drives, and were
new in 1970.  We have to boot them from a special front panel with a very
special "hi tech advanced" LED *numeric* display and keypad.  This was an
improvement over the old system where we had to key the boot strap code in
octal. <grin>.

Of course on the other hand.... most of the software we are now looking out
for with this whole y2k problem is based on the fact that NO ONE actually
believed that a program written in 1960 would be still in use today.

Wes -  kd4rdbspamKILLspamqsl.net
 http://www.qsl.net/kd4rdb

Where am I?
  http://map.aprs.net/kd4rdb-9
  http://map.aprs.net/kd4rdb-10

Stupidity should be painful
{Original Message removed}

1999\09\21@024731 by William K. Borsum

flavicon
face
At 10:08 AM 9/20/99 PDT, you wrote:
>Hi All,
>
>As a system integrator, I used to build control systems for customers using
>industrial/embedded PCs, but as Windows has replaced DOS in the commercial
>sector, unless I packaged my product as a proprietary system, many of my
>customers will query if they are advanced enough since they are still
>running on DOS. However, to me, I still find DOS the most economical and
>programmer friendly o.s. to use in many industrial applications, especially
>when a graphical user interface is not needed.
>Am I making a wrong decision of retaining a phasing out o.s. in my product?
>Or can anyone suggest me some ways to make my customers confident in my DOS
>based systems?

I like DOS--I loved CPM.  Could do things that are truly impossible under
any form of windows/GUI environment--particularly if SPEED was an issue.
Building your own TSR's was not impossible.  a real "open" architecture.

On the other hand---you can do graphical and image things in windows, along
with a lot of event driven tasks in windows that would be virtually
impossible in DOS.

So why not combine the two?  Seem to recall that the old QBASIC provided a
compiler that generated .EXE files, along with the intermediate .OBJ's etc.
Run the critical stuff under a basic window that gets exclusive control.

I've got a number of programs that do just that for speed, then use the
windows environment for the operator interface stuff.

>From a marketing standpoint, just hide the fact it is primarily a DOS based
system and most people won't know the difference.  Or seriously hype the
DOS advantages.

Asyst was a Forth based language that I used extensively on the old DOS 286
machines--did some serious aerospace work.  Ten man years into a project
for Grumman that still hasn't been duplicated under windows.  Unfortunately
there was not enough market for Asyst to survive and advance along with the
processors.

Is DOS going away--I still see a command file in the windows directory with
a lot of files that still look like the old DOS system, even in '95 and '98.

If your systems WORK and are cheaper than the competition, I'd say stick
with DOS.  BUT listen to your clients--they have the money and the "power".
Darn it.

My nickels worth
kelly


William K. Borsum, P.E. -- OEM Dataloggers and Instrumentation Systems
<.....borsumKILLspamspam.....dascor.com> & <http://www.dascor.com>

1999\09\21@042243 by Dr. Imre Bartfai

flavicon
face
Hi,

I am definitely for DOS. I do also my (almost) full development activities
using this o.s. Applications developped by me for PC runs only using DOS
(maybe in a DOS Window). However, the DOS I am using is the Caldera Open
DOS, rather than MS. It is stable, well-documented and
resource-economical. The C compiler I am using is the Micro-C from
Dunfield Development Systems, as it is practically bug-free, and the
programs generated are as small as they would be written in assembly. (A
pain that Mr. Dunfield has not created a PIC C compiler yet...)

The customer should be satisfied that instead of continuous danger of data
loss and system crash he can use a smaller but (almost: rock) stable o.s.
as result of decision coming from serious programmers.

Here is my $0.02.

Imre

PS: another very important argument is the possibility of direct accessing
of hardware component under DOS so it can be treated as RTOS.


On Mon, 20 Sep 1999, John Waters wrote:

{Quote hidden}

1999\09\21@042449 by wzab

flavicon
picon face
On Mon, Sep 20, 1999 at 10:08:10AM -0700, John Waters wrote:
> Hi All,
>
> As a system integrator, I used to build control systems for customers using
> industrial/embedded PCs, but as Windows has replaced DOS in the commercial
> sector, unless I packaged my product as a proprietary system, many of my
> customers will query if they are advanced enough since they are still
> running on DOS. However, to me, I still find DOS the most economical and
> programmer friendly o.s. to use in many industrial applications, especially
> when a graphical user interface is not needed.
> Am I making a wrong decision of retaining a phasing out o.s. in my product?
> Or can anyone suggest me some ways to make my customers confident in my DOS
> based systems?
>
My suggestion is:
If your embedded system has enough memory/disk to run Windows, use Linux, which
will be much more efficient and stable on the same hardware.
If your system has small memory (<8MB) use DOS.
If you are brave and do not want to pay royalties, use the FreeDos
(http://www.freedos.org).
If you want to avoid Micro$oft bugs, use the DR DOS (which is Y2K
compatible)
(http://www.calderathin.com/products/drdos/drdos.html).
If you need some real-time processing, use the RT Linux, or if you have
a lot of money, buy QNX.
Certainly, my point of view is biased...
--
                               hope this helps
                             Wojciech M. Zabolotny
       http://www.ise.pw.edu.pl/~wzab  <--> EraseMEwzabspam_OUTspamTakeThisOuTise.pw.edu.pl

http://www.debian.org  Linux - free OS for free people!

1999\09\21@060110 by Gennette Bruce

flavicon
face
Something extra to think about - you were talking about the apparent failure
of developers to plan sufficiently far enough ahead -

> {Original Message removed}

1999\09\21@075817 by Harrison Cooper

flavicon
face
my .02 worth.....unless you need a fancy graphical output, and even those
can be done without an OS, stick with the simplest interface...

1999\09\21@100014 by Mike Mansheim

picon face
May I ask why DOS programs will not work after 2038??

--- Wes Johnston <kd4rdbspamspam_OUTNETZERO.COM> wrote:
> DOS will continue to work until 2038... and LOTS of
> C programs will stop
> working then too.
<snip>
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

1999\09\21@103228 by Wagner Lipnharski

picon face
Windows and other equivalent platforms were developed for the common
dumb user (sorry, no offense), since Bill Gates wanted to create
something that *everyone* could use, not requiring computer deep
knowledge to operate.

You must agree with me that it is so much easier to copy a floppy using
Windows icones than the traditional DOS commands.  For someone that
knows DOS it is pretty easy, but for someone that can't even recognize
which letter is assigned to the floppy disk, it is a disaster. Does it
change in Windows? not so much. The only big difference is the
substitution of keyboard typing for icones drag and drop, and fancy
color display, nothing else.

Lots of facilities were incorporated to Windows, so the programmer
doesn't need to work hard to produce a graphic image or intrincated
directory & file structure display, as it is in DOS, added to the 640k
DOS limitation.

So, I can say that if you know what you are doing in software, DOS
offers less problems and give you more machine control, with less
required disk space and less and tinny files to instal.

I can be retarded somehow, but I already got few problems to develop
software for Windows, those run pretty nice in DOS without any extra
effort.

Wagner.

1999\09\21@115506 by Harold M Hallikainen

picon face
       Another DOS to consider for embedded applications is ROM-DOS from
DataLight.  I've done a few projects with it and it has worked well.  I
put a single EPROM on an ISA board.  The EPROM appeared as a BIOS hook
which then loaded DOS and the application from EPROM up above 8 meg in
the memory map.

Harold



Harold Hallikainen
@spam@haroldKILLspamspamhallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.

1999\09\22@011950 by Gennette Bruce

flavicon
face
> -----Original Message-----
> From: Mike Mansheim [SMTP:KILLspammike_mansheimKILLspamspamYAHOO.COM]
> Sent: Wednesday, 22 September 1999 0:09
> To:   RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
> Subject:      Re: [OT] Industrial applications - DOS or Windows?
>
> May I ask why DOS programs will not work after 2038??
>
> --- Wes Johnston <spamBeGonekd4rdbspamBeGonespamNETZERO.COM> wrote:
> > DOS will continue to work until 2038... and LOTS of
> > C programs will stop
> > working then too.
> <snip>
>
Microsoft counts seconds from an arbitrary starting date (I think it is
1-1-1980) and calculates the date and time from that number. Once the number
field is filled the dates will roll-over - this will happen in 2038, then
all old DOS programs are on their own.

Bye.

1999\09\22@032823 by Lee Jones

flavicon
face
>> May I ask why DOS programs will not work after 2038??

> Microsoft counts seconds from an arbitrary starting date

No, seconds elapsed from 1-1-1970 UTC (aka GMT) in a 32 bit
word is Unix.


> (I think it is 1-1-1980)

That's the correct base date for DOS file date/time stamps.
Set the file modification date/time stamp to all zeros and
a directory listing shows 1-1-1980.


> and calculates the date and time from that number. Once the
> number field is filled the dates will roll-over - this will
> happen in 2038, then all old DOS programs are on their own.

Actually, the DOS file date/time stamp is 32 bits but it is
stored in 2 16 bit words.  One word contains year (7 bits),
month (4 bits), and day of month (5 bits).

The other word contains the hour (5 bits), minute (6 bits),
and second (5 bits).  Note that the seconds field is too small
to go all the way to 60, so Microsoft drops the low order bit.
Last field actually counts in 2-second units.

Here's a graphical layout of the fields (use a monospaced font):

/* MS-DOS stores the file modification date & time in 2 16-bit words
* in the following format:
*
*                  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
* last write date: |   (year - 1980)    |   month   |     day      |
*                  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
* last write time: |     hour     |     minute      |   second/2   |
*                  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
*   bit positions: |15          11|10  9| 8        6| 5           0|
*/


So DOS file dates will overflow at the end of 2107.

                                               Lee Jones

1999\09\22@035739 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

Maybe we'd better start considering putting a Y2.107K plan together... :o)

Mike Rigby-Jones

1999\09\22@044350 by Dr. Imre Bartfai

flavicon
face
Hi,
I think you're confused. An overflow in 2038 occurs in Linux/Unix, because
a second counter overflows which has been started in 1900. Proof:

2 ^ 32 / (365.25 * 24 * 3600) = 136

I do not believe DOS has the same problem.

Regards,
Imre


On Wed, 22 Sep 1999, Gennette Bruce wrote:

> > {Original Message removed}

1999\09\22@101803 by Andy Kunz

flavicon
face
At 07:09 AM 9/21/99 -0700, you wrote:
>May I ask why DOS programs will not work after 2038??

Same reason UNIX won't!

Andy

==================================================================
Eternity is only a heartbeat away - are you ready?  Ask me how!
------------------------------------------------------------------
andyEraseMEspam.....rc-hydros.com      http://www.rc-hydros.com     - Race Boats
EraseMEandyspammontanadesign.com  http://www.montanadesign.com - Electronics
==================================================================

1999\09\22@102159 by Wagner Lipnharski

picon face
Gennette Bruce wrote:
> Microsoft counts seconds from an arbitrary starting date (I think it is
> 1-1-1980) and calculates the date and time from that number. Once the number
> field is filled the dates will roll-over - this will happen in 2038, then
> all old DOS programs are on their own.

This is possible to happens with several other programs that use seconds
count to calculate dates and days of the week.  From 1980 to 2038 is
aprox 1.830.297.600 seconds, or 6D182000 in hex, what is not using whole
bits in those bytes... I did not calculate it with precision, but
doesn't make sense, if the starting date is 1980.

I will change date to 2039 in my laptop (at home) and make some tests
about extract date/time from DOS Time Functions and post the result
tonight.

1999\09\22@102632 by Andy Kunz

flavicon
face
>I do not believe DOS has the same problem.

It does.

Andy

==================================================================
Eternity is only a heartbeat away - are you ready?  Ask me how!
------------------------------------------------------------------
RemoveMEandyEraseMEspamEraseMErc-hydros.com      http://www.rc-hydros.com     - Race Boats
RemoveMEandyspam_OUTspamKILLspammontanadesign.com  http://www.montanadesign.com - Electronics
==================================================================

1999\09\22@104041 by Andy Kunz

flavicon
face
>count to calculate dates and days of the week.  From 1980 to 2038 is

1/1/1970.  Same as Unix.

File dates are done differently.

Andy

==================================================================
Eternity is only a heartbeat away - are you ready?  Ask me how!
------------------------------------------------------------------
RemoveMEandyTakeThisOuTspamspamrc-hydros.com      http://www.rc-hydros.com     - Race Boats
EraseMEandyspamspamspamBeGonemontanadesign.com  http://www.montanadesign.com - Electronics
==================================================================

1999\09\22@163721 by wzab

flavicon
picon face
On Wed, Sep 22, 1999 at 03:18:20PM +1000, Gennette Bruce wrote:
> > -----Original Message-----
> > From: Mike Mansheim [SMTP:RemoveMEmike_mansheimKILLspamspamYAHOO.COM]
> >
> > May I ask why DOS programs will not work after 2038??
> >
> > --- Wes Johnston <kd4rdbSTOPspamspamspam_OUTNETZERO.COM> wrote:
> > > DOS will continue to work until 2038... and LOTS of
> > > C programs will stop
> > > working then too.
> > <snip>
> >
> Microsoft counts seconds from an arbitrary starting date (I think it is
> 1-1-1980) and calculates the date and time from that number. Once the number
> field is filled the dates will roll-over - this will happen in 2038, then
> all old DOS programs are on their own.
>
There is the same problem in all 32-bit Unix'es and their clones.
time_t is unsigned integer, and it returns number of seconds since 1-1-1970.
Additionally time_t is used to store dite in filesystems, so it is not so easy
to fix it :-(.
When I asked about it on one of Linux mailing list, the answer was: Up to this
time we all will upgrade to 64-bit architectures :-)))).

--
                       Wojciech Zabolotny
                       http://www.ise.pw.edu.pl/~wzab

http://www.debian.org  Use Linux - save your data and time

1999\09\22@225630 by bowman

flavicon
face
Wagner Lipnharski wrote:

> I will change date to 2039 in my laptop (at home) and make some tests
> about extract date/time from DOS Time Functions and post the result
> tonight.


I don't know what happens to the extra seconds, but if you run 12/31/37
through the gcc C library conversions to a time_t val, it gets close to
0x7fffffff. Conversely, a time_t == 0 converts to 1/1/80. Trying to
convert 1/1/38 yields -1.

If nothing else, software using the C library localtime(), mktime() etc
will have trouble if time_t doesn't get kicked out to 64 bits. Not a
personal concern of mine; if I live that long, software will be the
least of my problems.



--
Bear Technology  Making Montana safe for Grizzlies

http://people.montana.com/~bowman/

1999\09\23@041350 by Dr. Imre Bartfai

flavicon
face
On Wed, 22 Sep 1999, Andy Kunz wrote:

> >count to calculate dates and days of the week.  From 1980 to 2038 is
>
> 1/1/1970.  Same as Unix.
 ^^^^^^^^                    True.
            ^^^^^^^^^^^^     I would not sure... Could you tell me the
source of that information. I bet Unix starts to count from 1900-1-1.
>
> File dates are done differently.
                     ^^^^^^^^^^^^    Correct.
{Quote hidden}

1999\09\23@042428 by Dr. Imre Bartfai

flavicon
face
Hi,

according to 'man 2 time' the starting age for time_t is 1/1/1970 instead
of 80. Otherwise your statement is correct.

Regards,
Imre


On Wed, 22 Sep 1999, bowman wrote:

{Quote hidden}

1999\09\24@164144 by Graeme Smith

flavicon
face
Hi....

The primary problem with dos... Timing Out, is in the applications where
the last update field is important.

If your program does not bother about the last update field, and it
doesn't sense the last update field, at any point, then... why would it
care, if the dos update field is "Out of date".

The problem comes primarily at installation when, you are attempting to
update an existing program. Often software venders use the last update
field, to determine which version of a file you are using. In the case
where you are using a DLL file that has a date AFTER the roll over, the
computer will not be able to recognize it as being the update, and you
will get one of those famous "The file you are installing is older than
the existing file" type messages.

So, the primary problem will be during installation of your program after
the date of roll-over.

There might be other problems, but it is primarily the file-system that is
limited. The calculation of the date stamp for that however, is part of
the BIOS time/date routines, so you might have problems if you are not
doing the low level timebase yourself.

                               GREY

GRAEME SMITH                         email: EraseMEgrysmithspamEraseMEfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Wed, 22 Sep 1999, Andy Kunz wrote:

{Quote hidden}

1999\09\24@165435 by Graeme Smith

flavicon
face
Just to be terribly odius....

We are all getting updates regularly anyways... right?

so why not simply change the base date as of a particular update?

have it set to simulate the old date up until the roll-over and then,
when all else has failed, simply start using the new date standard after
roll-over or some set date....

It's only a STANDARD after all, when it is obsolete, why force people out
of legacy systems, when all that is needed is an update?

With UNIX, the date routine should be modularized so that it can be
replaced at need.

But then, that is only my .00002 cents worth ;)

                               GREY

GRAEME SMITH                         email: .....grysmithspam_OUTspamfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...