This is a question that I have long been wanting answered.
Major operating systems such as Windows and Mac OS X generally only "support" one or a few languages (i.e. C++, C#, VB for Windows, Objective-C for Mac OS X).
Using the Go language as an example, it's obviously possible to interact with the operating system and make calls to these functions without using the "supported" languages.
How is this possible?
What does a developer need to know in order to call these system functions using the language of his choice?
I'm looking for how these calls are represented in code - and how they are then used upon execution.
I expect that there isn't one answer that fits every language-system combination... but a few different examples would be helpful.
The ABI (Application Binary Interface) defines how to make a call to the operating system. To be able to make those calls requires the particular programming language implementation to generate code conforming to that ABI.
Making OS calls in C is well-supported, and many interpreted languages (e.g., perl, python, tcl) are implemented in C, so they are in essence making the calls via C.
Related
Do interpreted languages such as Java and Python need an operating system to work?
For example, on a bare-metal ARM microcontroller, can an interpreter be installed such that we can have both compiled code such as C, and interpreted code such as Python working together, Or is an OS needed to support this?
Of course you can write an interpreter that runs on bare-metal, it is just that if the platform does not have an OS any run-time support the language needs must be part of the interpreter. To the extent in some cases that such an interpreter might essentially be an OS. That is if it provides the services to operate a system, it could be called an operating system.
It is not perhaps as simple as interpreted vs compiled. Java for example runs on a virtual machine and is "compiled" to bytecode. The bytecode is interpreted (or just-in-time compiled in some cases), rather then the Java source directly. In an embedded system, it is possible that you would deploy cross-compiled bytecode on the target rather then the source. Certainly however JVMs exist for bare-metal. Some support multi-threading through a third party RTOS, others either have that support built-in or do not support threading at all.
There are interpreters for cut-down subsets of JavaScript and Python that run on bare-metal microcontrollers. I am not sure about full implementations, but it is technically possible given sufficient run-time support even if not explicitly implemented. To fully support some of these languages along with all the standard and third-party libraries and frameworks a developer might expect, may require so much run-time support and resource that it is simpler to deploy and OS, so implementations for resource constrained systems are often subsets or have restricted libraries.
Java needs a VM - virtual machine. It isn't interpreted, but executes byte code. Interpreted would mean grabbing the source in run-time as it goes, like BASIC.
When Java was new and exciting around year 2000, everyone thought it would be the next big general-purpose language, replacing C++. The syntax was so clean, it was "pure OO" and not some "filthy hybrid".
It was the major buzz word of the time. Schools stopped teaching C and C++. MCU manufacturers started to make chips with Java VM in hardware. Microsoft made their own Java "standard". Everyone was high on the Java hype.
Then as the Internet hype as whole collapsed in 2002, it took the Java hype with it. In the sober hang-over afterwards, people started to realize that things like byte code, VMs and garbage collection probably don't belong on bare metal systems.
They went back to using compiled C for hardware-related programming. Or in fact they never stopped, since Java never quite made it there, save for some oddball exotic architectures.
Java remained used only in the areas were it was suitable, namely web, desktop and mobile development. And so it got a second golden age when the smart phone hype struck around 2010.
No. See for example picoJava, which is one of several solutions for running Java natively. You can't get closer to bare metal than running bytecode on the CPU.
No. Some 8-bit computers had interpreted languages in ROM despite not having anything reasonably resembling a modern operating system. The Apple 2 is one example. You could boot the system without any disks or tapes, and it would go straight to a BASIC prompt, where you could write basic (no pun intended) programs.
Note that an operating system is somewhat of a vague term when speaking about these days - these 8-bit computers did have some level of firmware, and this firmware did provide some OS-type functionality like access to basic peripherals. In these days, what we now know as an OS was more commonly called a "DOS" - a Disk Operating System. MS-DOS is one of them, as well as Apple's ProDOS. These DOS's evolved into our modern-day operating systems (e.g. Windows 95 was based on top of MS-DOS, while modern Windows versions derive from a separate branch that was largely re-implemented with more modern techniques), so one could claim that their ancestors are the closest they had to what we now call an OS.
But what is an interpreter but a piece of software?
In a more theoretical sense, an interpreter is simply software - a program that takes input and produces output. Suppose you were to implement a custom solid-state Turing Machine. In this case, your "input" would be the program to be interpreted, and the "output" would be the program's behavior. If "software" can run without an operating system, then an interpreter can.
Is this model a little simplified? Of course. The difference is a matter of degree, not nature. Add very basic user input and output capabilities (e.g. a TTY) and you have the foundation to implement all, or nearly all, of the basic functionality of a language such as Java byte code, Python, or BASIC. The main things you would be missing are libraries and whatnot that depend on things like screen manipulation, multiprocessing, and networking, but you could handle them with time too.
I am trying to create my own programming language but I am already thinking ahead a little.
Of course when I can compile a little program I won't have a Standart Library at that time,
and you'd have to create one yourself. Now take for example I'd like to add some functionality to print a string to the screen, I am pretty sure I'd have to do a few System Calls to the operating system to get this displayed.
So to the point: What would be the best way to interact with the Operating System?
Possibilities I came up with myself:
- Generate Object Files and link those to the (for example) C Standart Library
- Writing the files with embedded assembly language containing System Calls
I have a feeling there are better possibilities!
I hope you can help me,
Christian
EDIT: It's a compiled language I am creating!
You have basically two options, like you say yourself. You can link your standard library with the standard C library, so that the I/O functions in your standard library can use C functions. Alternatively you can make system calls to the operating system directly.
The second approach seems like it's going to be more work: The system calls will be different on each operating system, so you'll have to put a lot of work into porting your system. The system calls may not be well documented, causing many frustrations.
You could start by linking your standard library to the C standard library and worry about other aspects of your language for the moment. Later you can look into replacing the C functions you use with syscalls.
Stdin and stdout are pretty much the minimum - if you are using a Unix environment you can then gain access to they keyboard, command line and also pipe text in and out to files.
If you are writing a new language - then StdError may also be worth considering too!
This question may sound stupid but i couldn't find a real answer so here it is:
In what programming language are OSs programmed?
In what language is OpenBSD programmed?
Can you programm and operating in every scripting language (Ruby, Python,...etc)?
Most operating systems are programmed in C. Some parts of some operating systems may use C++ or Objective C as well. Also, operating systems must have some assembly in them.
Although you can theoretically program parts of an OS in a scripting language, it would not be so easy. At least some of the OS would need to be compiled to native code. However, the operating system might have a built in interpreter for a scripting language or virtual machine for bytecode. Then you could write, for example, device drivers in the scripting language, where the driver presents a certain interface to the OS. You could also maybe write scheduling policies, paging systems, etc. in the scripting language. Basically your scripting language would provide a nice way to quickly prototype and test new modules and OS concepts. However, I wouldn't recommend such a system for production environment because you usually take a performance hit with the types of languages that you mention.
I am not aware of any operating system that uses anything like this. I am vaguely aware that some research OSes have been developed that used similar ideas, though I can't name any off the top of my head.
When and especially why should I switch from Objective-C to C or C++ when I develop on iOS platform. I'm sure I'm missing something but as far as I can see Apple wants developers to use Objective-C everywhere in Mac/iOS environment so why would I go with C/C++?
One note, though, I'm NOT talking about GAME DEVELOPMENT. In case of games I realize what are the advantages. I just don't get when I want to use C if I develop, for example, a client for a server or something like that (once again, not a game). All the classes I need already there and all of them in Objective-C.
Objective C is a strict superset of ANSI C, so an Objective C programmer is very likely already doing a significant amount of programming in C. In fact, many Mac and iOS APIs (audio, graphics, etc.) are C interfaces and/or use C data types.
A few of the reasons to do something in C, of things that are possible in both the superset and subset languages, might include performance and portability. There is a small amount of runtime overhead to Objective C messaging that is completely unsuitable for the inner loops of real-time audio or video image processing, etc. For portability, one can often use well encapsulated C code in iOS, Linux, Android NDKs, WebOS PDKs, & etc. And occasionally the Objective C wrappers for an OS service won't offer all the flexibility of some underlying C API.
The only reason I can see to use C++ for an iOS app might be to use some legacy C++ code and maintain some consistency of style with that code for readability, maintainability, etc.
For an iOS app where performance, or any portable code reuse is not important, there are few reasons to not just use Objective C (with its included C language), as that is what the most current documentation, tools, frameworks, and APIs for iOS are supported on.
The main advantage is portability. A chunk of code written in C++ or C can, when appropriate measures are taken, be very easily wrapped up and used in iOS or Android, or Blackberry, etc... Many 3rd party libraries go this route for that reason (Zebra Crossing and OpenCV come to mind immediately).
Another reason (and I would argue bad reason) is simply that a developer is comfortable in C or C++ and wants to avoid learning Objective-C as much as possible.
The only reasons I can think of are (a) you have an existing C++ codebase that you want to re-use (and don't want to have to rewrite it all in Objective C), or (b) you really like C++ and/or really don't like Objective C.
Why not mix and match as you like. The compiler supports "objective c++". Not sure that it supports C++11 features in such a mode, but it should support C++98 well. I think all that is required is that you change the naming of your source files from ".m" to ".mm". (This is all from memory and could be inaccurate).
As to the "why". Some apple APIs had more features in one language than the other. For example it used to be (and may still be) that a bunch of the graphics / quicktime functionality was only available through the cocoa interfaces, and not the objective C interfaces.
It is even more likely that some third party libraries may only be available in one language.
Why did Apple decide to use Objective-C for the iPhone SDK and not C++?
It seems strange to me that they would not have chosen a language more popular than Objective-C. Is it because wanted to have something unique in their application which is not otherwise in general use?
Apple merged with NeXT in the '90s and Mac OS X was made from NeXT's operating system, NeXTSTEP. Objective-C was the official language of NeXTSTEP's application frameworks, which became Mac OS X's Cocoa. Mac OS X was then adapted into the iPhone OS, and Cocoa was made into Cocoa Touch. Objective-C has held up pretty well all along the way, and a lot of Cocoa's features would be difficult to translate into C++.
So essentially, it all comes from NeXT.
Objective C began life in 1983 I believe, created by Brad Cox and Tom Love. The idea of Objective-C was to take the purity and low-level control of C and merge that with true object-oriented features that would allow companies to customize system libraries that could communicate with the OOP layer of Obj-C. Essentially, it worked. Obj-C is a strict superset of C, unlike C++ which is most of C, but with many differences.
When Steve Jobs founded NeXT Computer (1985), he brought in some of his former Apple team and others. His best programmers were interested in using a language that expanded on C with the same speed benefits and system control. They chose Objective-C. NeXT eventually wrote many libraries and methods for the base language. These all begin with NS for Next Step. This was the name of the NeXT OS. By 1989 the Next Step OS was considered to be vastly superior to MS Windows or Mac OS, and many computer companies wanted to license it badly. Jobs simply didn't want to go in that direction.
Once Apple wised up and brought Steve Jobs back into the fold (1996), the infusion of Next Step OS into the new Mac OS X was really the key to Apple reviving its software and its programming strategy.
While C++ remains a truly excellent and powerful language, I find that Objective C has less flaws (just my opinion), and Apple's continued work on Cocoa libraries has made the Obj-C language a truly modern power with C underpinnings. Is it better than Java? Not sure. But for what it is primarily designed for (Mac OS, iOS) it is astonishingly good, if a bit overly verbose.
The greatest criticism of Obj-C is the syntactical styling, but any programmer that truly learns the language will quickly learn of its amazing power and seemless fit with all things Mac, iPhone, iPad.
Will any other platforms ultimately adopt Obj-C? not sure, but doubtful. But the Cocoa libraries are truly wonderful.
It's because Objective C has been the de facto language for Mac OS X development before it was Mac OS X. When Jobs left Apple to set up NeXT, the language Objective C was developed as a specific language that wasn't C++ and avoided many of its pitfalls. It therefore makes sense that any portable or consumer equipment (including Apple TV) use Objective C as their primary development language, and dropping down to the underlying C layer when needed for performance or interface issues.
Objective-C adds object oriented programming to C. It was used for NeXT, upon which a lot of OSX is derived. It supports all of C, and is simpler than C++.
http://discussions.apple.com/thread.jspa?threadID=2091191
Note that Objective-C is not a new language. It's been around since 1986 - well before Java or C#!
It has been in general use ever since NeXT, many real-world applications are around that make use of it.
Apple answered this very question here in 2010:
The Objective-C language was chosen for a variety of reasons. First
and foremost, it’s an object-oriented language. The kind of
functionality that’s packaged in the Cocoa frameworks can only be
delivered through object-oriented techniques. Second, because
Objective-C is an extension of standard ANSI C, existing C programs
can be adapted to use the software frameworks without losing any of
the work that went into their original development. Because
Objective-C incorporates C, you get all the benefits of C when working
within Objective-C. You can choose when to do something in an
object-oriented way (define a new class, for example) and when to
stick to procedural programming techniques (define a structure and
some functions instead of a class).
Moreover, Objective-C is a fundamentally simple language. Its syntax
is small, unambiguous, and easy to learn. Object-oriented programming,
with its self-conscious terminology and emphasis on abstract design,
often presents a steep learning curve to new recruits. A
well-organized language like Objective-C can make becoming a
proficient object-oriented programmer that much less difficult.
Compared to other object-oriented languages based on C, Objective-C is
very dynamic. The compiler preserves a great deal of information about
the objects themselves for use at runtime. Decisions that otherwise
might be made at compile time can be postponed until the program is
running. Dynamism gives Objective-C programs unusual flexibility and
power. For example, it yields two big benefits that are hard to get
with other nominally object-oriented languages:
Objective-C supports an open style of dynamic binding, a style that
can accommodate a simple architecture for interactive user interfaces.
Messages are not necessarily constrained by either the class of the
receiver or even the method name, so a software framework can allow
for user choices at runtime and permit developers freedom of
expression in their design. (Terminology such as dynamic binding,
message, class, and receiver are explained in due course in this
document.) Dynamism enables the construction of sophisticated
development tools. An interface to the runtime system provides access
to information about running applications, so it’s possible to develop
tools that monitor, intervene, and reveal the underlying structure and
activity of Objective-C applications.
Historical note: As a language, Objective-C has a long history. It was
created at the Stepstone company in the early 1980s by Brad Cox and
Tom Love. It was licensed by NeXT Computer Inc. in the late 1980s to
develop the NeXTStep frameworks that preceded Cocoa. NeXT extended the
language in several ways, for example, with the addition of protocols.