standard include files

Q

Quentin Pope

fair enough.

I wasn't seriously expecting much modern development to be being done on
DOS systems, and other (more modern) DOS variants, such as FreeDOS, have
LFN support, so it is likely a moot point anyways.

You might be surprised.

In Fall 2010 I was in India to oversee setting up a new campus where our
company is best-sourcing some of its development work. I interviewed a
lot of computer science graduates. The majority of them had learned C in
a Borland environment running on DOS. And why not? It's a standardized
language, so why not go for a (now) free compiler running on cheap
hardware?

// QP
 
Q

Quentin Pope

hmm... I had overlooked / was not aware of this.

but, yes, IBM and their sometimes strangely arcane systems.

You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.
 
J

jacob navia

Le 26/02/12 22:07, Quentin Pope a écrit :
You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.

So, you seem to believe that a mere PC (even with the best Intel in
existence) is faster than an IBM MAINFRAME running zOS???

That would be news to me...

That IBM has strange and arcane systems doesn't mean that those
systems are slow or even less powerful than a PC!!!

But Mr Quentin Pope will write ANY nonsense as soon as it can be
possible to put something against Navia isn't it?

:)

jacob
 
E

Eric Sosman

[...]
but, yes, IBM and their sometimes strangely arcane systems.

You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.

No, Mr. BGB started by worrying about the difficulties a C
implementation might face on (wait for it) "MS-DOS / Win 3.x".
 
K

Keith Thompson

Quentin Pope said:
On 2/26/2012 12:17 AM, Robert Wessel wrote: [...]
zOS (IBM mainframe) C/C++ developers often use PDSs to store header
files - these make names longer than eight characters problematic, at
best. In fact C header files are often stored in a PDS dedicated to
headers, and the header name does not include the ".h".

hmm... I had overlooked / was not aware of this.

but, yes, IBM and their sometimes strangely arcane systems.

You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.

I fail to see how your criticism relates in any way to what BGB
actually wrote.
 
K

Keith Thompson

Quentin Pope said:
You might be surprised.

In Fall 2010 I was in India to oversee setting up a new campus where our
company is best-sourcing some of its development work. I interviewed a
lot of computer science graduates. The majority of them had learned C in
a Borland environment running on DOS. And why not? It's a standardized
language, so why not go for a (now) free compiler running on cheap
hardware?

Ah, but how likely is it that any future C standards, or even C99,
will be supported by implementations hosted on MS-DOS?

As you say, I might be surprised -- but *if* we can safely assume
that *modern* MS-DOS hosted implementations are not a realistic
possibility, then C11 and later standards needn't worry about MS-DOS
hosting any more than they already do.

Then again, the C standard has never been limited to systems that
support long file names, so it's not much of an issue anyway.
 
B

BGB

[...]
but, yes, IBM and their sometimes strangely arcane systems.

You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.

No, Mr. BGB started by worrying about the difficulties a C
implementation might face on (wait for it) "MS-DOS / Win 3.x".

yep.


a few issues that come to mind:
8.3 file-names;
16-bit address issues (if not using DPMI or Win32S);
FAT16 (which deals very poorly with large numbers of small files, I have
memory of these pains with larger drives);
....


luckily, I started getting into computers when MS-DOS and Win 3.x was
nearing the end of its life-span, and being subsumed by the then new
Windows 95 (I was in elementary school at the time).

IIRC, the last time I was using a primarily DOS computer, it was IIRC a
hacked-together mix of the Win95 version of MS-DOS and a MS-DOS 6.22
implementation (many of the tools which were missing from the Win95 DOS
were copied over from 6.22). IIRC, I think I was mostly using the Win95
version of DOS for sake of FAT32 or similar (but, I was using it solely
as DOS due to saving disk space and given nearly everything I was doing
was in DOS).

