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

Internet Message Format | 1992-12-26 | 7.0 KB

Xref: sparky comp.os.os2.advocacy:10949 comp.os.ms-windows.advocacy:3434
Newsgroups: comp.os.os2.advocacy,comp.os.ms-windows.advocacy
Path: sparky!uunet!mcsun!sun4nl!dutrun!donau!dutecaj.et.tudelft.nl!linstee
From: [e-mail] (Erik van Linstee)
Subject: Re: FCC will proclaim Microsoft is run by Communists! : )
Message-ID: <[e-mail]>
Sender: [e-mail] (UseNet News System)
Nntp-Posting-Host: dutecaj.et.tudelft.nl
Organization: Delft University of Technology, Dept. of Electrical Engineering
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 26 Dec 1992 12:10:58 GMT
Lines: 152

[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.

>>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.


Depends of the level he is programming at.
>Also, it is sometimes needed to write inline assembly and
>you must be aware of the architecture.


Well, you are right about assembly language, but there is good
reason not to use it, therefore not having to know about
seg:ofs. This kind of knowledge is necessary for directly
programming to the system, or even system programming, but
for applications, I say not. No software engineering or programming
course or whatever I have seen involves memory models. It is
about algorithms and such.


>>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 -:) ?

Depends on how far you want to go. Will there really be a large
penalty in performance or memory usage when a huge model is
used where a compact could be used?

>
>>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.

Well, I have not yet encountered a situation where I had to be
concerned about whether a pointer was far, near or huge. Conversions
are done implicitly and where they are not, it is because of a
defeciency of the compiler. But don't get me wrong, I do know
about architectures.


>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.

That is true, but that is a limitation of the compiler, isn't it?
The compiler should be smart enough to find the right model.
But, this is not what I meant to say before. I meant the programmer
should just request memory and see if he gets it or not. If this
always results in not whenever he requests more than 64k, that is
a shame, but this is no special case over the other cases where
the memory is not available for other reasons.
Besides, knowing the limitations of your C or other language compiler,
wouldn't you write a piece of code that solves it and can be used
henceforth? Or at least ask a system programmer to do it and then
use it for ever more. That would be good programming practice.

>
>>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.

>>>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.

Yes, of course, but those are not DOS programming considerations.


>>>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.

There is always the possibility of low memory. Not a special
case for DOS.

>>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 ?

I meant the Protected mode DOS. It isn't a regular system, is it?
sO it is bound to have a very special and different approach.

>
>>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.

I disagree to a point. A good programmer should have good libraries
at his disposal that overcome those deficiensies. That alliviates
him of the necessity to know about the target system, if
not only for portability reasons.


>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" ?

These issues are none of my concern.


Erik van Linstee   |   Delft University of Technology   |   I'll be back ...