NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/os2/advocacy/11003

Internet Message Format | 1992-12-28 | 6.2 KB

Xref: sparky comp.os.os2.advocacy:11003 comp.os.ms-windows.advocacy:3461
Newsgroups: comp.os.os2.advocacy,comp.os.ms-windows.advocacy
Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!orchard.la.locus.com!prodnet.la.locus.com!lowell
From: [e-mail] (Lowell Morrison)
Subject: Re: FCC will proclaim Microsoft is run by Communists! : )
Message-ID: <[e-mail]>
Organization: Locus Computing Corp, Los Angeles
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 28 Dec 1992 15:44:07 GMT
Lines: 130

In article <[e-mail]> [e-mail] (Dov Bai-MSI Visitor) writes:
>In article <[e-mail]> [e-mail] (Erik van Linstee) writes:
>>[e-mail] (Dov Bai-MSI Visitor) writes:
>
>Erik, as a short exercise I suggest that you take a look at the FAQ
>for the msdos.programmer group and see how many of the questions
>are related directly to hardware and system. You will find many.
>
I have, and am amazed at the need to know things for plain jane dos
that these programmers are asking.  I have programmed for 17 years
quite effectively without knowing these things about DOS.

>>No, one need not know about segment:offset. Why do you think they
>>should?
>
>One should because some compilers (e.g. MS-C) provide _based pointers.
>I think that a good programmer should know how to use them. In addition
>it is related to structure packing.
Ah, MS-C, how about pascal, basic, cobol, apl and other staples of the
programmers diet, rather than just the latest fad.  And I admit, it may
well become the only way to program for these new operating systems.


>
>Also, it is sometimes needed to write inline assembly and
>you must be aware of the architecture.
>
Most inline assembly I have seen makes the assumption that you are programming
for an 8086, not these newer processors.  This is the legacy of DOS.

>>Yes, one needs to know what memory model to use when programming
>>in C, but only to optimise results. That is a feature C provides.
>                   ^^^^^^^^
>And a good programmer is not supposed to optimize ? Is there
>also a third category of an Optimizing Programmer -:) ?
>
Hmm, since M$ produces some of the largest, bulkiest Code I have
ever seen, I think they need to take your advice.

>>Programming in Pascal does not involve memory models. Anyway,
>>choosing the memory model is no programming decision, proper
>>code is not affected by memory model.
>
>That is not true at all. Near, far, hugh pointers are not a standard
>of any language. They are compiler extensions directly related to
>the segmented architecture. A good programmer is expected to know
>how to use them effectively.
>
>You cannt write a program with a data item extending 64k, without
>using the huge model. But the huge model is not the default. If you
>dont use it, your code may give the wrong results and you would not
>know what is going on if you are not aware of the segmented architecure.
>
Again, it is just a matter of using the compiler switch or proper
library.  No need to be terrably concerned about the internals.

>>No, one can not program effectively for DOS period.
>
>Nonetheless there are about 90 million  DOS installed. A good programmer
>is expected to program as effectively as possible.
>

Mostly running software written for the 8086 series.
>>>How about the differences between 286/386 ?
>>
>>Well, what about them?
>
>(1) Memory mapping (2) An optional 32-bit programming (3) 16M memory
>limit in 286 (4) flat memory model with an appropriate  DOS extender
>(5) switching time from real to protected mode considerably different.
>
>>>How about the 640k limit and how to overcome it ? Need not the
>>>programmer know about extended/expanded memory, DPMI/VCPI interfaces ?
>>
>>The 640k limit is of no concern. When you write an app. and you
>>need memory, you request it and check if you got it. You do not
>>consider if maybe the target system has a specific limit, you
>>just check for any limit to be reached.
>
>(1) The concern for memory is different if the memory limit is low.
>(2) In shortage of memory the programmer may use overlays.
>
>>No, a programmer needn't know about DPMI/VCPI interfaces. If he
>>wants memory, he requests it, he does not generally care where it
>>comes from. The DPMI/VCPI interface should be hidden from him,
>>unless of course he is writing his own memory management, but
>>I can't think of a reason why an application should need that.
>
>>>I have in front of me the second edition (1992) of the book
>>>"Extending DOS - A Programmer's Guide to Protected Mode DOS" by
>>>Ray Duncan. The first introductory chapter include detailed description
>>>of selectors, descriptors etc.
>>
>>Protected mode DOS, where can you buy that?
>
>Come now, your last few postings were to convince me that the
>programmer does _not_  need such a book. Why are you interested ?
>
>>Oh wait, it says
>>Extending DOS. So it isn't part of DOS? Then it can't be of
>>a DOS app. programmers concern, can it? Looks like systems programming
>>to me, but I could be wrong.
>
>Sure, protected mode is not part of DOS. But that is the whole point:
>DOS is so deficient that much of the work must be provided
>by the programmer. That is why there is no real distinction between
>system and application programming for a good, efficient DOS programmer.
>

Ah, the truth comes out, we are NOT talking about programming for DOS
at all, but trying to work with a Hybrid-system-application to go
beyond DOS.  There is a Huge difference between System and Application
programmers.  I work at a Unix Kernel Development house, and they can
make a system do anything, but are hopeless as application developers.
You see, they simply cannot understand a User Interface for a Word Processor
the best they can do is VI.....

>BTW: Does any body think that if a "system programmer" at MS
>has written an interrupt handler for the "application" group
>he must tell it to all the competitors? Is it another case of
>"predatory tactics" ?
>
>>
>>Erik van Linstee   |   Delft University of Technology   |   I'll be back ...
>
>Dov

--Lowell Morrison
--Uncle Wolf