I think I still had Win 3.11 and Win32S on the thing though, which I
remember as being able to run many Win95 apps at the time (the computer
was itself a 486 cobbled together from spare parts, with some "creative"
modifications, and duct tape, to make up for the case, PSU, and MOBO,
not really fitting together due to mismatched mounts and screw-holes...).


this carried over until a short time after the release of Win98, when my
HDD died horribly (boot-sector died), and I essentially lost everything
I had on that computer. subsequently, I just used Linux for the next
several years (cause Win9x was generally too terrible to really be worth
bothering with), but ended up later migrating back to Windows (using
Win2K), a short while before WinXP came out, then I used XP mostly this
up until fairly recently, when Windows 7 was released, mostly because my
brief exposure to Vista was... not exactly enjoyable (lag, many programs
not working anymore, ...).

IIRC, I messed with NT4 as well, but remember not really liking it at
the time (I think I remember lots of DOS apps not really working, like
Doom and Quake and similar refusing to work).


IIRC, I started out programming mostly using QBasic, and got some older
copies of MASM and TurboC.
over time, I migrated from QBasic to TurboC, mostly as QBasic was slow
and very limiting, and I remember being able to have much bigger arrays
and similar in TC (using far pointers).

after a while, I then jumped over to DJGPP (but still used QBasic for
misc things "here ant there"), and was using this for a while until the
fateful HDD crash.


later on, when returning to Windows land, I was using Win2K and Cygwin,
and have used primarily C since then (though migrating to MinGW and
later MSVC), with occasional ventures into other languages, but not
really liking what I found there.

I messed with Java but found it terribly slow and awkward at the time
(this being before Java stopped really being dead-slow), and at one
point ended up half-way migrating into Scheme land. despite developing
primarily on Windows, I never really "got into" .NET though (due to
various reasons). other reasons generally prevented a large-scale
migration to C++ as well.

or, at least, this is a quick summary of the past several decades...


but, often, the past does not entirely go away, and maybe some people,
somewhere, are still using primarily MS-DOS?...

or such...
 
B

BGB

You might be surprised.

In Fall 2010 I was in India to oversee setting up a new campus where our
company is best-sourcing some of its development work. I interviewed a
lot of computer science graduates. The majority of them had learned C in
a Borland environment running on DOS. And why not? It's a standardized
language, so why not go for a (now) free compiler running on cheap
hardware?

well, I learned C also using a similar environment, but this was decades
ago now (back in the 90s...).

granted, I am native to the US as well.
 
J

James Kuyper

On 2/26/2012 1:41 PM, James Kuyper wrote: ....
I'll admit that all these mappings are "name-preserving" in
some sense specific to the systems involved. However, 6.10.2p2
does not require that the Standard headers be files, nor that their
file names (if any) have any obvious relation to the header names.

I'm fully in agreement with that; I'm just saying that the case you
presented doesn't qualify as an example of any of those odder possibilities.
 
B

BGB

Quentin Pope said:
On 2/26/2012 12:17 AM, Robert Wessel wrote: [...]
zOS (IBM mainframe) C/C++ developers often use PDSs to store header
files - these make names longer than eight characters problematic, at
best. In fact C header files are often stored in a PDS dedicated to
headers, and the header name does not include the ".h".

hmm... I had overlooked / was not aware of this.

but, yes, IBM and their sometimes strangely arcane systems.

You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.

I fail to see how your criticism relates in any way to what BGB
actually wrote.

yeah... the issue was not saying that IBM mainframes are slow, but more
the PDS thing, with 8 character name limits. nevermind things like
EBCDIC and similar. along with such things as "Token Ring" and "Twinax"
cabling.

and where COBOL is still alive and well...

nevermind fixed-field form and menu-driven systems (with absurd color
schemes) accessed via terminal emulators, ... all on presumably fairly
modern (PowerPC based) HW... (I had brief exposure to some this once
before...).


doesn't mean it is necessarily old or slow, but more the sorts of things
which would likely make most "sane" computer users (assuming they know
enough to understand it) to be all like "WTF is this?!" (like the
computer equivalent of some strange/alien landscape or something...).

