Creating My own laser show software

[JohnYayas]

Im not an expert or have enough knwoledge to discuss with you guys.

Same could be said about James. LOL

[james]

I think my point is that the whole idea that everything is a file in UNIX and that every file has ownership and permissions and a list of possible states. All of this is built into the file IO functionality of C and C++. The idea of the FILE construct in C and streams in C++ is all about the commonality of moving data to or from devices that either consume or produce data or both.

A keyboard, mouse, touch pad, joystick, display screen, printer, scanner, sound card, tape drive, memory stick, modem, etc... are all files.

Almost all of that is lost in Windows.

The areas where both C and C++ break down in total incompatibility between UNIX and Windows is file IO. And in UNIX, one does not spend so much time working with proprietary device drivers. That is handled within the scope of file IO.

In other words there are large parts of both C and C++ that are standard to UNIX (from whence they came) that have absolutely no meaning at all to Windows.

The unfortunate thing about this is that someone programming in Windows isn't even afforded the opportunity to think in these terms. "Everything is a file" is one of the fundamental design concepts of UNIX.

Yes. You are correct UNIX was written in C and C was written to be the choice compiled language for UNIX.

C++ was written to make it easier to write things like windowing systems. X by Xerox being the most notable.

James.

[heroic]

This is so far from true, James, that I wonder where you got the idea. There are no "large parts" of C (C is an extremely compact language), and there are certainly no "large parts of C++" that are meaningless in Windows. There are also huge swathes of Unix, including whole families of unix device drivers, that expose no file interface (for example, I see no file-oriented interface to my ethernet card.)

C++ was invented at Bell Labs as a collection and standardization of the various object oriented extensions of C. X was not written by Xerox, and certainly wasn't written in C++.

[james]

There are no "large parts" of C (C is an extremely compact language)

As you know, C is largely written in C. You are correct in your assertion that there are very few reserved key words. However, you won't get very far is you limit yourself to just using those key words and never including any of the header files that allow you to use all of the other functionality that comes with your compiler. There are also many lists of error codes or status conditions that are almost always represented as integer values. Even though they are not words, exactly, they have meaning that contributes to the language. C and C++ is not just a matter of a few reserved key words. It is the total understanding of the whole thing, how to use other code that comes with the compiler and from other sources and how that all works with the OS. That is HUGE.

Sockets is most definitely a kind of file IO.

Of course devices have unique drivers in UNIX. But the way we communicate with those drivers is abstracted to file IO, even if it is the most raw read and write. This is how UNIX maintains the integrity of its security systems. The kernel knows owners and permissions of files.

[heroic]

James, that's just not true. Seriously. There are whole classes of device that are *not* represented by pseudofiles under /dev.

Let's look at:

USB- the interface to USB is not even remotely file-like. Some USB device drivers expose file-like /dev entries. That's not the same thing.

Video- good luck talking to a video driver with a file-like interface; you *can* mmap a framebuffer, but that's not even scratching the surface of a video driver these days.

Audio- yes, I know about /dev/audio and /dev/dsp, but in fact that's a convenience interface exposed by the driver (just like the video system's /dev/fb entries), not the driver itself.

Network- yes, sockets are file-like. But the ethernet device underlying them is not. There's no /dev/en0 on this mac. There's no /dev/eth0 on this linux box. Even if there were, the semantics of, say, a wifi card are not easily represented as a character or block device; you would be back to the morass of ioctl() calls (which you don't even seem to have heard of).

The only things that unix-like OSes expose as file-like objects are char devices and block devices. Almost everything else on the system is implemented by a system-specific interface. In MacOS X (and iOS, for that matter), it's a proprietary C++ structure called IOKit. In Linux, it's a series of kernel-defined interfaces to C code and syscalls. In other unix-like OSes, it's something completely different to that again. In Android, there's another entire layer of abstraction over even the non-file-like devices. All operating systems, even ones with unix-like semantics, have their own way of implementing access to the deeply non-file-like devices we have now.

It seems, however, that your experience with unix is rooted deeply in an early 1990s view of what Linux was like back then. Things have changed. Video cards are not framebuffers any more. Sound cards are not streaming DACs any more. Network interfaces are not char streams any more (and, in fact, haven't been even as far back as NET2 in Linux.)

James, trust me on this, j4cbo and I are right and you are wrong. Your basic premise is not-even-wrong, and hasn't even been wrong for many years.

[j4cbo]

It's true that Unix and C came from the same place at the same time and were designed approximately together by the same people.

This does not mean that C cannot exist without Unix. That's just false. You keep talking about "owners" and "permissions" which are core Unix concepts, but have nothing to do with C. Before you type anything else in reply, please, read the C standard.

Signs of rectal-cranial inversion, here...

[heroic]

The C standard has no concept of a file descriptor, and C programs- probably the majority of running C programs in the world, actually- can and do exist without a filesystem of any kind.

Go read the ISO C99 standard. Almost none of the stuff you cite is actually part of it.

[james]

Your basic premise is not-even-wrong, and hasn't even been wrong for many years.

That is a bizarre twist of words.