How can I compile a C++ program with a command-line interface and use it under Android 2.3.5 on my phone?
No - the model is completely different. Simple C++ programs are single threaded - they do whatever they have to do as quickly as they can in a single thread of execution and if they have to wait or block on something like retrieving data from the network then they just have to wait. They are given timeslices by a multitasking operating system and when they're finished they're finished.
In Android there is always one thread running which handles GUI interactions and passes the results into 'hooks' in your Activity instance. Anything that might block the GUI thread has to be farmed out to another thread, and call back on another method in your Activity. It's event-driven, and you have remarkably little control or certainty about things like object lifetime. So you need to program in a completely different way.
An emulator of some kind running as an Android app could - in principle - run C++ binaries compiled for a specific VM. But as far as I'm aware such an app doesn't exist and neither does the toolchain to produce such binaries. Google have discouraged such an approach too AFAIK. There are fully-fledged computer emulators but for obvious reasons they're mainly old 8-bit nostalgia fests :)
I'm a C++ programmer who recently got involved in Android programming and I'd recommend it. You'll think about programs in a different way from the single-threaded IFTT way you may be used to.
Related
I am trying to understand how code, regardless of the language, works. Specifically thinking about software that runs on Windows.
Is my understanding correct that every built in function of a particular language maps to an exposed function in the Windows API when writing software for the Windows platform?
I guess my question can be even more generally, can a language do anything outside of what the OS provides? If so, how? What is an example of this?
There is a theoretical and a practical answer to this.
Practical: yes.
The WinAPI is the API everything uses to do things on Windows. It’s stable and compatible between versions so you can write whatever you want with it and it will work on practically any version of Windows given you don’t use any APIs that aren’t present in an old version. There isn’t any other interface to talk to the operating system properly.
Any language or platform that wants to work on top of this will call WinAPI. C libraries, Python, etc all are written so that they work on top of it (often other languages use C or C++ libraries which use WinAPI).
Theoretical: no.
Windows itself includes a Native API which is the actual OS interface and WinAPI is built on top of this. It is not really used if it’s not necessary since it’s not really documented. It’s used in a couple of Windows components that need to run before the other parts of the system are running and you can build applications linking to this API. But since it’s undocumented it’s not really reasonable and may change whenever.
There is also the syscall level. Several Windows components provide the lower level services for operations done on the WinAPI level. You can write, for example, an assembly program and use the syscalls directly if you want to. Mostly you don’t want to so this is more of a theoretical rather than practical answer to different platforms communicating with the OS. These also may change based on the OS.
WinAPI is basically only one subsystem that runs on the NT kernel. For example, Windows Subsystem for Linux is another one which implements its own syscalls which are then translated to Windows ones. There has also been a POSIX subsystem previously.
So all in all it depends on which level you look at it, but the practical answer is yes. Everything practically runs on WinAPI.
Yes. Even if an application exits immediately, it uses a windows call.
So it is not only theoretical. In theory, as in practice, every Windows application uses the API, because there is nothing else to use.
Even if you try to rewrite each functionality you are about to use, you would eventually have to install a driver, and this also mean you would use the API.
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.
How are operating systems typically debugged? They cannot be stepped through with a debugger like simple console programs, and the build times are too large to repeatedly make small changes and recompile the whole thing.
They aren't debugged as a multi-gigabyte programs! :)
If you mean the individual user-mode components, they can mainly be debugged just like normal programs and libraries (because they are normal programs/libraries!).
For kernel-mode components, though, each OS has its own mechanism; here is some information regarding the way that we do kernel debugging in Windows. It can be done using the help of another machine connected to the machine you're debugging, via a serial port or something. I'm not familiar with the process itself, but that's the gist of how they work. (You need to set some boot loader options so that the system is ready for the debugger to be connected as early as possible.)
It depends on which part of the operating system you're talking about. When I worked at MSFT, I worked on the IE team. We debugged IE and the shell (Windows Explorer) in Visual Studio and stepped through them line by line all day long. Though, sometimes, it's easier to debug using a command line tool such as NTSD.
If, however, you want to debug anything in Kernel land such as the OS kernel or device drivers, which I suspect is really what you're asking, then you must use the Kernel debugger. For Windows that is a command line tool called kd, and generally you run the debugger on one machine and remotely debug the target.
There are a whole set of techniques throughout history from flashing lights on the console, to the use of hardware devices like an ICE, to more modern techniques utilizing fairly standard debuggers. One technique that is more common among OS developers then application developers is the analysis of a core dump. Look at something like mdb on solaris for ideas about how Solaris kernel developers do some of their debugging. Also tracing technologies are used. Anywhere from fairly straightforward logging packages to more modern techniques like dtrace.
Also note that the techniques used depend on the layer of software. Initial boot tends to be a fairly hard place to get your fingers into. But after that the environment of modern operation systems looks more and more like the application setting you are use to. In the end, it is all code :)
I am into new project, which should use microcontroller. The easiest way to program it is using parallel port. But, there are few things I hope you can help me with. Oh, and the preferred language is C and platform Windows.
So, I studied LPT ports and Windows a bit, and from what I learned the most important is: Since Windows NT based systems, you cannot use instructions for direct port manipulation. This should be, because now programs are run in different privilege mode, which doesn't support the kind of instructions that are used by outport() function.
But at this point, I don´t understand a few things. First, I thought that Windows actually used privilege levels since first protected mode version, but that's the wrong assumption.
But more importantly, I thought that Windows has included functions for just about any hardware communication. I mean, anything you do in Windows these days, you just call windows functions which further call kernel services. I assumed that outport() doesn´t use any Windows function, and just makes the communication itself, which is prohibited now. But I am literally shocked that there is no system function to control parallel ports in modern Windows systems. At least that's what I read.
But even if I could get the control of parallel port, there comes my second problem.
For programming the controller, I need to follow special protocol, especially timing. But since Windows is multitasked, I worry about what if Scheduler switches to another app, and therefore when is the right time to switch signals on LPT, my program just will not be able to run.
Oh, by the way, I know I could use any 3rd-party apps, but I just like to be able to do it myself, or at least before I use some 3rd-party app, I want to know how it works. And yes, you can program some microcontrollers just by parallel port with some resistors, I know this for sure.
Thanks.
For windows you need to install a DLL which contains a driver to run at elevated privileges to get access to the HW ports.
You can find such a library at :
http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html
There are also some links to sample code.
I do not know which uController you are using, but I programmed in the past a variety of them and never had issues with timings, well for programming at least. The programming protocols are usually robust enough to deal with the jitter caused by multitasking. Just keep your clock edges and signa edges well separated and it should go fine.
I would like a low-overhead method of monitoring the I/O of a Windows process.
I got several useful answers to Monitoring certain system calls done by a process in Windows. The most promising was about using Windows Performance Toolkit to get a kernel event trace. All necessary information can indeed be pulled from there, but the WPT is a massive overkill for what I need and subsequently has a prohibitive overhead.
My idea was to implement an alternative approach to detecting C/C++ dependency graphs. Usually this is done by passing an option to the compiler (-M, for example). This works fine for compilers and tools which have such an option, but not all of them do, and those who do often implement them differently. So, I implemented an alternative way of doing this on Linux using strace to detect which files are opened. Running gcc (for example) in this way has a 50% overhead (ballpark figure), and I was hoping to figure out a way to do this on windows with a similarish overhead.
The xperf set of tools have two issues which prevents me from using them in this case:
There is no way to monitor file-I/O events for a single process; I have to use the kernel event trace which traces every single process and thus generates huge amounts of data (15Mb for the time it takes to run gcc, YMMV).
As a result of having to use the kernel event trace, I have to run as administrator.
I really don't need events at the kernel level; I suppose I could manage just as well if I could just monitor, say, the Win32 API call CreateFile(), and possibly CreateProcess() if I want to catch forked processes.
Any clever ideas?
Use API hooking. Hooking NtCreateFile and a few other calls in ntdll should be enough. I've had good experience using easyhook as a framework to do the hooking itself - free and open source. Even supports managed hooking (c# etc) if you wanted to do that. It's quite easy to set up.
It's at located at http://easyhook.codeplex.com
Edit: btw detours does not allow 64 bit hooking (unless you buy a license for a nominal price of 10,000USD)
EasyHook does not allow native hooks across a WOW64 boundary. It allows managed hooking across WOW64 boundaries though.
I used Microsoft's Detours in the past to track memory allocations by intercepting particular API calls. You could use it to track CreateFile and CreateProcess.
It seems like Dr. Memory's System Call Tracer for Windows is exactly what I was looking for. It is basically a strace implementation for Windows.