hence, "arcane"...


and is maybe also part of why PowerPC is popular on game consoles: makes
it harder to pirate the games and run them on a PC in an emulator,
because they would run slowly (if it were x86 based, they could
potentially use partial OS or HW emulation via virtualization or
similar, but given it is a different ISA, it makes tolerable-performance
emulation much harder, so no one can just play pirated XBox360 or PS3
games on a desktop PC in an emulator, but have to go for the potentially
much more painful and expensive route of getting a "modded" game
console...).


or such...
 
J

James Kuyper

On 02/26/2012 04:04 PM, Quentin Pope wrote:
....
In Fall 2010 I was in India to oversee setting up a new campus where our
company is best-sourcing some of its development work. I interviewed a
lot of computer science graduates. The majority of them had learned C in
a Borland environment running on DOS. And why not? It's a standardized
language, so why not go for a (now) free compiler running on cheap
hardware?

Because, based upon the questions we've received in this newsgroup from
Indian students learning on those systems, I gather that it's a compiler
that doesn't actually fully conform to the standard (any version). The
reason that compiler is free and the hardware is cheap is that both are,
at best, obsolescent, if not actually obsolete.
 
B

BartC

Quentin Pope said:
You might be surprised.

In Fall 2010 I was in India to oversee setting up a new campus where our
company is best-sourcing some of its development work. I interviewed a
lot of computer science graduates. The majority of them had learned C in
a Borland environment running on DOS. And why not? It's a standardized
language, so why not go for a (now) free compiler running on cheap
hardware?

How cheap does it have to be? The cost of the RAM in that DOS machine, at
today's prices, is probably less than $0.01! The trouble is it comes in
GB-sized modules. [A 2GB upgrade for my PC costs about £10]

If students in a 3rd-world country (that happens to have a space program),
only have access to machines that are 20+ years old, that's fine. They are
not obliged to use a stdheaders.h file. But if trying to compile and run any
open source projects on such hardware, the size of the standard headers will
be the least of their problems.

In the meantime I don't see why other developers should be constrained by
these sorts of considerations. If we're talking about commercial work, then
in the UK for example, the pay of a contract programmer ... actually, forget
a programmer, even someone working in McDonalds would be earning the
equivalent of 20MB of RAM every single minute! How much time would be saved
typing all those includes?
 
B

BGB

17 AM, Robert Wessel wrote:
[...]
zOS (IBM mainframe) C/C++ developers often use PDSs to store header
files - these make names longer than eight characters problematic, at
best. In fact C header files are often stored in a PDS dedicated to
headers, and the header name does not include the ".h".

hmm... I had overlooked / was not aware of this.

but, yes, IBM and their sometimes strangely arcane systems.

You are in good company with Mr Navia, who seems to believe that anyone
not running an x86 with blazing-fast hardware is unworthy to use the C
language.

I fail to see how your criticism relates in any way to what BGB
actually wrote.

yeah... the issue was not saying that IBM mainframes are slow, but more
the PDS thing, with 8 character name limits. nevermind things like
EBCDIC and similar. along with such things as "Token Ring" and "Twinax"
cabling.

and where COBOL is still alive and well...

nevermind fixed-field form and menu-driven systems (with absurd color
schemes) accessed via terminal emulators, ... all on presumably fairly
modern (PowerPC based) HW... (I had brief exposure to some this once
before...).


IBM Mainframes (the S/360 line, "System z" now), is not at all PPC
based.

