Related
Programming languages are platform independent, so why is it that we can't write a program that will run on both a PC and a Mac?
I want to develop a software and I'm on a mac, but I want it to run on a PC also, is it possible to develop such a software without having to require the user to download a special program that will make my program compatible with their computer?
The problem with this is that most software is dependent on the OS to handle some tasks. Yes, most programming languages are compatible with many platforms, but the OS provides a lot of support. When software uses the OS, it is sometimes called making a system call. If you want here is some more information.
Theoretically if you write your program in a 'high level language' it should be portable between two operating systems.
Practically however, the differences start from the very beginning - the API of choice, which works on one and does not on another(Such as, Mac's BSD API is incompatible with Win32 API) and boils down to the very last, which is, executable format, linker and loader. Each operating system has its own quirks.
Then comes the difference between the underlying architecture. Previously Macs ran on PowerPC architecture and Motorola architectures, while PCs used Intel. Since Macs have switched to Intel, there have been attempts at making cross platform executables inside Apple. Most attempts have failed.
There is however a way around your problem. You can use a very high level language such as Python to code and then distribute your python code to your PC friends.(But remember remember, you need a Python interpreter in your PC friends' computers for your program to run). I have successfully ported Python programs from Mac to PC with 0 code changes, and sometimes requiring only 2-4% code changes.
Simple answer: because language per se is not enough to make an application cross-platform. Also the framework it uses must be cross-platform too, frameworks are required for everything: handling data, displaying things, communicate with the hardware, multi threading, etc
This can usually be done:
by choosing a complete solution like Java, which will actually run on both platforms seamlessly and even with the same binary
by using C/C++ and cross platform libraries so that the same program can be compiled for both platforms (keep in mind that you can't distribute the real same binary, you need to compile two in any case)
by writing the logic of your program just using standard libraries and a standard language and then attach whatever you need for a specific platform just to build two different libraries. Of course you will have to wrap as much as you need so that the cross-platform part of your program doesn't know it
Mind that developing cross-platform applications which are not trivial examples like a game (for which there are plenty of cross-platform APIs) without using a complete solution like Java is not an easy task at all. Especially because most of the GUI you can build are strictly platform specific and relies on their own frameworks.
If you want an application to run "anywhere" your best option is a JIT type language which means that it compiles as it runs (Just In Time) for the platform that it's on. Really the language that stands out in my mind is Java (there's others and personally I don't like java). However, it's not quite that simple. For example a Window on a Mac computer has pieces and functions that a Window on a PC doesn't have and vice versa. And other operating systems don't even have windows or anything equivilant yet still run Java like Android or iOS for example or countless Linux Distros. And that's just a very basic example it gets MUCH MUCH harrier. Really the best way to build an application that can be used by anyone on just about any device is going web based.
The lesson is that if it was that simple a lot of people wouldn't have jobs and it never will be that simple, things will always progress and change and not everyone is going to want to do the same thing with their OS as someone else. There's a million ways to skin a cat and there's many more ways to implement something in an OS.
Yes, it is possible. But it is quite tricky. You need to:
Use a cross platform language (this is the easy part, many languages run on different plaftforms)
Avoid using any platform-specific features (usually not too hard, but needs testing)
Ensure you have cross platform libraries for all your dependencies (hard!)
Because of the library issue in particular, there are very few options that work across platforms. Your best options are probably:
A JVM language (like Java, Scala or Clojure) - because the JVM abstracts away from platform specific features, pure Java applications and libraries will run on any platform. Java probably has the best ecosystem of cross platform libraries and tools as a result.
JavaScript - quite a good option if you don't mind running in a browser. There are lots of quirks to deal with, but JavaScript is one of the best cross-platform options because of it's ubiquity.
Can the Ruby language be used to create an entire new mobile operating system or desktop operating system i.e. can it be used in system programming?
Well there are a few operating systems out there right now which use higher-level languages than C. Basically the ruby interpreter itself would need to be written in something low-level, and there would need to be some boot-loading code that loaded a fully-functional ruby interpreter into memory as a standalone kernel. Once the ruby interpreter is bootstrapped and running in kernel-mode (or one of the inner rings), there would be nothing stopping you from builing a whole OS on top of it.
Unfortunately, it would likely be very slow. Garbage collection for every OS function would probably be rather noticeable. The ruby interpreter would be responsible for basic things like task scheduling and the network stack, which using a garbage-collecting framework would slow things down considerably. To work around this, odds are good that the "performance critical" pieces would still be written in C.
So yes, technically speaking this is possible. But no one in their right mind would try it (queue crazy person in 3... 2...)
For all practical purposes: No.
While the language itself is not suited for such a task, it is imaginable (in some other universe ;-) that there a Ruby run-time developed with such a goal in mind.
The only "high level" -- yes, the quotes are there for a reason, I don't consider C very "high level" these days -- language I know of designed for Systems Programming is BitC. (Which is quite unlike Ruby.)
Happy coding.
Edit: Here is a list of "Lisp-based OSes". While not Ruby, the dynamically-typed/garbage-collected nature of (many) Lisp implementations makes for a favorable comparison: if those crazy Lispers can do/attempt it, then so can some Ruby fanatic ... or at least they can wish for it ;-) There is even a link to an OCaml OS on the list...
No, not directly
In the same way that Rails is built on top of Ruby, Ruby is built on top of the services that lower layers .. the real OS .. provide.
I suppose one could subset Ruby until it functionally resembled C and then build an OS out of that, but it wouldn't be worth it. Sure, it would have a nice if .. end but C syntax is perfectly usable and we already have C language systems. Also, operating systems don't handle character data very much, so all of the Ruby features to manipulate it wouldn't be as valuable in a kernel.
If we were starting from scratch today we might actually try (as various experimental projects have) to use garbage collected memory allocation in a kernel but we already have OS kernels.
People are making investments at the higher layers rather than redoing work already done. After all, with all the upper level software to run these days, a new kernel would need to present a compatible interface and the question would then be asked "why not just run the nice kernels we already have?".
Now, the application API for a mobile OS could indeed be done for Ruby. So, just as Android apps are written in Java, RubyPhone apps could be written in Ruby. But Ruby might not be the best possible starting point for a rich application platform. Its development so far has been oriented to server-side problems. There exist various graphical interface gems but I don't think they are widely used.
basically yes, but with a big disclamer .. which is basically Chris' answer but a different spin on it. Since for kernel performance it would kinda suck to use ruby, you'd probably want to build around a linux-ish kernel and just not load any of the rest of the operating system. This is basically what Android does: the kernel is a fork from Linux (and is maintained close to linux), the console is a webkit screen, and the interpreter is Java with some Android specific libraries. IE, Android is Java masquerading as an OS, .. you could do about the same thing with Ruby instead of Java and only a smallish hit to performance from java
While building a whole OS from scratch in Ruby seems like
a multi-billion project (think of all the drivers), a
linux kernel module that runs simple ruby scripts does
make sense for me - even it was only for prototyping
new linux drivers.
Greetings , I have a few questions that need experts' help to demystify it.
Question:
1.)Can a GUI be created without using any framework or API like GDI and DirectX??
2.)How microsoft develop the GUI environment for his OS??
3.)Is it possible that I could get knowledge about creating a GUI which run during booting without relying on an OS??Does it require any special tools which we do not own at home but is available in microsoft??
4.)Any book recommended for me to know more about GUI development of OS like windows and linux??
Thanks for spending time reading my question , your help is much appreciated
I'm not an expert on this field but to my knowledge:
Without considering your question #3, Yes, use a programming language (PL), but if you consider PL's as framework then NO, or even if it's possible, it is certainly not practical. Even Assembly (machine language) is a programming language.
To help understand the answer to this question, I suggest you read what an operating system is and how it is created. MS Windows (depending on the version) is written using PL: C, C++, C#, and Assembly. They used what we consider now as "low-level" programming to create their GUI's.
I find this question conflicting, I believe you need an OS to run a GUI. Because an operating system is responsible for connecting your hardware together (e.g. where to output the display, where to get the inputs like keyboard and mouse, etc). If you want, create an OS yourself but again, I find this very impractical. What you can do is start learning how to create GUI from Linux or even build your own minimalistic OS from Linux from Scratch. I recommended Linux because it's free and mature (relatively stable, has tons of documentation and internet references)!
I can't recommend any specific book, but types of book: Programming Languages and Operating Systems. Also, you can find all the resources you need on the internet. You just need to know exactly what questions you are looking an answer for.
But if you simply want to create a GUI that can run on most Operating Systems, this has been the aim of Java. Java uses a virtual machine to do this. Of course there are other options too, you can research about it. If it's already available that suits your needs and it's legally free, use it. It will save you a lot of effort. :)
If a particular piece of software is made to be run on one platform and the programmer/company/whatever wants to port it to the other, what exactly is done? I mean, do they just rewrite linux or windows-specific references to the equivalent in the other? Or is an entire rewrite necessary?
Just trying to understand what makes it so cost-prohibitive that so many major vendors don't port their software to Linux (specifically thinking about Adobe)
Thanks
this is the point of a cross-platform toolkit like qt or gtk, they provide a platform-agnostic API, which delegates to whichever platform the program is compiled for.
some companies don't use such a toolkit, and write their own (for whatever reason - could well be optimisation-related), meaning they can't just recompile their code for another os.
There are also libraries available that ease, at least on a specific area, the port of Windows API calls to Linux. See the Windows to Linux porting library.
In my experience, there are three main reasons why it's cost-prohibitive to take a large existing program on one platform and port it to another:
it has (not necessarily purposely) extensively used some library or API (often GUI, but there are also plenty of other things) that turns out not to exist on the other platform
it has unknowingly become riddled with dependency on nonstandard features or oddities of the compiler or other tools
it was written by somebody who didn't know that you had to use some oddball feature to get things to work on the other platform (like a Linux library that isn't sprinkled with the right __declspec directives you need for a good Windows DLL).
It's much easier to write a cross-platform app if you consider that a design goal from the start, and I have three specific recommendations:
Use Boost—oodles of handy things you might ordinarily get from platform-specific APIs and libraries, but by using Boost you get it cross-platform.
Do all your GUI programming using a cross-platform library. My favorite these days is Qt, but there are other worthy ones as well.
Build and test every day on both platforms, never provide an opportunity for the code to develop a dependency on only one platform and discover it only too late.
There are many reasons why it may be very difficult to port an application to a different platform, most often it is because some interfaces the application uses to communicate with the system are not available, and one either has to implement them on their own, port a library your application depends on, or rewrite the application, so that it uses alternative functions. Most languages today are very portable across hardware architectures and operating systems, but the problem is with libraries, system calls and potentially other interfaces the OS (or platform) provides. To be more specific:
Compilers may differ in their configuration and the standard functions they provide. On Windows the most popular compiler for C/C++ is Visual Studio, while on unix it is gcc and llvm (in combination with the standard library glibc or BSD libc). They expect different flags, different forms of declaration, produce different file format of executables and shared libraries. Even though C and C++ have standard libraries, they are implemented differently across platforms. There are some systems whose aim is to make compilation portable, such as Autotools, CMake and SCons.
On top of standard libraries there are additional functions OS provides. On Windows they are covered by win32 API, on unix systems these are part of the POSIX standard, with various GNU, BSD and Linux specific extensions, and there are also plain system calls (the lowest-level interface between applications and the operating system). POSIX functions are available on Windows via systems such as cygwin and mingw, win32 API function are available on unix via Wine. The problem is that these implementations are not complete, and often there are minor (but important) differences.
Communication with the desktop system (in order to make a GUI interface) is done differently. On Linux this might be the X Window System (together with freedesktop libraries) or Wayland, while Windows has its own systems. There are GUI libraries which try to provide an abstract interface for these, such as Qt, GTK, wxWidgets, EFL.
Other services the OS provides, such as network communication may be implemented differently. On Windows many applications use .NET libraries, for which there is only limited support on unix systems. Some unix applications rely on Linux-specific features such as systemd, /proc, KMS, cgroups, namespaces. This limits portability even among unix systems (Linux, BSD systems, Mac OS X, ...). Even .NET libraries are not very compatible across different versions, and they might not be available on an older version of Windows or on embedded systems. Android and iOS have different interfaces entirely.
Web applications are usually the most portable, but HTML5 is a live standard, and many interfaces may not be available yet in some browsers/web engines. This requires the use of polyfills, but it is usually much less painful than the situation with "native" applications.
Because of all of these limitations, porting can be a pretty hard work and sometimes it is easier to create a new application from scratch, either specifically for the other platform, using cross-platform abstraction libraries/platforms (such as Qt or Java), or as a web application (potentially bundled in something like Electron). It is a good idea to use these from the beginning, but many programmers choose not to because the applications tend to look and behave differently from "native" applications on the platform, and they might also be slower and more restricted in the way they interact with the OS.
Porting a piece of software that has not been made platform-independant upfront can be an enormous task. Often, the code is deeply ingrained with non-portable APIs, whether 3rd party or just OS libraries. If the 3rd party vendor does not provide the API for the platform you are porting on, you are pretty much forced into a full rewrite of that functionality, or finding another 3rd party that is portable. This only can be awfully costly.
Finally, porting software also means supporting it on another platform, which means hiring some specialists, and training support to answer more complex queries.
In the end, such a process can be very costly, for very little additional sales. Sadly, the decision is easy: concentrate on new functionality on your current platform that you know your customers are going to pay for.
If the software was written for a single OS, a major rework is likely. The first step is to move absolutely all platform-specific code into a single area of the code base; this area should have little or no app-specific stuff. Then rewrite this isolated portion of the code for the new target OS.
Of course, this glosses over some extremely major implications. For instance, if your first version targeted the Win32 API, then any GUI code will be heavily tied to Windows, and to maintain any hope of preserving your sanity, you will need to move all that code to a cross-platform GUI framework like Qt or GTK.
Under Mono, you can write a C# Winforms program that works on both platforms. But to make that possible, the Mono team had to write their own Winforms library that essentially duplicates all of the functions of Winforms. So there is still no free lunch.
Most software is portable to some extent. In the case of a C app - there will be a lot of #ifdefs in the area, apart from path changes, etc.
Rarely windows/linux version of the same software don't share a common codebase - this would actually mean that they only share a common name. It's always harder to maintain more codebases, but I think that the actual problem with porting applications has little to do with the technical side and a lot with business side. Linux has much fewer users that Windows/OSX, most of them expect everything to be free as in beer or simply hate commercial software on some religious grounds.
When you come to think about it - most open source software is multiplatform, no matter what language was used to implement it. This speaks for itself...
P.S. Disclaimer - I'm an avid supporter of Free and Open source software, I don't want to insult anybody - I just share my perspective on the topic.
Ok, this is an interesting question to ask because everyone has a say in it.
What is your favorite library to program in for GUI's and the language that you program it in. Give a short reason why. (ex. Gtk, Qt, Windows, etc..) Just an FYI, this includes any scripting language that you program a GUI in Python, Perl etc...
Frankly I've always done Gtk in C, but I'm starting to warm up to Qt in C++ with the new KDE. I've never been a big fan of Windows programming.
ChrisW. stated that I did not give a reason for Gtk/Qt so here goes. I started with Gtk because when I started programming GUI's I was working in Linux and there was more Gtk information available. Started utilizing Qt when I started working more in KDE but really the move to Qt was based on trying to move to C++ and learn more languages. I've never been a fan of basic Windows programming, but I do enjoy a little DirectX now and then :P
Recently I had the opportunity to work with both wxWindows and QT, while some time ago I wrote some small programs using FLTK and Gtk. My conclusion is that widget libraries tend to be very similar; each one has its strenghts and its quirks.
Instead of advocating a specific library, then, I would like to advocate the use of high level languages in GUI programming: the development cycle is way faster and GUI programs are rarely CPU bound, so the performance hit is rarely a problem.
If a GUI program has to perform some intense computations, just develop a core library in C or C++, but keep the interface in Python or whatever other interpreted language.
People like to bash Swing for being old, slow and ugly, but it's just not true. Swing is mature, is faster than ever on Java SE 6/10, looks decent enough, and is tolerable to program. Above all, I've found Java + Swing to be the most trouble-free cross-platform combination. It also works remarkably seamlessly with Jython (Python on JVM).
SWT could also be an option, but so far I've been happy with Swing.
I realise you're focusing on application GUIs but if you want a quick, powerful and fun way to visualize anything on your computer, you can't go past Processing
From the site:
Processing is an open source
programming language and environment
for people who want to program images,
animation, and interactions. It is
used by students, artists, designers,
researchers, and hobbyists for
learning, prototyping, and production.
It is created to teach fundamentals of
computer programming within a visual
context and to serve as a software
sketchbook and professional production
tool. Processing is an alternative to
proprietary software tools in the same
domain.
WPF in particular, and XAML in all its reincarnations (WPF, Silverlight, Moonlight).
C# on top of .Net 3.5/Mono: $0
Visual Studio Express/MonoDevelop: $0
Being able to tell the designer "make my program pretty" and continue coding features: priceless.
I liked writing to video memory under DOS: for an animated game (i.e. an Asteroids clone), that was as fast (performant) as I knew how to do it (certainly faster that using the BIOS API).
This is really a somewhat subjective question, so there is no best or correct answer to it. The following is based on my (limited) experience:
I personally like wxWidgets with PLT Scheme for writing simple but flexible GUIs. There are much more advanced toolkits, but I usually do not need their features. wxWidgets is flexible and the Scheme interface follows Scheme traditions of being powerful with a relatively simple structure. I like the fact that wxWidgets is portable, and yet tries not to actually draw its own widgets, but can use native or common toolkits of the environment it is used under. It is written in C++ but I never used its C++ interface.
That is not to say that in my opinion Scheme will generally be the optimal language to write your application in. In fact there are many kinds of applications I would not write in Scheme, even though I like the language. But regarding the GUI programming part, that is my favourite because of its straight-forwardness, and the way that a functional language like Scheme goes well with declarative-style GUI programming.
Of course you will not have the same level of control when using that as when having your program involved in every stage of the window construction and input reaction, by using an event loop (such as with Win32API or Xt/Intrinsics). But that is not always convenient and often unnecessary, and seems to become decreasingly common.
Note: The wxWindows toolkit was renamed wxWidgets, but my installation of a rather recent version of PLT Scheme still comes with the older wxWindows. I am not sure whether there is an updated package of wxWidgets available or if it is going to be included in a future version of PLT Scheme.
Qt4 without question for me. Now that it has an LGPL license it makes sense for all kinds of applications that previously weren't possible. Additionally, it changes C++ in ways that dramatically improve the experience of using the language. (Things like a foreach and forever loop, atomic operations on integers, and memory management)
Gtk and is the primary window-drawing graphical subsystem I have experience working with (and is therefore my favorite XD).
As far as general graphics subsystems go, however, OpenGL (typically in combination with GLUT) has been an easy and productive ride for me. Regrettably I have little DirectX experience to compare to, though :S
For writing souped-up versions of standard Windows components, I loved Borland's VCL, and am very pleased with .NET.