19.17c How can I suppress the dreaded MS-DOS ``Abort, Retry, Ignore?''
message?
19.23 How can I allocate arrays or structures bigger than 64K?
19.24 What does the error message ``DGROUP data allocation exceeds 64K''
mean, and what can I do about it? I thought that using large model meant
that I could use more than 64K of data!
19.29 How do I get an accurate error status return from system on MS-DOS?
19.40b How do I... Use BIOS calls? Write ISR's? Create TSR's?
19.40d What are ``near'' and ``far'' pointers?
MSDOS died some 20 years ago (more or less).
CAN WE GET RID OF THAT?
There is no word about windows/unix/Mac OS X and systems used TODAY...
And there are things like:
7.17 I've got 8 meg of memory in my PC. Why can I only seem to malloc
640K or so?
Theren't a single PC today that is shipped with less than 512K...
most are shipped with 1-4GB, my machine has 12GB. And YES: MSDOS is
dead.
Other answers are just wrong:
11.8: I don't understand why I can't use const values in initializers
and array dimensions, as in
const int n = 5;
int a[n];
The answer given is:
The const qualifier really means ``read-only''; an object so qualified
is a run-time object which cannot (normally) be assigned to. The value
of a const-qualified object is therefore not a constant expression in
the full sense of the term, and cannot be used for array dimensions,
case labels, and the like. (C is unlike C++ in this regard.) When you
need a true compile-time constant, use a preprocessor #define (or
perhaps an enum).
This is plain wrong. You CAN do this within a function in standard C.
That should be mentioned there. ANd NOT only with const but with any
variable of integer type.
Another is:
2.6: I came across some code that declared a structure like this:
struct name {
int namelen;
char namestr[1];
};
and then did some tricky allocation to make the namestr array act like
it had several elements, with the number recorded by namelen. How does
this work? Is it legal or portable?
The answer starts with:
It's not clear if it's legal or portable, but it is rather popular.
And after a page of ramblings comes to:
C99 introduces the concept of a flexible array member, which allows the
size of an array to be omitted if it is the last member in a structure,
thus providing a well-defined solution.
That should be at the beginning, and the whole answer must be changed
to reflect the fact that standard C accepts this!
jacob
The most recent edition of Schildt's "C: The Complete Reference" still
has near and far pointers. And, whether we like it or not, there's still
code out there that has those references in it, and someone might need
to port it.
> This is plain wrong. You CAN do this within a function in standard C.
> That should be mentioned there. ANd NOT only with const but with any
> variable of integer type.
It's not accurate for C99 or GNU C. The problem is that the question used
"array size" as an example of something which implicitly needed an "integer
constant", but of course, it's not anymore.
> That should be at the beginning, and the whole answer must be changed
> to reflect the fact that standard C accepts this!
"must" seems a little strong.
I agree that it would be great if Steve updated the FAQ. But, since I'm not
paying him to do it, I don't feel like I'm in a great position to impose
conditions or requirements.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Hmm... I had to get PeeCee with DOS to play DOOM (now widely ported, but the
DOS version came out first, and the other ports were missing features for a
long time). That was less than 17 years ago. And not exactly an obscure
application running on legacy hardware either.
Of course that machine did come preinstalled with a "win" line in its
autoexec.bat which in hindsight is recognizable as the beginning of the end
of DOS.
|>
|> CAN WE GET RID OF THAT?
|
|The most recent edition of Schildt's "C: The Complete Reference" still
|has near and far pointers. And, whether we like it or not, there's still
|code out there that has those references in it, and someone might need
|to port it.
But the F in FAQ stands for something, and it's not "all questions ever".
Killing off the ones that have become infrequent would make the list shorter,
and a shorter list will be read by more people.
|
|> This is plain wrong. You CAN do this within a function in standard C.
|> That should be mentioned there. ANd NOT only with const but with any
|> variable of integer type.
|
|It's not accurate for C99 or GNU C. The problem is that the question used
|"array size" as an example of something which implicitly needed an "integer
|constant", but of course, it's not anymore.
It still works if you assume it's outside of a function. Inside a function,
change it to a case label in a switch to make the same point.
--
Alan Curry
Is MSDOS really completely dead? I know it's not used much anymore,
and I agree that it probably doesn't deserve as much mention as it
gets in the FAQ, but I think it's still used in some niche
applications.
> There is no word about windows/unix/Mac OS X and systems used TODAY...
>
> And there are things like:
>
> 7.17 I've got 8 meg of memory in my PC. Why can I only seem to malloc
> 640K or so?
>
> Theren't a single PC today that is shipped with less than 512K...
You mean 512M, don't you?
> most are shipped with 1-4GB, my machine has 12GB. And YES: MSDOS is
> dead.
Yes, the numbers are dated, but the principle is unchanged. The
question and answer could both be improved by making them more
generic.
> Other answers are just wrong:
>
>
> 11.8: I don't understand why I can't use const values in initializers
> and array dimensions, as in
>
> const int n = 5;
> int a[n];
>
> The answer given is:
>
> The const qualifier really means ``read-only''; an object so qualified
> is a run-time object which cannot (normally) be assigned to. The value
> of a const-qualified object is therefore not a constant expression in
> the full sense of the term, and cannot be used for array dimensions,
> case labels, and the like. (C is unlike C++ in this regard.) When you
> need a true compile-time constant, use a preprocessor #define (or
> perhaps an enum).
>
>
> This is plain wrong. You CAN do this within a function in standard C.
> That should be mentioned there. ANd NOT only with const but with any
> variable of integer type.
Yes, in C99, which not all compilers fully support. (Yes, jacob, we
know ...)
I agree that that answer should be updated. Note, however, that n is
*still* not a constant expression. C99 allows it to be used as an
array dimension, but it still can't be used in case labels and a few
other contexts. And depending on the cleverness of the compiler, there
might be a difference between
const int n = 5;
int a[n]; /* This is a VLA */
and
enum { n = 5 };
int a[n]; /* This is not a VLA */
Even if C99 were universally available, I'd still tend to prefer the
latter, just to avoid runnng into any problems with the differences
between VLAs and non-VLAs.
> Another is:
> 2.6: I came across some code that declared a structure like this:
>
> struct name {
> int namelen;
> char namestr[1];
> };
>
> and then did some tricky allocation to make the namestr array act like
> it had several elements, with the number recorded by namelen. How does
> this work? Is it legal or portable?
>
> The answer starts with:
>
> It's not clear if it's legal or portable, but it is rather popular.
Which is still true. There's still plenty of code that uses the
struct hack, even though it's not needed in C99. The question begins,
"I came across some code ..."; this is something that programmers are
still likely to run into. (If nothing else, that answer would be
improved by mentioning the phrase "struct hack".)
> And after a page of ramblings comes to:
> C99 introduces the concept of a flexible array member, which allows
> the size of an array to be omitted if it is the last member in a
> structure, thus providing a well-defined solution.
>
> That should be at the beginning, and the whole answer must be changed
> to reflect the fact that standard C accepts this!
I agree that the FAQ needs some updating. It was last updated in
2005, and that wasn't a complete update. But keep in mind that
it's basically a one-man volunteer effort.
I don't pretend to speak for Steve Summit, but perhaps he'd be
interested in an project where we provide updated answers for
his approval. We've always been free to provide input by e-mail,
but that tends to be rather haphazard.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
I am personally aware of several extant MS-DOS installations, on several
separate sites. (In fact, I have one right here, about fifteen feet
away.) By "MS-DOS installations", of course, I am excluding mere
DOS-boxes and referring to the genuine article. Although MS-DOS is
certainly on its way out, it is not yet completely dead. There are some
good reasons for this, and some bad reasons too.
One of the bad reasons is that some people are unwilling to migrate to
newer systems because to do so would be to change a working system.
Whilst one can have a certain amount of sympathy for this view, it is
becoming more and more difficult to find support vendors for MS-DOS
systems, and that means that the "working system" is increasingly likely
to stop working. Better to grasp the bullet and migrate to something a
little more current.
One of the good reasons is that there are still some people who are
prepared to support those who still use MS-DOS; and to do so, one needs
at least one or two MS-DOS systems around the place, for testing purposes.
<snip>
>> Theren't a single PC today that is shipped with less than 512K...
>
> You mean 512M, don't you?
He probably does, yes. All except one of the (many) computers in my home
have less than 512MB memory, but none of the desktop machines have less
than 512KB.
Some people replace their machine every few months. To such people, an
FAQ that dealt with ancient dinosaurs with a mere 1GB of memory is
antiquated and needs replacing. Others either choose to, or have to,
make their machines last many years. To such people, an FAQ that dealt
only with the latest systems and hardware would be pointlessly faddish.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Why complain here? Why not complain to Steve Summit, the
author of the FAQ and the holder of its copyright? His contact
information is easily found in the -- wait for it -- FAQ ...
--
Eric Sosman
eso...@ieee-dot-org.invalid
No, MS DOS stopped shipping less than 10 years ago; it was still
underneath the hood of MS Windows 3.x, 95, 98, and ME.
> CAN WE GET RID OF THAT?
Not until MS DOS--and every bit of source code that _assumes_ it is
running on MS DOS even if it's actually under emulation--is completely
eradicated, and I suspect that'll be another few decades.
Every now and then, I find a useful piece of software for MS DOS that
needs to be ported to something modern; understanding "near" and "far"
pointers (and some other MS DOS oddities) is still useful. Even for
those of us who were there, a refresher is still handy.
OTOH, given this group's topicality Nazis, one could easily argue that
any references to _any_ particular OS should be stricken from the FAQ.
> There is no word about windows/unix/Mac OS X and systems used TODAY...
Indeed, and that could use some work, along with many other ares. If
you want it improved, I'm sure the maintainer would appreciate suggestions.
> And there are things like:
>
> 7.17 I've got 8 meg of memory in my PC. Why can I only seem to malloc
> 640K or so?
>
> Theren't a single PC today that is shipped with less than 512K...
> most are shipped with 1-4GB, my machine has 12GB. And YES: MSDOS is
> dead.
True, though there are plenty of folks working on embedded systems that
have even less memory than that; they're just not PCs.
> Other answers are just wrong:
>
> 11.8: I don't understand why I can't use const values in initializers
> and array dimensions, as in
>
> const int n = 5;
> int a[n];
>
> The answer given is:
>
> The const qualifier really means ``read-only''; an object so qualified
> is a run-time object which cannot (normally) be assigned to. The value
> of a const-qualified object is therefore not a constant expression in
> the full sense of the term, and cannot be used for array dimensions,
> case labels, and the like. (C is unlike C++ in this regard.) When you
> need a true compile-time constant, use a preprocessor #define (or
> perhaps an enum).
>
>
> This is plain wrong. You CAN do this within a function in standard C.
> That should be mentioned there. ANd NOT only with const but with any
> variable of integer type.
True, it's been a poor example since C99 added VLAs. Better would be a
switch/case statement, where a "const int" still can't be used.
> Another is:
> 2.6: I came across some code that declared a structure like this:
>
> struct name {
> int namelen;
> char namestr[1];
> };
>
> and then did some tricky allocation to make the namestr array act like
> it had several elements, with the number recorded by namelen. How does
> this work? Is it legal or portable?
>
> The answer starts with:
>
> It's not clear if it's legal or portable, but it is rather popular.
>
> And after a page of ramblings comes to:
> C99 introduces the concept of a flexible array member, which allows the
> size of an array to be omitted if it is the last member in a structure,
> thus providing a well-defined solution.
>
> That should be at the beginning, and the whole answer must be changed
> to reflect the fact that standard C accepts this!
Indeed. In general, as with the comment directly above, it appears that
the FAQ has not been updated to reflect the changes from C99 or, at
minimum, documented to say the answers only refer to C89.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
The F in FAQ stands for something, though.
That's a good point. However, I am pretty sure that the question has been
asked frequently. It may not be asked very often now, but the total number
of times it's come up is pretty large. :)
I am all for removing that from the FAQ when we have some reasonable proof
that people now reading the FAQ are never going to need to know. Otherwise,
the cost of leaving it there is small, and it has some potential value.
Also, more generally, the FAQ often includes Q which aren't A all that F,
but which are significant to people at the stage where they're likely to
be directed to the FAQ.
I would never doubt that. It is just near your 10 year old version of
gcc that you refuse to upgrade, and near a version of the C89 standard
that you also refuse to upgrade.
And behind that MSDOS system is a song of Jethro Tull:
"Living in the past".
Ahhh those were the times my friend. They will never come again.
The Win32 API of 95 is still there. So what? You would tell me that
MSDOS is still shipping today or what?
We are speaking of the FAQ of 2010, not the FAQ of 2000 or 1995. The
"F" means FREQUENT and I do not see much people around developing
ìn MSDOS. I could (maybe) understand if there were questions concerning
Unix development, or windows questions but MSDOS?
Just to argue the other side of this - let's remember that this is C
we're talking about here. An old-fashioned language that served us
well, but is, itself, basically obsolete. This is not to say that it
isn't still used or anything like that - but the fact is that very
little new development, on current/new OSes and platforms, is done in C.
Even C++ is considered "old" by most people these days.
Further, let's stipulate that both DOS and Unix are also considered
"old". Again, this doesn't mean that they aren't both in use and even
developed for, in various niche application domains.
So, what this all leads to is that it makes sense for the C FAQ to
contain a lot of content about DOS and Unix, since a lot of what makes C
what it is (warts and all) is tied to those OSes.
<snip DOS questions>
> MSDOS died some 20 years ago (more or less).
Nope. MS-DOS is still around, albeit as a lurker beneath WIndows. Yes,
huge numbers of people still use Windows 98/ME/2000/XP, all of which
provided DOS mode/prompt. I don't know about Vista and 7, but while
Vista died in infancy, 7 is yet to be widely adopted. Reluctance to
change a working system and learn new interfaces, and cost of
migrating are some important factors for why these "legacy" systems
are still widely used. Much of the same reasoning applies to why Turbo
C is still being widely used for teaching introductory C.
But I haven't seen a single "pure" MS-DOS installation since atleast a
decade.
But the pertinent question is not if MS-DOS is dead or not, but how
much C programming is still being done under DOS or DOS mode. As I
said above, many introductory C classes still use the Turbo C/DOS
prompt combine due to reasons given above. Some popularly used C
"textbooks" still make heavy references to, and contain instructions
for, DOS, making the new student think he must start with Turbo C/DOS.
Other than this I guess that DOS programming is still being actively
done only by DOS enthusiasts (of which there're still very many), and
perhaps in certain embedded areas.
So I guess it'd be cleaner if the DOS FAQs were moved into a separate
"DOS" section of the FAQ. Though I wouldn't like to see them removed
altogether, having them all collected under a single link would make
the rest of FAQ cleaner and more up-to-date seeming for the rest of
us.
<snip>
Not MSDOS, but you can get freedos. (I run dos applications in dosemu here).
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Actually, IIRC my gcc version is only 8 years old and is installed on a
Linux machine, not my DOS machine. I have a copy of the C99 Standard, of
course (also on a Linux machine, and I have a number of drafts of
revisions to the Standard published since 1999). And neither of those
facts has anything whatsoever to do with my MS-DOS installation, which I
actually keep around precisely because some of my users do have MS-DOS
installations and I like to be able to test code using their OS. Is that
okay with you, or should I tell them Jacob Navia says to get lost?
> And behind that MSDOS system is a song of Jethro Tull:
>
> "Living in the past".
Good song. "Now there's revolution, but they don't know what they're
fighting", which we might render as "changing for the sake of change",
which is normally a very silly idea.
> Ahhh those were the times my friend. They will never come again.
It is (mostly) because those times haven't yet gone that I keep this
antique heap of junk lying around instead of taking it down to the tip.
No, we are speaking of the FAQ of the C language.
> The
> "F" means FREQUENT and I do not see much people around developing
> ìn MSDOS.
Yes, I know - but it seems from past discussions with you that you don't
get out much.
> I could (maybe) understand if there were questions concerning
> Unix development, or windows questions but MSDOS?
If there are frequently asked questions about Unix or Windows (or indeed
OS390 or MacOS or Linux or FreeBSD or whatever), let us by all means add
them to the FAQ. I see no reason to take questions away, though. Like
the yard lengths of parcel string, the little collections of twisted
plastic cable-ties, and the blunt pencils that litter kitchen drawers
all over the world, they may come in handy one day.
I second this. MS-DOS has terribly limited networking support,
almost no support for modern filesystems, primitive threading
and IIRC, no memory protection. (Actually, the DOS functions
were so slow that you /had/ to use MMIO directly to draw graphics
at any decent speed.)
In any case, I do not believe that the memory limitations
discussed in the FAQ are at all frequently met. In fact, I
doubt that most C programmers encounter /any/ memory limits
on desktop PC's anymore. Certainly not when they're learning
and need a FAQ.
You really should do a BIOS update on your PC one day... the last time I
did, within the last couple of years, it involved booting to DOS using
an image provided by the computer vendor.
> And behind that MSDOS system is a song of Jethro Tull:
>
> "Living in the past".
>
> Ahhh those were the times my friend. They will never come again.
The past isn't as dead as you think.
Although I happen to agree that a lot of mention of DOS isn't really
needed in the FAQ these days.
--
Flash Gordon
Ask in a Windows group. That DOS prompt has in 2000 and above is NOT
running MS DOS or anything like it.
<snip>
> Vista died in infancy, 7 is yet to be widely adopted. Reluctance to
> change a working system and learn new interfaces, and cost of
> migrating are some important factors for why these "legacy" systems
> are still widely used. Much of the same reasoning applies to why Turbo
> C is still being widely used for teaching introductory C.
Well, the courses should move on to something more recent, and although
DOS is still used, it is gradually disappearing.
> But I haven't seen a single "pure" MS-DOS installation since atleast a
> decade.
>
> But the pertinent question is not if MS-DOS is dead or not, but how
> much C programming is still being done under DOS or DOS mode. As I
> said above, many introductory C classes still use the Turbo C/DOS
> prompt combine due to reasons given above. Some popularly used C
> "textbooks" still make heavy references to, and contain instructions
> for, DOS, making the new student think he must start with Turbo C/DOS.
Any introductory courses using it need serious updating.
> Other than this I guess that DOS programming is still being actively
> done only by DOS enthusiasts (of which there're still very many), and
> perhaps in certain embedded areas.
DOS has been dropping out of the embedded market for a long time. I
don't know how much (if at all) it is still used.
> So I guess it'd be cleaner if the DOS FAQs were moved into a separate
> "DOS" section of the FAQ. Though I wouldn't like to see them removed
> altogether, having them all collected under a single link would make
> the rest of FAQ cleaner and more up-to-date seeming for the rest of
> us.
A lot of the stuff, if re-cast, could still be relevant.
--
Flash Gordon
<snip>
> In any case, I do not believe that the memory limitations
> discussed in the FAQ are at all frequently met. In fact, I
> doubt that most C programmers encounter /any/ memory limits
> on desktop PC's anymore. Certainly not when they're learning
> and need a FAQ.
The specific values mentioned in the FAQ may be no longer relevant, but
we *do* have learners posting code which attempts to allocate local
variable which are so large the allocation fails causing the program to
crash. So there *are* still limits, and learners *do* still hit them!
We also have had people post things similar to, "...but I've got 4GM of
RAM!" when this is pointed out.
--
Flash Gordon
:-)
I recall in 1968 folks on their initial FORTRAN course doing:
DIMENSION X(1000,1000)
This was on a 32k 7094. But then why shouldn't they? No-one had told
them not to.
--
Tim
"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"
Bill of Rights 1689
<snip>
> > MSDOS died some 20 years ago (more or less).
>
> Nope. MS-DOS is still around, albeit as a lurker beneath WIndows.
not really. There's a CLI that looks a lot like DOS but it isn't
really DOS
>Yes,
> huge numbers of people still use Windows 98/ME/2000/XP, all of which
> provided DOS mode/prompt. I don't know about Vista and 7, but while
> Vista died in infancy, 7 is yet to be widely adopted.
eek! I'm using Vista. Admittedly I'm the only person in the world who
*likes* Vista, but still... Vista still has DOS-like CLI.
I've heard it said that W7 is pretty much the Vista OS but with some
cleanup to the GUI. The security is supposed to be less intrusive (I
*like* intrusive)
No, Win7 is a -lot- faster. It's prettier and easier to use and
all that, but there's clearly been a lot of work under the hood.
(Though, they still won't let you accept RDP connections with a
home version. Silly Microsoft, I guess I'll stick with Linux.)
Andrew
Yes, but that is not pertinent to this discussion is it? The NT family
emulates the DOS interface, but they still provide it, allowing almost
all programs to work, that'd run on native DOS.
In effect, they do "provide" DOS right upto Vista, though my
understanding is that Windows 7 has finally dropped support for it.
So potentially, all users of versions of Windows up to XP (and I think
Vista too), *can* use DOS programs and do a subset of DOS programming,
which is a *huge* user base.
> <snip>
>
> > Vista died in infancy, 7 is yet to be widely adopted. Reluctance to
> > change a working system and learn new interfaces, and cost of
> > migrating are some important factors for why these "legacy" systems
> > are still widely used. Much of the same reasoning applies to why Turbo
> > C is still being widely used for teaching introductory C.
>
> Well, the courses should move on to something more recent, and although
> DOS is still used, it is gradually disappearing.
>
> > But I haven't seen a single "pure" MS-DOS installation since atleast a
> > decade.
> >
> > But the pertinent question is not if MS-DOS is dead or not, but how
> > much C programming is still being done under DOS or DOS mode. As I
> > said above, many introductory C classes still use the Turbo C/DOS
> > prompt combine due to reasons given above. Some popularly used C
> > "textbooks" still make heavy references to, and contain instructions
> > for, DOS, making the new student think he must start with Turbo C/DOS.
>
> Any introductory courses using it need serious updating.
Well, to be fair, top of the notch places have moved on to using some
version of Visual C++ and gcc under Linux, but the seedier
establishments still use old installs of Windows 98/DOS combo and
Turbo C/C++, since, I guess, they prefer saving the money they'd
otherwise've to shell out for Windows and Visual Studio licenses.
But their numbers are dropping. DOS might completely disappear in
about 5-10 years, except for hobbyists and other peculiar instances.
<snip>
> A lot of the stuff, if re-cast, could still be relevant.
Yes, but since it's a volunteer effort by Mr. Summit, it'd be mean to
carp too much without actually lending a hand. It's still a very
useful resource, but it used to be periodically posted to clc. I
wonder why that has been discontinued. A weekly post of it might bring
it to the attention of newbies and lurkers more effectively than
mentioning it only in occasional replies.
The first time I met a computer with a soldering iron in my hand was in
1963. I was a full grown Customer Service Engineer for the company.
For me that was the beginning of "now" and before that is "past".
MSDOS and CP/M are still very much "now" to me.
The first digital computer I saw working was a CDC 160A in 1962. It's job
was sending large amounts of data over telephone lines from Fairbanks,
Alaska to Sunnyvale, California, 24/7. It had an operator console but no
operator. It was programmed to do its job without intervention. That's the
one that got me "hooked" on computers.
That's all "past" for you but I feel no need to "get over it".
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
>MSDOS and CP/M are still very much "now" to me.
MSDOS and CP/M seem older than they are because they were out of date
when they were designed.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
> The first time I met a computer with a soldering iron in my hand was in
> 1963. I was a full grown Customer Service Engineer for the company.
>
> For me that was the beginning of "now" and before that is "past".
>
> MSDOS and CP/M are still very much "now" to me.
> That's all "past" for you but I feel no need to "get over it".
The MSDOS stuff seems ancient now (and it was new for me too at one time).
There's no reason now to give such prominence to the problems of this
particular 1980s processor (8086), rather than a dozen others.
--
Bartc
The target of CP/M was the Intel 8080A. In what way was CP/M out of date in
1979?
>> MSDOS died some 20 years ago (more or less).
>
> Nope. MS-DOS is still around, albeit as a lurker beneath WIndows. Yes,
> huge numbers of people still use Windows 98/ME/2000/XP, all of which
> provided DOS mode/prompt.
95/98/ME provide an MS-DOS prompt (and mode). 2K/XP/etc don't.
2K/XP/etc provide a command interpreter (cmd.exe), which is mostly
compatible with MS-DOS' command.com, and they provide several command-line
utilities which are are mostly compatible with MS-DOS utilities of the
same name.
However, the similarity ends there. While cmd.exe and the utilities are
compatible with various MS-DOS programs, they are *not* MS-DOS programs,
but 32-bit Windows executables.
2K/XP/etc do provide support (via NTVDM) for running MS-DOS and Win16
programs (although not on 64-bit systems), but this is quite unrelated to
the console or the command prompt.
Actually it is, since you claimed it is still lurking beneath Windows.
> The NT family
> emulates the DOS interface, but they still provide it, allowing almost
> all programs to work, that'd run on native DOS.
>
> In effect, they do "provide" DOS right upto Vista, though my
> understanding is that Windows 7 has finally dropped support for it.
Things have been gradually stopping working since before Windows 7.
Hell, not everything worked in a DOS shell under Win95!
> So potentially, all users of versions of Windows up to XP (and I think
> Vista too), *can* use DOS programs and do a subset of DOS programming,
> which is a *huge* user base.
Some is not all, and your statement about DOS lurking under Windows 2000
is still false.
<snip>
>>> But the pertinent question is not if MS-DOS is dead or not, but how
>>> much C programming is still being done under DOS or DOS mode. As I
>>> said above, many introductory C classes still use the Turbo C/DOS
>>> prompt combine due to reasons given above. Some popularly used C
>>> "textbooks" still make heavy references to, and contain instructions
>>> for, DOS, making the new student think he must start with Turbo C/DOS.
>> Any introductory courses using it need serious updating.
>
> Well, to be fair, top of the notch places have moved on to using some
> version of Visual C++ and gcc under Linux, but the seedier
> establishments still use old installs of Windows 98/DOS combo and
> Turbo C/C++, since, I guess, they prefer saving the money they'd
> otherwise've to shell out for Windows and Visual Studio licenses.
Or they could shell out the full cost of a free CentOS install...
They may well still be around, but they are doing their students a
serious disservice.
> But their numbers are dropping. DOS might completely disappear in
> about 5-10 years, except for hobbyists and other peculiar instances.
>
> <snip>
>
>> A lot of the stuff, if re-cast, could still be relevant.
>
> Yes, but since it's a volunteer effort by Mr. Summit, it'd be mean to
> carp too much without actually lending a hand.
I'm fully aware of that, and I was not carping.
> It's still a very
> useful resource, but it used to be periodically posted to clc. I
> wonder why that has been discontinued. A weekly post of it might bring
> it to the attention of newbies and lurkers more effectively than
> mentioning it only in occasional replies.
There is meant to be an automated monthly posting, but I don't think it
is working reliably.
--
Flash Gordon
Andrew, Idunno. I have experience with this product, as my girlfriend
uses it (ergo I do). Why does a software component need a time machine?
--
I may be wrong, since it's been a while since I've used Windows XP,
but last time I checked, they do provide COMMAND.COM and most of the
other standard DOS utilities. Of course, they don't run on top of DOS,
but NTVDM, but I don't see how that makes much of a difference from a
programmer's point of view, as long as he confines himself to
application programming and doesn't do things like switching to pmode
and so on.
I can very well run Turbo C/C++ and other DOS products in XP, so when
considering the potential DOS user base, IMO we'll have to consider
those using XP too, not just up to 98/ME.
> >>> But the pertinent question is not if MS-DOS is dead or not, but how
> >>> much C programming is still being done under DOS or DOS mode. As I
> >>> said above, many introductory C classes still use the Turbo C/DOS
> >>> prompt combine due to reasons given above. Some popularly used C
> >>> "textbooks" still make heavy references to, and contain instructions
> >>> for, DOS, making the new student think he must start with Turbo C/DOS.
> >> Any introductory courses using it need serious updating.
> >
> > Well, to be fair, top of the notch places have moved on to using some
> > version of Visual C++ and gcc under Linux, but the seedier
> > establishments still use old installs of Windows 98/DOS combo and
> > Turbo C/C++, since, I guess, they prefer saving the money they'd
> > otherwise've to shell out for Windows and Visual Studio licenses.
>
> Or they could shell out the full cost of a free CentOS install...
Funny. At the financial and technical level at which these places are
run, no one there would even know *what* was CentOS, let alone have
the money/motivation to hire someone familiar with UNIX to install and
manage the systems.
> They may well still be around, but they are doing their students a
> serious disservice.
Well, if the aim in just to teach standard C, then I guess DJGPP would
be as good as any other compiler. After all, it implements much more
C99 than even the latest MS Visual C++.
One good side-effect of using DOS would be to introduce students to a
CLI. It's shocking how many people who've exclusively used only
Windows don't even know about the existence of text interfaces.
<snip>
> The F in FAQ stands for something, though.
So, all we need do is update the definition of FAQ to "Formerly Asked
Questions"...
> This document shows its age. I remember complaining here some years ago
> about this MSDOS questions but they are still there:
>
> [...]
>
> MSDOS died some 20 years ago (more or less).
>
> CAN WE GET RID OF THAT?
>
> There is no word about windows/unix/Mac OS X and systems used TODAY...
It should be obvious to everyone that Jacob is 50% troll.
Um, no. Jacob, who's confrontational manner I do not approve of, has
posted more useful information to comp.lang.c in the last 2 or 3 years
than almost anyone else. You, however, have posted none.
>Flash Gordon wrote:
>> santosh wrote:
>> > jacob navia wrote:
>> >> This document shows its age. I remember complaining here some years ago
>> >> about this MSDOS questions but they are still there:
>> >
>> > <snip DOS questions>
>> >
>> >> MSDOS died some 20 years ago (more or less).
>> >
>> > Nope. MS-DOS is still around, albeit as a lurker beneath WIndows. Yes,
>> > huge numbers of people still use Windows 98/ME/2000/XP, all of which
>> > provided DOS mode/prompt. I don't know about Vista and 7, but while
>>
>> Ask in a Windows group. That DOS prompt has in 2000 and above is NOT
>> running MS DOS or anything like it.
>
>Yes, but that is not pertinent to this discussion is it? The NT family
>emulates the DOS interface, but they still provide it, allowing almost
>all programs to work, that'd run on native DOS.
>
>In effect, they do "provide" DOS right upto Vista, though my
>understanding is that Windows 7 has finally dropped support for it.
Win7 64 bit (as well as Vista 64 bit) will not run 16bit DOS programs,
but they will still run most 32bit programs. There is a utility
called DOSBox which will run 16 bit DOS executables on Win7 and Vista
64 bit.
>
>So potentially, all users of versions of Windows up to XP (and I think
>Vista too), *can* use DOS programs and do a subset of DOS programming,
>which is a *huge* user base.
(snip)
--
Bob Doherty
Strictly speaking, that he's posted useful information doesn't disprove
the claim that he is 50% troll. What's significant is that he posts a LOT
of useful information, and a very small amount of confrontational stuff,
so even if we call all the confrontational stuff "trolling", I'd say he's
at most 10% troll.
He remains one of the compelling arguments for figuring out how to score
articles UP in my scoring-based newsreader. :)
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
> MSDOS died some 20 years ago (more or less).
Ouch.. we are getting older!
Even if not a FAQ these days, DOS is still in use. Students might use
e.g. FreeDOS for embedded programming.
--
Tor <echo bwz...@wvtqvm.vw | tr i-za-h a-z>
Remember that C is used in other contexts than writing PC software.
The 8051 has 256 bytes of ram and the options for programming it are
Assembly and C... I prefer C :)
Also, an aside regarding DOS... the book "Linux Assembly Language
Programming" uses some DOS examples and code. I forget exactly why, but
IIRC it had something to do with real vs protected mode for the i386?
--
Ted DeLoggio
> Remember that C is used in other contexts than writing PC software.
>
> The 8051 has 256 bytes of ram and the options for programming it are
> Assembly and C... I prefer C :)
True, but its pretty hard to see the relevance of that to the *DOS-
specific* parts. I've never used an 256 byte embedded system that
prints "Abort, Retry, Ignore" as an error, or that had the concept of
"TSR programs".
I don't know whether to say this or not but ... it's interesting to me
that the FAQ contains answers to so many non-standard system-
specific. It appears, contrary to the assertions of some, that at the
time the FAQ was being written, c.l.c'ers did not consider their
newsgroup to be off-limits to people asking system-specific
questions.
In fact, it would seem, that these were among the more frequently
asked questions, and rather than tell them asker to "ask in a system
specific group", a list of useful answers was created and
distributed. Of course, the non-existence of such system specific
groups may have had a bearing on this....
Uh, no. I was there, and we ALWAYS thought those were off-topic. I've
been using Usenet since before the Great Renaming.
The point of a FAQ is not necessarily to be 100% topical, but to answer
questions which come up a lot to reduce traffic to the group. Since the
purpose of a FAQ is to *prevent* discussion of an issue, the presence of
an off-topic issue in a FAQ does not prove that people would welcome
discussion of that issue!
Exactly.
All this reactions have something in common:
MSDOS is surely not dead in the mind of some people here. They
are still in those times, and a FAQ of those times looks very
modern to them.
With age, some people loose the ability to realize change
and adapting to new stuff. They close themselves from the present
and prefer living in some glorious past, long gone but still
present in their minds.
I have mixed feeling when I see them. There is (of course) the
fear that I could be like them in the future, there is the pity
looking at them and their endless remembrance of times long gone,
and their lost future.
Those people have completely lost the future as a tense: they
never speak about it. Any change is a challenge, any change
is a threat and they perceive it as such.
Look in this group:
Any change to C is perceived as a threat. The overwhelming reaction
to a proposal of getting rid of MSDOS in the FAQ proves beyond
any doubt where those people are living.
That is why I am so despised in this group, now it is at least
clearer. I want to change stuff, and I try to project myself into
the future, and (worst) I even speak about the future of C.
Everybody (with a few exceptions) sees C as a thing of the past,
joined by a few nostalgic old C programmers that live in 1989,
with MSDOS and Turboc.
The fact that those times were TWENTY years ago doesn't bother them.
They want to STAY there, in their untouched glorious past.
> Uh, no. I was there, and we ALWAYS thought those were off-topic.
It'd be interesting to see contemporary posts that backs that up.
Which is not to say that you're being dishonest, just that
contemporary threads would be interesting. I have a tendency to
suspect sentences that being ascribe motives that don't use first
person singular.
Arbitrarily jumping back to 1992 on google.groups (around post
130000), I took entirely unscientific sample of 10 threads with titles
that looked system specific, which had more than one article, and did
not ask questions in the FAQ. Titles were:
1. "Curses eats the right bottom corner? (ISC SysV3.2)"
2. "Vax C problem"
3. "C socket programming"
4. "Help! Need to detect the CRT's vertical retrace signal"
5. "Graphics.h"
6. "HELP! How to do VGA graphics screen dumps onto an IBM Proprinter
II"
7. "Timing problems on 486-33--delay() function in Turbo C"
8. "HELP Menus with Mice on PC with Microsoft C"
9. "Clear screen"
19. "Borland Turbo C++ and memory problem at startup"
In only two of these threads [(3) and (4)] did anyone redirect the
questioner to another group, or dismiss them as off-topic, and even in
those cases someone else supplied a full or partial answer. In the
vast majority of cases, the people following up were informative,
courteous and helpful.
> The point of a FAQ is not necessarily to be 100% topical, but to answer
> questions which come up a lot to reduce traffic to the group.
Personally, as a "form defines function" kind of guy, when theoretical
notions of topicality clash with "questions which come up a lot", I'm
on the side of "questions which come up a lot".
lolwut?
MS-DOS has been irrelevant to my programming experience since about 1992,
when I finally ditched a heinously awful consulting gig that depended on
DOS overlays. I have never looked back.
> Those people have completely lost the future as a tense: they
> never speak about it. Any change is a challenge, any change
> is a threat and they perceive it as such.
Again, lolwut?
> Any change to C is perceived as a threat.
This is not true. We've got several of the people you view as perceiving
any change as a threat advocating new syntax within the last week or so (The
suggestion to use {} as an idiom for "initialized all to zeroes"). I've
written up and proposed changes to C.
Don't mistake my disagreement with you about the ideal nature of a "container
library" for a general opposition to change in C.
> The overwhelming reaction
> to a proposal of getting rid of MSDOS in the FAQ proves beyond
> any doubt where those people are living.
Actually, no. It proves that I don't like to throw away data until long,
long, after it's ceased being useful. Not just because it's no longer
a major priority for most people.
> That is why I am so despised in this group, now it is at least
> clearer. I want to change stuff, and I try to project myself into
> the future, and (worst) I even speak about the future of C.
None of this has ANYTHING to do with disliking you. I dislike you because
you make up stories about how other people think, and insist that these things
you've invented are what they think or feel, and ignore anything they tell
you. That's a pretty nasty thing to do to people, and I don't like it.
I don't think, though, that it would be fair to say that I "despise" you.
I think you're a valuable contributor with a lot of good insight into C,
and I would love it if more people contemplating various additions to C
were aware of some of your work on lcc-win.
> Everybody (with a few exceptions) sees C as a thing of the past,
> joined by a few nostalgic old C programmers that live in 1989,
> with MSDOS and Turboc.
Really, no. Most of the code I'm writing these days probably has unambiguous
dependencies on APIs that hadn't even been CONCEIVED of in 2000. Now,
I do admit, that's about a decade ago... But that's because we have
requirements to continue supporting extremely old host systems for some
of our stuff. (But not MS-DOS old, just "early 2000s" old.)
Meanwhile, I'm also spending a fair amount of my programming time doing
Ruby on Rails, and working on an iPhone app as a hobby. This is not 1989,
and no one thinks it is.
And if you want people to like you more, you might try not asserting such
ridiculous things about them, hmm?
That's not so useful. It would be more interesting to look at the discussions
of topicality per se. In the early 90s, a lot of people gave up on trying
to make the group useful -- that's one of the reasons clcm was formed, because
clc had been overwhelmed by noise.
> Personally, as a "form defines function" kind of guy, when theoretical
> notions of topicality clash with "questions which come up a lot", I'm
> on the side of "questions which come up a lot".
I'm okay with "questions which come up a lot, or used to come up a lot and
would be really hard to research nowadays because all the sources are
pre-Google". :)
> That's not so useful. It would be more interesting to look at the discussions
> of topicality per se.
That's not so useful. The only people who discuss topicality per se
are those who
a) think topicality is topical
b) find topicality discussions interesting.
That tends to mean the discussions are between the hardliners on both
sides, so your sample is intrinsically skewed. It's the same reason
that political discussions on the internet tend to attract drooling
morons from both sides -- people with moderate opinions frequently
have better things to do.
You don't get a balanced idea of a population by listening to its most
vociferous. The best lack all conviction, where the worst are full of
passionate intensity, as the poet wrote.
>On 2010-02-10, gwowen <gwo...@gmail.com> wrote:
>> I don't know whether to say this or not but ... it's interesting to me
>> that the FAQ contains answers to so many non-standard system-
>> specific. It appears, contrary to the assertions of some, that at the
>> time the FAQ was being written, c.l.c'ers did not consider their
>> newsgroup to be off-limits to people asking system-specific
>> questions.
>
>Uh, no. I was there, and we ALWAYS thought those were off-topic. I've
>been using Usenet since before the Great Renaming.
Would "we" be you and your tapeworm, or you and people who agree
with you? I certainly don't agree, and I also have been using
Usenet well before the great renaming.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.
>> Any change to C is perceived as a threat.
>
> This is not true. We've got several of the people you view as perceiving
> any change as a threat advocating new syntax within the last week or so
> (The
> suggestion to use {} as an idiom for "initialized all to zeroes"). I've
> written up and proposed changes to C.
{} instead of {0}? Yeah, that's a big change.
>> The overwhelming reaction
>> to a proposal of getting rid of MSDOS in the FAQ proves beyond
>> any doubt where those people are living.
>
> Actually, no. It proves that I don't like to throw away data until long,
> long, after it's ceased being useful. Not just because it's no longer
> a major priority for most people.
Anyone who sees the MSDOS stuff in the FAQ is going to wonder how old,
out-of-date, irrelevant and unreliable the rest of it is going to be.
The C FAQ is obviously just a static file, but if it was a dynamic resource,
the MSDOS queries would have long vanished into the archive section.
--
Bartc
That apparently doesn't seem to worry anyone here.
No, it's a rather small change. Nobody said it was a big one.
jacob, however, claimed that "*Any* change to C is perceived as a
threat" (emphasis added). To refute such an absolute statement,
it's sufficient to present a counterexample. I'm sure I'm one of
the people who jacob claims perceives any change to C as a threat,
but I recently proposed a change to C.
If jacob wants to make more reasonable statements, we can have a
reasonable discussion. In particular, jacob is welcome to stop
making claims about other people's motivations; he makes many such
claims, and I don't remember one of them being correct.
>>> The overwhelming reaction
>>> to a proposal of getting rid of MSDOS in the FAQ proves beyond
>>> any doubt where those people are living.
>>
>> Actually, no. It proves that I don't like to throw away data until long,
>> long, after it's ceased being useful. Not just because it's no longer
>> a major priority for most people.
>
> Anyone who sees the MSDOS stuff in the FAQ is going to wonder how old,
> out-of-date, irrelevant and unreliable the rest of it is going to be.
>
> The C FAQ is obviously just a static file, but if it was a dynamic
> resource, the MSDOS queries would have long vanished into the archive
> section.
Agreed, mostly. Let me emphasize that the FAQ is a one-man volunteer
project, and Steve Summit is under no real obligation to spend time
on it. Perhaps people could volunteer to spend some of their own
time helping out. Pointing out problems is valuable, but offering
fixes for them is much better.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Just what reaction are you referring to?
I agree that the MSDOS material in the FAQ is largely obsolete.
I think it's of historical interest, so I wouldn't want it deleted
altogether, but it could be moved to an archive section. And some,
but not all, of it could be made relevant just by tweaking a few
numbers. (There's plenty of room on the web; keeping the MSDOS
material doesn't mean there's less space for other information.)
I think most of the negative reaction was to your claim that
MSDOS is dead. That's just not true. It's *mostly* dead,
and has been almost entirely superseded by other things,
but it's still in use here and there.
This kind of thing seems to happen a lot. You make a basically
reasonable proposal, one that could trigger an interesting
discussion, but you combine it with an over-the-top claim that's easy
to refute. Naturally, people jump on the over-the-top claim because
it's easy, and your reasonable proposal gets lost in the noise.
For our purposes, it doesn't really matter whether MSDOS is
completely dead or just mostly dead. You're right, MSDOS gets too
much emphasis in the FAQ. You didn't need to make the false claim
that it's dead to support that.
> That is why I am so despised in this group, now it is at least
> clearer. I want to change stuff, and I try to project myself into
> the future, and (worst) I even speak about the future of C.
I can't speak for anyone else, but I don't despise you. I do find
you annoying at times, especially when you make claims about other
people's motivations and get them so spectactularly wrong.
> Everybody (with a few exceptions) sees C as a thing of the past,
> joined by a few nostalgic old C programmers that live in 1989,
> with MSDOS and Turboc.
>
> The fact that those times were TWENTY years ago doesn't bother them.
>
> They want to STAY there, in their untouched glorious past.
Nope.
You have a point, there.
There's a tension between wanting to get the opinions of people who at
least comprehend the issue, and wanting to get the opinions of people who
aren't fanatical.
Huh! Well, that's interesting. Maybe we need a poll.
I know that the first time I posted a system-specific question to clc, I
got a very polite note letting me know I would need a system-specific group,
and also an explanation of why.
... via email, I think. Interesting.
On 02/07/2010 08:10 AM, jacob navia wrote:
> This document shows its age. I remember complaining here some years ago
> about this MSDOS questions but they are still there:
>
> 19.17c How can I suppress the dreaded MS-DOS ``Abort, Retry, Ignore?''
> message?
>
> 19.23 How can I allocate arrays or structures bigger than 64K?
>
> 19.24 What does the error message ``DGROUP data allocation exceeds 64K''
> mean, and what can I do about it? I thought that using large model meant
> that I could use more than 64K of data!
>
> 19.29 How do I get an accurate error status return from system on MS-DOS?
>
> 19.40b How do I... Use BIOS calls? Write ISR's? Create TSR's?
>
> 19.40d What are ``near'' and ``far'' pointers?
>
> MSDOS died some 20 years ago (more or less).
>
> CAN WE GET RID OF THAT?
>
> There is no word about windows/unix/Mac OS X and systems used TODAY...
>
> And there are things like:
>
> 7.17 I've got 8 meg of memory in my PC. Why can I only seem to malloc
> 640K or so?
>
> Theren't a single PC today that is shipped with less than 512K...
> most are shipped with 1-4GB, my machine has 12GB. And YES: MSDOS is
> dead.
>
>
> Other answers are just wrong:
>
>
> 11.8: I don't understand why I can't use const values in initializers
> and array dimensions, as in
>
> const int n = 5;
> int a[n];
>
> The answer given is:
>
> The const qualifier really means ``read-only''; an object so qualified
> is a run-time object which cannot (normally) be assigned to. The value
> of a const-qualified object is therefore not a constant expression in
> the full sense of the term, and cannot be used for array dimensions,
> case labels, and the like. (C is unlike C++ in this regard.) When you
> need a true compile-time constant, use a preprocessor #define (or
> perhaps an enum).
>
>
> This is plain wrong. You CAN do this within a function in standard C.
> That should be mentioned there. ANd NOT only with const but with any
> variable of integer type.
>
> Another is:
> 2.6: I came across some code that declared a structure like this:
>
> struct name {
> int namelen;
> char namestr[1];
> };
>
> and then did some tricky allocation to make the namestr array act like
> it had several elements, with the number recorded by namelen. How does
> this work? Is it legal or portable?
>
> The answer starts with:
>
> It's not clear if it's legal or portable, but it is rather popular.
>
> And after a page of ramblings comes to:
> C99 introduces the concept of a flexible array member, which allows the
> size of an array to be omitted if it is the last member in a structure,
> thus providing a well-defined solution.
>
> That should be at the beginning, and the whole answer must be changed
> to reflect the fact that standard C accepts this!
>
> jacob
>
>
The Pharoah's are all dead, but we still treasure their mummified bodies.
DOS isn't quite dead. It lives on in its mummyfied form. In Freedos,
DosEMU and DosBox.
Yes, largely irrelevant, but not completely. I did recently do some
minor bug fixes on an old DOS program used in a Pharmaceutical
manufacturing company. I dont see much point removing it, apart from
saving a few bytes
Yes. You, and all "regs" here, still treasure the mummified body of
MSDOS.
The catastrophic impression that a FAQ fulll of MSDOS references makes
in people reading it ("Wow, this document is at least 20 years old,
how can I trust what it says?") doesn't matter to you since you
(and your friends) are more interested in treasuring mummified bodies
than in actually keep current with the transformation of the data processing
industry since MSDOS.
From all the things I objected you picked up (like all your friends)
the one you love the most:
MSDOS.
As some people age, they are more and more unable to realize that
they aren't living in their youth, that things change and must be changed.
They prefer to relive the good old days of their past. Your reaction (and
the reaction of your frieds) shows where you are living.
The 1989 standard, Turboc (that will be still recommended) and MSDOS.
"Those were the days, my friend
They will never come back again..."
I can't help you. I just hope that I will avoid becoming like you
in the future.
try reviving the clc wiki? (it seemed pretty moribund last time I
looked).
Such as yourself.
--
Tim
"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"
Bill of Rights 1689
Unless I'm much mistaken, nearly everyone in this thread have
suggested or approved of the idea of moving all the DOS questions into
a special "archive" section of the FAQ. So your statements above seem
to be gross exaggerations.
>On 2010-02-10, Richard Harter <c...@tiac.net> wrote:
>> Would "we" be you and your tapeworm, or you and people who agree
>> with you? I certainly don't agree, and I also have been using
>> Usenet well before the great renaming.
>
>Huh! Well, that's interesting. Maybe we need a poll.
Who would we poll? At a minimum your "we" referred to people
who active at the time of the clc FAQ. Call that group 1. But
then you went on to qualify it with being active before the great
renaming. Call those hoary veterans group 2. Would we poll
group 1 or group 2? What about all of the long gone? How do we
poll them? (This is known as cheap sarcasm.)
The nub is that your original wording implied a consensus that
has never existed.
>
>I know that the first time I posted a system-specific question to clc, I
>got a very polite note letting me know I would need a system-specific group,
>and also an explanation of why.
>
>... via email, I think. Interesting.
Once upon a time net etiquette dictated email responses for
communicating peripheral corrections such as spelling errors,
errors in grammar, tangential errors of fact, topicality
complaints, and other such trivia. It was a well founded rule.
Such trivia impacts the smooth flow of discussion. Sadly the old
machinery for orderly discourse no longer works.
> Remember that C is used in other contexts than writing PC software.
>
> The 8051 has 256 bytes of ram
That's the 8052. The 8051 has 128 bytes.
> and the options for programming it are Assembly and C...
And Forth. :-)
Andrew.
>
> Anyone who sees the MSDOS stuff in the FAQ is going to wonder how old,
> out-of-date, irrelevant and unreliable the rest of it is going to be.
What if they also saw questions about using C with more modern operating
systems? Then what would they all wonder?
If you think the FAQ is unreliable, by the way, I suggest you send a
patch to Steve Summit. Did you have a specific question in mind whose
answer you consider unreliable?
>
> The C FAQ is obviously just a static file, but if it was a dynamic
> resource, the MSDOS queries would have long vanished into the archive
> section.
And there they would remain... undeleted. Since the C FAQ is (as you
rightly say) relatively static, however, the archive section is kinda
all mixed up with the non-archive section. I seem to recall that
system-specific questions are in their own chapter anyway, so what's the
problem?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
But the clc FAQ isn't *full* of MSDOS references.
You would be far more impressive if you could stick to facts.
<snip>
I'm talking about what newcomers might think after glancing through section
19, which could do with an overhaul.
The rest of it seems sound enough to me, but I'm not an expert, so wouldn't
know if some of the advice written in 1995 (or perhaps earlier) is still
good 15 years later.
--
Bartc
> Richard Tobin wrote:
>> In article <3rWdnfcLoolZYfPW...@giganews.com>,
>> Joe Wright <joeww...@comcast.net> wrote:
>>
>>> MSDOS and CP/M are still very much "now" to me.
>>
>> MSDOS and CP/M seem older than they are because they were out of date
>> when they were designed.
>>
>> -- Richard
>
> The target of CP/M was the Intel 8080A. In what way was CP/M out of
> date in 1979?
Unix had been out for years before that and was a vastly better system
even then. Even Microsoft had their own Unix OS (at a later date
obviously).
> Andrew Poelstra wrote:
>
> <snip>
>
>> In any case, I do not believe that the memory limitations
>> discussed in the FAQ are at all frequently met. In fact, I
>> doubt that most C programmers encounter /any/ memory limits
>> on desktop PC's anymore. Certainly not when they're learning
>> and need a FAQ.
>
> The specific values mentioned in the FAQ may be no longer relevant, but
> we *do* have learners posting code which attempts to allocate local
> variable which are so large the allocation fails causing the program to
> crash. So there *are* still limits, and learners *do* still hit them!
>
> We also have had people post things similar to, "...but I've got 4GM of
> RAM!" when this is pointed out.
Then a discussion on the stack versus heap sounds like it would be in
order rather than issues relating to an outdated, little used operating
system wouldn't you say?
Which bits of section 19 do you think newcomers would think were unreliable?
<snip>
as a pastiche of spinoza this isn't bad (cod psychology, a touch of
sociology) but it's got a long way to go. You need to attack the
capitalist system (and in particular american business practices) you
need some literary references to show how well read you are. You
forgot to mention your degree or that you wrote all nash's (beautiful
mind) programs for him.
I'm beginning to think I ought to have stuck with 3 adjectives instead of
trying for four..
--
Bartc
Given that, even now, there are current production systems - not very
many, I grant you, but still *some - that rely on MS-DOS and which are
still being maintained and developed, two of the other three adjectives
are open to question, too. As for "old", the MS-DOS-specific material is
almost certainly about as old as much of the other material. Steve
Summit did do some C99-related updates a few years ago, but not many.
>> MSDOS and CP/M seem older than they are because they were out of date
>> when they were designed.
>The target of CP/M was the Intel 8080A. In what way was CP/M out of date in
>1979?
Nothing to do with the target. It was just a poor operating system.
For example, it only had a single directory for each disk.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
If you would read the original article of this thread
you wouldn't ask stupid questions.
>>
>> The C FAQ is obviously just a static file, but if it was a dynamic
>> resource, the MSDOS queries would have long vanished into the archive
>> section.
>
> And there they would remain... undeleted. Since the C FAQ is (as you
> rightly say) relatively static, however, the archive section is kinda
> all mixed up with the non-archive section. I seem to recall that
> system-specific questions are in their own chapter anyway, so what's the
> problem?
>
Nooooone. MSDOS deserves a section by itself. Unix doesn't. Windows doesn't,
Apple's iphone OS doesn't.
Everything is OK heathfield, go back to 1989.
I have read the original article of this thread. The question is not
stupid. It is a request for bartc to explain which questions he
considers to have unreliable answers. His response suggests that *he*
thinks there are no such questions. Interesting, eh?
>
>>>
>>> The C FAQ is obviously just a static file, but if it was a dynamic
>>> resource, the MSDOS queries would have long vanished into the archive
>>> section.
>>
>> And there they would remain... undeleted. Since the C FAQ is (as you
>> rightly say) relatively static, however, the archive section is kinda
>> all mixed up with the non-archive section. I seem to recall that
>> system-specific questions are in their own chapter anyway, so what's
>> the problem?
>>
> Nooooone. MSDOS deserves a section by itself. Unix doesn't. Windows
> doesn't,
> Apple's iphone OS doesn't.
Frequently asked questions deserve answers in an FAQ. If you have
examples of questions about Unix, Windows, or Apple's iphone OS that are
not dealt with in the FAQ, but which are (or have been) frequently asked
in this newsgroup, why not submit them to Steve Summit?
> Everything is OK heathfield, go back to 1989.
You don't do sarcasm well.
Why Unix didn't get used in the early microprocessors?
Because the Unix vendors had another strategy (that eventually
provoked their doom):
They IGNORED the microprocessor revolution. DEC, for instance,
wanted to go on selling VAXes and ignored ALL developments in
that field.
They were eventually bought by compaq, what an irony.
The same later with Sun microsystems, that ignored the mass
market and preferred to stay with their workstations.
They have been bought now by Oracle.
The only Unix vendors that survived were the ones that
did not ignore the mass market like HP or IBM.
CP/M was an incredible step backwards, but it was like
that because UNIX vendors choose to avoid the microprocessor
mass market, a strategy that led directly to their death.
> The same later with Sun microsystems, that ignored the mass
> market and preferred to stay with their workstations.
>
> They have been bought now by Oracle.
>
> The only Unix vendors that survived were the ones that
> did not ignore the mass market like HP or IBM.
>
> CP/M was an incredible step backwards, but it was like
> that because UNIX vendors choose to avoid the microprocessor
> mass market, a strategy that led directly to their death.
Confusing. All of DEC, Sun, HP and IBM sold UNIX on microprocessors.
And none of them mass-marketed UNIX. (I don't recall supermarkets
selling HP-UX or AIX systems.)
B.
DEC ignored the microprocessor market until it was too late
They sold their own processors. DEC started their own microprocessor
when it was too late, the "vax in a chip". And DEC NEVER
produced a PC. (well almost, their PC was a total failure)
Sun never sold a workstation at the price levels of the
mass market. They could have taken the position of Apple
by selling workstations that would have been directed
to the mass market but they didn't.
DEC and Sun never had any mass market strategy.
HP and IBM produced PCs in great numbers, I just do not
understand why you do not see such a difference!
> And none of them mass-marketed UNIX. (I don't recall supermarkets
> selling HP-UX or AIX systems.)
No. Instead of doing what NextStep did, making a user friendly
Unix version they marketed MSDOS!
But they survived because of that.
False premise. The first workstations built by Sun and Apollo used
Motorola's 68k family of processors.
> Because the Unix vendors had another strategy (that eventually
> provoked their doom):
>
> They IGNORED the microprocessor revolution. DEC, for instance,
> wanted to go on selling VAXes and ignored ALL developments in
> that field.
Completely wrong. The first VAX, introduced in 1977, was indeed built
with discrete TTL gates. However, the MicroVAX, introduced in 1984,
implemented the same instruction set using a CPU in VLSI technology.
And the 64-bit DEC Alpha CPU, introduced in 1992, was one of the finest
RISC CPUs ever.
> [...]
> The same later with Sun microsystems, that ignored the mass
> market and preferred to stay with their workstations.
True. But that does not change the fact that their workstations always
used microprocessors. First Motorola's 68k, later Sun's own RISC archi-
tecture called SPARC.
> [...]
> The only Unix vendors that survived were the ones that
> did not ignore the mass market like HP or IBM.
Well, HP always had deep pockets and the right intuition for good
acquisitions. For example the became a serious Unix vendor only after
buying Apollo, and their current PC business is all based on the know
how they bought with Compaq. And it's hard to tell how profitable HP's
computers based on PA-RISC and Itanium were.
IBM is a very special case. Their POWER architecture carried descrete
multi-chip design well into to 1990ies. Off-spins like PowerPC and the
Cell processor were rather short lived. And you might know they sold
their PC clone business to China a few years ago.
> CP/M was an incredible step backwards, but it was like
> that because UNIX vendors choose to avoid the microprocessor
> mass market, a strategy that led directly to their death.
Nice rant. Can you also do that without contradicting facts?
I mean, Gary Kildall originally developed CP/M during 1973-74. That
was about the time when Unix was rewritten in C (hey, we are getting
on-topic again!). So in terms of availability CP/M came first.
--
Lass die Leute reden und lächle einfach mild,
Die meisten Leute haben ihre Bildung aus der Bild.
Und die besteht nun mal, wer wüsste das nicht,
aus: Angst, Hass, Titten und dem Wetterbericht!
because it wouldn't fit.
> Because the Unix vendors had another strategy (that eventually
> provoked their doom):
>
> They IGNORED the microprocessor revolution. DEC, for instance,
> wanted to go on selling VAXes and ignored ALL developments in
> that field.
this is historical revisionism on a grand scale. It would be fairer to
say the PC people ignored Unix (not necessarily a dumb thing to do at
the time). Note "microprocessor" is not an alias for PC. Just as PC
was not an alias for "IBM PC"
what processor is used in t work station?
Yes.
Also, so far as I can tell, the death of "UNIX vendors" has a great deal to
do with the widespread availability of high-quality free competition. Which
is ultimately a great thing -- commoditize the bits we know how to do so
people can focus their budgets and effort on something unique or specific.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
"The early microprocessors" is a very wide field. Indeed, Unix
was used on many, several were designed for Unix. A more
interesting question is why Unix did not get used in the
early intel processors. The answer is that it was to
some extent (eg Xenix). These attempts never made much
headway, because the intel stuff was low powered. Forward
to the early 90's. If you wanted to do "serious" computing
you needed a "workstation" class processor. These mostly ran
some version of Unix, so there was a lot of unix development.
On the intel side, there were only relatively low powered
machines, and there was no good unix system. So you
were faced with a difficult porting job that would probably
not work very well.
Three things happened:
- The intel hardware got a lot more powerful,
so you could get workstation performance at
an order of magnitude lower cost.
- NT
- Linux
Given the hardware costs moving to intel was inevitable.
The NT POSIX layer did not work so porting to NT was hard.
The niche that had been taken by the SUN, SGI, etc.
workstations went to intel/Linux. My contention is that
if the NT POSIX layer had worked correctly from the beginning
Linux would be very much marginalized.
- William Hughes
I would suspect, though, that the people tasked with
maintaining those DOS machines are not brand spanking
new C programmers who need (or want) to read the FAQ.
Jacob's point is that the "real" brand spanking new C
programmers will see the DOS questions, remember from
their Java courses that all Old things are Bad, then
end up posting here anyway (or worse, doing their own
thing).
Andrew
In one sense, your reply is perfectly justified.
Well, I realized after the fact that if I replaced "though"
with "however" and "Bad" with "Evil", I could have been rid
of those pesky spaces.
But I should add that as near as I can tell, there aren't a
whole lot of people coming here with silly questions caused
by mistrust of the FAQ. Perhaps merely being Usenet in 2010
is enough to be inaccessible to most newbies?
Andrew
> On 2010-02-12, Alexander Bartolich <alexander...@gmx.at> wrote:
>> False premise. The first workstations built by Sun and Apollo used
>> Motorola's 68k family of processors.
>
> Yes.
>
> Also, so far as I can tell, the death of "UNIX vendors" has a great deal to
> do with the widespread availability of high-quality free competition. Which
> is ultimately a great thing -- commoditize the bits we know how to do so
> people can focus their budgets and effort on something unique or specific.
>
> -s
Actually as far as I can tell the major cause of the death of UNIX
vendors was a fragmentation of the market. At one point there was a
very large difference between System V and BSD flavours that didn't
help the UNIX cause one bit. It took Linux emerging for the big UNIX
vendors to get together and actually create worthwhile crossplatform
standards.
Apparently you have never heard about the PDP 11 then.
A 286 board was MUCH more powerful than the PDP 11,
and Xenix proved that Unix was feasible in a 386 board.
I used the Fortune machine with a 68000 processor that supported
9 users with 2MB of RAM.
I participated into the porting of Unix into the first 386
board that came in France, almost right after it came out
around 89-90 for Goupil, a French PC maker of that time.
Unix run circles around MSDOS... but the project was stopped
because management decided that MSDOS was better.
Steve Jobs proved (around that time) that a user friendly
UNIX was feasible. Problem was, I could never afford that
hardware, the mass market wasn't their customer target.
Microsoft targeted the mass market. And won, against all
odds because of the attitude of Unix vendors.
what?
Linux is even more fragmented that the different Unix flavors at that time.
No, against no odds at all. Microsoft won because of the IBM PC, and
network effects.
BTW, to answer your question: I made some comment about industry shifts,
and found out that there are still live systems in production -- and NEW
systems being PUT INTO production -- running DOS.
A friend of mine does fire alarm control systems. They have very small
CPU requirements, EXTREMELY high predictability and testing requirements,
and some such software has been extremely thoroughly vetted for DOS or
Windows 98 environments. As a result, there are people building new buildings
who are setting up new machines. Running DOS. Because they are SURE it
will work.
So, no, DOS is not yet dead. Much though we might wish it to be otherwise.
I wrote a hunk of code which has one meaningful #ifdef in it, which is
working on every Linux system we know of currently available. It's not
quite stable enough that you can use binaries from one system on another,
but that's because it is by design an EXTREMELY non-portable piece of code.
I don't mean "currently in production" -- I mean we're including Red Hat
Enterprise Linux 4, which dates back to 2005. I've had to check for the
availability of precisely one feature that didn't exist in RHEL4, and
everything else I need is adequately consistent between RHEL4 and Fedora 12,
OpenSuSE 11, and so on.
That's substantially better compatibility than we used to have between BSD
and SysV.
For that matter, this is one of the only pieces of code I've seen in years
that wouldn't run perfectly well on any BSD or Linux or Solaris type system.
The migration towards consistent interfaces occurred mostly in the 90s, and
is now adequately complete.
... Okay, I gotta bring this back on topic.
The "#ifdef" remark above refers to a convention which has extremely high
expressive power for dealing with portability. The idea is that in addition
to providing declarations of functions and types, headers can also provide
what are called "feature test macros" -- macros which are defined if and only
if a particular feature is available. This allows code which would like
to support a given feature to do so where that feature is available, while
falling back on an alternative where it isn't.
Another variant of this is feature-request macros, where a particular
macro, if defined before a header is included, has magical effects
on the header. For instance, if you're compiling things on a typical
Linux box, there are a lot of extra features which will be disabled if
you've put the compiler in a reasonably standard mode. You can bring many
of them back by doing something like:
#define _POSIX_SOURCE
or
#define _GNU_SOURCE
before including various headers.
Well-documented and standardized things like this make it easier to write
code which is portable across a variety of implementations, while getting
additional performance on others. Even if you can't work without a feature,
it can be preferable to use a #error directive to diagnose the specific
problem rather than leaving the reader with a huge stream of "syntax error
before..." messages.
The best-selling single personal computer model of all time is the
Commodore 64. Yet Commodore is no more. Same can be said of Atari,
Sinclair, the BBC Micro, the MSX standard, etc. To my knowledge out
of all companies that targeted the mass market with 8-bit and 32-bit
home computers only one survived: Apple.
--
First bet:
It doesn't use any GUI
Second bet:
It doesn't use any sound/video/multimedia
Third bet:
It doesn't use any graphics, or mouse
Obviously, THEN... it is portable. But it would be portable to
Mac/windows/whatever too without much pain.
Actually, there's no reason why it shouldn't, given that he is only
claiming portability across "every Linux system we know of currently
available". The same applies to your other two bets...
>
> Second bet:
>
> It doesn't use any sound/video/multimedia
>
> Third bet:
>
> It doesn't use any graphics, or mouse
...but if he were claiming general cross-platform capability, your bets
would be pretty solid, I think. Nevertheless, a system can use such
components and still be /largely/ portable - i.e. the rewrite work for
each platform can be isolated and contained in specific modules, where
it is easily identifiable (and surprisingly small, if the design is good).
> Obviously, THEN... it is portable. But it would be portable to
> Mac/windows/whatever too without much pain.
If the system is written with portability as one of the major
objectives, the pain may indeed be minimal.
I can use the same code from windows 95 to windows me to windows NT/XP
to VISTA and windows 7, using windows, mouse, graphics, sound, and
many other things with minimal problems. The same isn't true in
linux. You have the KDE/Gnome problem (QT/GDK) and within GDK, the
only that I used, the problem that each version is (of course) incompatible
with the last version. I gave up following GDK and rewriting my
application again
Why this mess?
Because windows is done by microsoft, a monopoly that wants to keep
most customers (and developers) happy to go on selling them stuff.
Linux is free, and the developers of linux GUIs do not care about users
since their user base doesn't pay them at all. So they do as they
find fit, and the users must rewrite all their applications at their
whim.
Obviously there are IMPORTANT part of linux that are rock solid since
there are CUSTOMERS that PAY linux developers to maintain those
parts: network, basic multi tasking, etc. Linux as a SERVER runs pretty
well since IBM/ORACLE/whatever PAY for top notch linux developers.
GUIs are used by "normal" users, and nobody gets payed for them.
Consequence: a mess.
In the linux bazaar, money is the center of attention like in any
other bazzar, even those that look like cathedrals.
The same situation appears in the linux developer tools, that are
at the same level that Unix 20 years ago...
vi+make+gdb
No sane linux developer would PAY for a development system. And
the consequence is that there are hundreds of unfinished "DUE"s:
"Desintegrated Unusable Environments" that promise the world
but deliver just crashes. The only one that halfway works is
Eclipse because IBM PAYED for it.
> >> It doesn't use any GUI
> >
> > Actually, there's no reason why it shouldn't, given that he is only
> > claiming portability across "every Linux system we know of
> > currently available". The same applies to your other two bets...
> >
>
> I can use the same code from windows 95 to windows me to windows NT/XP
> to VISTA and windows 7, using windows, mouse, graphics, sound, and
> many other things with minimal problems. The same isn't true in
> linux. You have the KDE/Gnome problem (QT/GDK) and within GDK, the
> only that I used, the problem that each version is (of course)
> incompatible with the last version. I gave up following GDK and
> rewriting my application again
You speak as if Qt and GTK+ are the only options. But of course, you
know better than that.
(You can still run truly ancient Motif-based applications, or
applications that implement their own GUI via Xlib quite successfully.)
B.
The first unix I saw was on a PDP 11/45 in 1977. This was at Bell
Northern Research in the Palo Alto / Mountain View area.
--
Tim
"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"
Bill of Rights 1689
>> I wrote a hunk of code which has one meaningful #ifdef in it, which is
>> working on every Linux system we know of currently available.
> First bet:
> It doesn't use any GUI
Right you are!
> Second bet:
> It doesn't use any sound/video/multimedia
Right you are!
> Third bet:
> It doesn't use any graphics, or mouse
Three for three!
> Obviously, THEN... it is portable. But it would be portable to
> Mac/windows/whatever too without much pain.
And here you've got a Nilges-grade error.
Lemme tell you what this hunk of code is. This'll drift a bit off topic,
but it's a very good example of how very non-portable a piece of code can
be. I would guess that I could get it running on OS X in a month or so,
but I am pretty sure it is semantically incoherent to talk about "porting"
it to Windows.
Background:
* Nearly all executables on Linux systems are dynamically linked, meaning
that they pick up the C library at runtime.
* Unix-like systems distinguish between "library" calls (made to code in
the C library) and "system" calls (made to the kernel).
* But actually, nearly all syscalls exist as tiny little stubs that are
found in the library and which contain the raw inline code to make a
syscall.
* The dynamic linker on Linux checks certain environment variables when
starting up, BEFORE it loads anything (including even the C library).
* These can cause it to do things like check paths other than the usual
system-wide linker path, and/or to load libraries BEFORE the shared
libraries a program was linked with, and which it was not linked with and
it has no knowledge of.
* The product I work on involves creating filesystems for embedded Linux
systems.
* Creating filesystems nearly always involves operations that require
root (sysadmin) privileges.
* It is extremely desireable that users not need root access on their
workstations to do it, though.
So.
The "hunk of code" alluded to above is a two-part thing. One part is a shared
library. Another part is a server. The shared library is designed such that,
if you put its name in the LD_PRELOAD environment variable, and a path to it
in the LD_LIBRARY_PATH environment variable, it will get picked up by any
dynamically-linked executable, and lookups of calls in it will pick up the
versions in this library BEFORE they pick up versions in the C library.
And it provides functions with the same names as a few dozen system calls,
and a couple of C-level library calls.
When you first hit one of these functions, it builds itself a table of the
"next" versions of all these calls (usually the ones in the C library, but
there could be other similar libraries; we don't care). And then it sets
up wrappers so that when you call the syscall open(), what you actually get
is my implementation of open(), which does some interesting magic stuff.
What this ends up doing is allowing me to intercept every system call that
deals with the filesystem and is affected by privileges, and act as though
you had root privileges, or at least, make it look as though it acted as
though you had root privileges. The client code does this by finding out
whether it has a server, and if not, starting a server, to which it then
sends messages informing the server about operations, or querying the server
about filesystem objects; the server maintains a database of files and
what to claim they are. So if you try to create a "device node" (a special
kind of Unix "file" which instead of having contents provides access to
the userspace interface of a device driver; e.g., a file named "sda1" might
end up hooked up to the first partition of the first SCSI disk on the
machine), what actually happens is:
1. I verify that there's not a file there, and if there is, fail
the same way the real syscall would have.
2. I create a plain file with no contents of that name.
3. If that succeeded, I send a note to the server telling it that
the file I just created should LOOK like it's a device node
with the given attributes.
Later, if you try to look at that file with, say, "ls -l", what actually
happens is:
1. I check the real file on disk.
2. I query the server about that path and file dev/inode (magic ID
uniquely identifying a file).
3. If I got anything back from the server, I replace the file's
"real" attributes with the attributes the server gave me.
4. I report back as though nothing happened.
There's a lot more, and some of it gets extremely arcane; there's magic
to intercept dozens of calls and do very surprising stuff.
The net result is that you can run an entire system install process and
end up with something which, viewed through this tool, looks just like a
properly-installed filesystem, complete with files owned by many different
users, device nodes, and everything. And then you can use other tools
which do things like create raw filesystem images or archives, and run
them in this magic mode, and get raw filesystem images which, dumped to disk
or flash, actually are working filesystem images with all the right modes.
The concept of porting this to Windows is frankly laughable. I could probably
get it working on BSD or OS X in about a month, give or take, but I'm not
totally sure; there's some pretty crazy assumptions in there, although I've
developed some neat trickery to allow this code to work even if some of the
"extra" calls it has don't exist on a given target. (e.g., some systems have
a family of calls with names like "openat()" or "unlinkat()" which allow you
to operate relative to a directory without having to specify the path to
that directory, others don't; my program wraps them if they exist, but works
fine even if they don't.)
Porting this between BSD and SysV in 1989 would have been much harder than
simply rewriting nearly all of it from scratch completely differently for
each, if it had even been possible to do it at all. (By 1990, you could
at least get ELF and dynamic linking on SVR4, so it might have been
possible there.) So, no, the Linux environment is NOT more fragmented than
the historical Unix market. They have greater code portability than anything
we ever saw back then.
> On 2010-02-13, jacob navia <ja...@spamsink.net> wrote:
>> Seebs a écrit :
F> 3. If that succeeded, I send a note to the server telling it that
So you basically admit its unportable "junk"?
You do realise that dont you?
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
> Seebs <usenet...@seebs.net> writes:
>
>> On 2010-02-13, jacob navia <ja...@spamsink.net> wrote:
>>> Seebs a �crit :
>>>> On 2010-02-12, jacob navia <ja...@nospam.org> wrote:
>>>>> Linux is even more fragmented that the different Unix flavors at that time.
>>
>>>> I wrote a hunk of code which has one meaningful #ifdef in it, which is
>>>> working on every Linux system we know of currently available.
>>
>>> First bet:
>>
>>> It doesn't use any GUI
>>
>> Right you are!
>>
>>> Second bet:
>>
>>> It doesn't use any sound/video/multimedia
>>
>> Right you are!
>>
>>> Third bet:
>>
>>> It doesn't use any graphics, or mouse
>>
>> Three for three!
>>
>>> Obviously, THEN... it is portable. But it would be portable to
>>> Mac/windows/whatever too without much pain.
>>
>> And here you've got a Nilges-grade error.
>>
>> <snip>
>> Porting this between BSD and SysV in 1989 would have been much harder than
>> simply rewriting nearly all of it from scratch completely differently for
>> each, if it had even been possible to do it at all. (By 1990, you could
>> at least get ELF and dynamic linking on SVR4, so it might have been
>> possible there.) So, no, the Linux environment is NOT more fragmented than
>> the historical Unix market. They have greater code portability than anything
>> we ever saw back then.
>>
>> -s
>
> So you basically admit its unportable "junk"?
>
> You do realise that dont you?
Unportable != junk.
Some things just have to be tied to a specific operating system. There
is only so much abstraction one can do before one has to get into the
nitty gritty of implementation specific software.
> Lemme tell you what this hunk of code is.
This was very interesting, thanks.
> When you first hit one of these functions, it builds itself a table of the
> "next" versions of all these calls (usually the ones in the C library, but
> there could be other similar libraries; we don't care).
I guess you use some kind of static variable (umm, an object of
integer type with static storage duration, internal linkage, file
scope) for checking if the preloaded lib was already initialized. Is
this thread-safe and/or async-signal safe?
Have you considered the "constructor" gcc function attribute?
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-Attributes.html
http://tldp.org/HOWTO/Program-Library-HOWTO/miscellaneous.html#INIT-AND-CLEANUP
http://tldp.org/HOWTO/Program-Library-HOWTO/miscellaneous.html#INIT-AND-FINI-OBSOLETE
As a lame "trick" question, how does the expression look where you
assign the value returned by dlsym(RTLD_NEXT, "open") to your
"orig_open" function pointer? :)
> What this ends up doing is allowing me to intercept every system call that
> deals with the filesystem and is affected by privileges, and act as though
> you had root privileges, or at least, make it look as though it acted as
> though you had root privileges. The client code does this by finding out
> whether it has a server, and if not, starting a server,
What were the arguments against implementing this with FUSE?
Also, how does the client start a server? Does it fork()? Or by
posix_spawn()? Or by messaging a super-server?
Thanks,
lacos
If you are expecting to communicate with one of our standard trolls,
you have missed the point greatly.
> Some things just have to be tied to a specific operating system. There
> is only so much abstraction one can do before one has to get into the
> nitty gritty of implementation specific software.
Exactly. Boot loaders are only marginally portable, but a good boot loader
is EXTREMELY valuable. (This lesson is driven home forcefully once you
have used some bad boot loaders.)
I would guess that I could extend this work to cover other modern Unix-like
systems with a reasonadble amount of effort; I've gone to great lengths to
make large hunks of the code reliable, clean, and portable. But
fundamentally, the task under discussion is inherently constrained to
particular environments.