PPC (POWER) runs both of IBM's midrange lines, the *nix based System p
(formerly RS/6000, pSeries, etc.), and now the System i (the old S/38,
AS/400 minis). IIRC, IBM is rebranding both of those as "IBM Power
Systems". The System i still has a fair bit of green screen support
(5250's, rather than the 3270s seen on the mainframe systems).

well, yes, but will anyone try to disagree with me that it is all a bit
strange, if considered from the POV of Windows or Linux based PCs or
servers?...

PPC has a considerable presence in embedded systems. Macs used to be
PPC based as well. The three main console vendors all chose PPC, but
for different reasons, and I don't think incompatibility with x86 was
a major reason in any case. FWIW, the original xBox, was Pentium III
based.

well, yes.

the XBox was also well known for being fairly easy to hack, and if one
got the right software, IIRC it was also possible to emulate XBox games
on the PC at reasonably decent performance (and with slight
wire-splicing, one could do so using the XBox controller as well, since
it was basically just a USB gamepad with a special connector).

But PPC is anything but arcane.

probably depends on who you ask, or what it is compared to...

probably the most commonly well-understood architecture around is x86.
ARM systems are fairly common, but far fewer people in total probably
develop for them (and, IMHO, the Thumb/Thumb2 instruction codings are a
bit dubious, looking a fair amount like ad-hoc bit twiddly magic).

PPC is sort of in the background, as an architecture relatively few
people really deal with directly or develop for, more existing as a
piece of mystery hardware sitting in their PS3 or XBox360 or similar.

granted, yes, at the C level it probably doesn't look too much different
from one to the other, but the ASM is notably different.


but, anyways, I suspect it probably still stands to reason that it would
be much easier to make a good performance x86 on x86 emulator, than it
is to make a good performance PPC on x86 emulator (or a good performance
ARM on x86 emulator).

although, there is a mystery though: the Android emulator for the PC is
dead slow, but at least from what I have heard, the iOS for OSX emulator
actually performs fairly well (though I have no first-hand experience to
test with).
 
N

Nomen Nescio

zOS (IBM mainframe) C/C++ developers often use PDSs to store header
Well no, since very little C/C++ is done on the mainframe under z/OS. There
is quite a lot of C/C++ done on the mainframe under z/Linux and there is no
problem since the filesystem z/Linux uses are not PDS based. There is also
support in z/OS natively for UNIX and that also uses a non-PDS based
filesystem. C really doesn't have much purpose on mainframes. It's like
criticizing PL/I because there aren't many PC compilers for it. Don't use C
on a mainframe, it's that simple. There are much better choices.

Correc and more to the point, none of the IBM mainframes are based on POWER
and they never were. PPC is used for what we mainframers call "toy
computers" those things the PC guys call "servers". They run UNIX, Linux,
Solaris and other toy OS.

Not arcane, you just missed all the interesting and correctly designed
hardware and software if you think UNIX is a good OS or Intel makes good
microprocessors. IBM kicks their ass. Yeah, they kick it good.
granted, yes, at the C level it probably doesn't look too much different
from one to the other,

Right and that is all most idiots care about. To a C coder everything is the
same, it just depends what editor or IDE you get.
 
P

Phil Carmody

Quentin Pope said:
In Fall 2010 I was in India to oversee setting up a new campus where our
company is best-sourcing some of its development work. I interviewed a
lot of computer science graduates. The majority of them had learned C in
a Borland environment running on DOS. And why not? It's a standardized
language, so why not go for a (now) free compiler running on cheap
hardware?

Because it teaches you things like the existence of "far" pointers,
and the use of functions in <conio.h>?

Phil
--
I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)
 
P

Phil Carmody

BGB said:
this doesn't make much difference though, the normal result is that
header names on Linux need to match exactly, and on Windows may differ
in case, but otherwise need to have the same characters.

Scarily, I've seen case-insensitive file name matching on OSX too. (At
all levels, not just in the context of #includes.) And there I was
thinking it was based on unix...

Phil
--
I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)
 
B

BGB

FreeDOS comes to mind.

yes, but whether or not FreeDOS counts or not is secondary (very
possibly there could be more FreeDOS users at this point than people
using MS-DOS proper).
 
B

BGB

Scarily, I've seen case-insensitive file name matching on OSX too. (At
all levels, not just in the context of #includes.) And there I was
thinking it was based on unix...

