From: lowell@locus.com (Lowell Morrison)
Subject: Re: FCC will proclaim Microsoft is run by Communists! : )
Organization: Locus Computing Corp, Los Angeles
Date: Mon, 28 Dec 1992 15:44:07 GMT

In article <1992Dec25.214123.5213@tc.cornell.edu> bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor) writes:
>In article <1992Dec25.181732.15997@donau.et.tudelft.nl> linstee@dutecaj.et.tudelft.nl (Erik van Linstee) writes:
>>bai@msiadmin.cit.cornell.edu (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

Newsgroups: comp.os.os2.advocacy,comp.os.os2.apps,comp.os.os2.misc