well, yes, but this wouldn't be the first thing weird thing about the
filesystem on a MacOS based system (if contrasted with either Unix or
Windows).

for example, there are also resource forks, and using ':' as a directory
separator, though from what I can gather, both have apparently fallen
into disfavor.

granted, I have no real firsthand experience with OSX.
 
M

Markus Wichmann

yes i'm not better of all you...
i said that because it seems to me all is easy,
but people invent useless complications
that make complicate algos difficult
(if not impossible) to write down
and the remain difficult to write

Provided I read that correctly: No, no-one is "inventing" complications.
You just have misconceptions about what is part of C and what isn't.
DLLs aren't.

Robert just wanted to show you the enormous flexibility of the C
standard. It would even allow a compiler to recognize calls to printf
with a constant format string and replace them with predefined formating
functions. Like:

printf("%d: %u\n", i, a);

could become

fmt_int(i);
fmt_puts(": ");
fmt_uint(a);
fmt_puts("\n");

The net gain, if the printf implementation were to use the same
formating functions, would be that the resulting executable would only
contain the necessary formating functions if printf() is never called
with a non-literal format string, and if it is, at least there would be
no duplicates.

Of course this completely breaks down in the face of the not unheard-of
construct:

int want_loglevel;
int log(int loglevel, const char* fmt, ...)
{
if (loglevel <= want_loglevel) {
va_list ap;
int r;
va_start(ap, fmt);
r = vfprintf(stdout, fmt, ap);
va_end(ap);
return r;
}
return 0;
}
than i were curious for the answer again me
i did provoke...


not for me

Though if you want to communicate, learning the language used would be a
good first step, wouldn't it?
"Simple" cannot be judged out of context.
Sure, in the contexts
you're familiar with, putting the CRT in a DLL may be simple (at least
some of the time). Yet for some implementations doing so may be
unreasonably difficult, so the "simple" solution is something else.

yes, i find very good to use MS Windows32 api: LoadLibrary()
FreeLibrary(), GetProcAddress()
and find very good the way RosAsm [one assember IDE too]
import .dll function as nameDllInMemory.nameFunction() too;
even if i not use all that name because i use define e.g.
%define GetStdHandle 'kernel32.GetStdHandle'

You completely missed the point (provided I understood your garbled
english correctly): Yes, on Windows, where Microsoft already provides
you with routines for dynamic linking, it might be a good idea to put
the CRT into DLLs. However, that is not always and not everywhere the case.

Case in point: On Linux, you actually get to see the kind of work a
dynamic linker has to do, before the application even can start (look at
the source of ld.so). Thus, you actually have to ask yourself whether
the saved space (on disk and _maybe_ in memory) is worth the runtime of
the dynamic linker. I for one could speed up the booting process by
linking the tools necessary for that statically. For example, as it
turns out, dynamically linking /bin/true takes far longer than the rest
of the runtime. Another example would be mplayer and mencoder, two
applications that are keeping the record in the number of depended-on
libraries (>100 for both of them). Since that number is pretty big and
the libraries are unlikely to be used by another program at the same
time, I have them linked statically for a major speed-up on start-up.
So the assumption that the CRT is in a DLL is simply wrong. Unless
you want to limit yourself to only those implementations (and submodes
of those implementations) where such is actually true.

so you say .dlls are not the way [to minimize the use of memory]...

Again, on Microsoft Windows that may be the case. However:

- Not all the world is a PC.
- Not all the world is Microsoft Windows.
- Not all the world is even x86 or compatible.
- Not everything else has facilities comparable to facilities of the
aforementioned.

For example, a C implementation is not required to have:
- an MMU
- multi-processing support
- a "disk" in the traditional sense (spinning round thingy)
- a disk in the logical sense (as mass storage device)

have a good day

HTH,
Markus
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,082
Messages
2,570,589
Members
47,211
Latest member
Shamestone

Latest Threads

Top