I learnt that c++ has many low level access to hardware so we write drivers in c++. But when we write a normal desktop application in c++, will it be able to access hardware directly?
I'm asking this because desktop applications runs on the application layer. OS layer and OEM layer are there Between App layer and Hardware. then how can our application written in c++ access hardware directly?
please somebody explain me how exactly c++ desktop apps works.
thanks.
In general, desktop applications have to go through the OS to access any resources, from extra memory to hard drives and sound chips.
In an embedded system, the hardware can be accessed directly, usually through a pointer. So to write to a UART register, one would assign the address of the register to a pointer and dereference the pointer.
Many compiler libraries provide support for various platforms and embedded systems. I'm using an IAR compiler for an ARM embedded system and programming with C++. We don't use streams since we don't have terminal I/O.
Edit 1: cout example
For example, to print to the console, via cout or printf, the compiler provides a library that calls Operating System functions to display the text.
The Operating System function may send the text directly to the console or may pop up a "console window" and send the text to that.
The Console functions convert the text to bitmaps and send the bitmaps to the Graphics Controller.
The Graphics Controller displays the bitmap on the screen.
Related
I want to write a program that will monitor memory in a driver and print the memory contents every so often.
However, I'm not finding any resources in the Windows API that seem to allow me to grab a pointer (Handle) to a specific driver.
I'd appreciate any answer either from User space OR kernel space.
If you want to know exactly what I'm doing, I'm attempting to duplicate the results from this paper except on Windows. After I gain the ability to monitor a buffer in a basic windows console program, I intend to monitor from the GPU.
[For the record: I am a Graduate Student who is pursuing this as a summer project... this is ethical malware research.]
============UPDATE ==================
This might technically be better suited as an answer, but not really until I have a working solution.
My initial plan of attack is to use WinDbg to do dynamic analysis on the keyboard driver when it gets loaded, so I can get some idea about normal loading/unloading behavior. I'm using chapter 10 of this book, to guide setting up my testbed and once I understand more about the keyboard structure and its buffer, I'll work backwards towards getting a permanent reference to this structure and see about passing it into the graphics card and monitoring it with DMA as the original paper did on Linux.
You won't solve this problem by "grabbing a pointer to a specific driver". You need to locate the specific buffer used by the keyboard driver that resides on top of the USB driver.
You will have to actually grok the keyboard and USB drivers for Windows. At least part of which is probably available if you have a DDK (driver development kit) [aka WDK, Windows Driver Kit]. You will definitely need a graphics driver for this part of the project.
You will also have to develop a driver mechanism to map an arbitrary (kernel) lump of memory to your graphics driver - which means you need access to the source code for the graphics driver. (In theory, you could perhaps hack about in the page-tables, but Windows itself isn't too keen on software messing with the page-tables, and you'd definitely need to be VERY careful if the system is SMP, since modifying page-tables in an SMP system requires that you flush the TLB's of the "other" CPU(cores) in the system after updates).
To me, this seems like a rather interesting project, but a really tough one in a closed source system like Windows. At least in Linux, the developer has the source-code to read. When it comes to Windows, most of the relevant source code is completely unavailable (unless your school has special license to the MS Source code - I think there are some that do).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am attempting to create my own operating system and I am just wondering if there is a way to tell the BIOS to set a VGA pixel on my screen in C++.
C as a language does not provide any built-in graphics capabilities. If you want graphics, you have to use some OS-specific library.
Aside from that, modern operating systems generally don't allow any old program to poke around in memory however it wants to. Instead, they use intermediates called drivers and, yes, graphics libraries and APIs such as OpenGL.
If you really want to do it yourself get a copy of MS-DOS and dig up some old VGA specs and start from there.
You can turn on a given pixel, but this requires platform specific code and may not portable when the OS or platform changes.
My understanding is you want direct access to the screen buffer with nothing between stopping you. Here's the way to go.
Common Research
On your platform, find out the graphics controller, brand name and model name, if you are using one. Search the web for the data sheets on the graphics controller chip. Most likely, the screen memory is inside the chip and not directly accessible by the CPU.
Next, find out how to access the board that the Graphics Controller resides on. You may be able to access the Graphics Controller chip directly by I/O ports or memory addresses; or you may have to use an interrupt system. Research the hardware.
Linux
Download a source distribution for the Linux kernel. Find the graphic driver. Search the code in the graphic driver to see how the Graphics Controller is manipulated.
For Linux, you will have to write your own graphics driver and rebuild the kernel. Next you will need to write a program that accesses your driver and turns on the pixel. Research "Linux driver API". There are books available on writing Linux drivers and the standard API that they use.
Windows
Windows uses the same concept of drivers. You will have to write your own Windows driver and let the OS know you want to use it. Your driver will talk to the Graphics Controller. There are books available about writing Windows drivers. After writing the driver, you will need to write a demo program that uses your driver.
Embedded Systems
Embedded systems range from simple to complex as far as displays go. This simplest embedded system uses memory that the display views. Any writes to this memory are immediately reflected on the display.
The more complex embedded systems use Graphic Controllers to control the display. You would need to get the data sheets on the Graphic Controller, figure out how to set it up, then how to turn on a pixel.
Driver Writers
Drivers are not an easy thing to write. Most drivers are written by teams of experts and take months to produce. Graphic Controller chips are becoming more and more complex as new features are added. The driver must be able to support new features and the older models. Not an easie issue.
Summary
If you really want to access a pixel directly, go ahead. It may require more research and effort that using an Off The Shelf (OTS) library. Most people in the industry use OTS libraries or frameworks (such as QT, wxWidgets and XWindows). Drivers are only rewritten or modified for performance reasons or to support new graphics hardware. Driver writing is not a simple task and requires a quality development process as well as a verification strategy.
Good luck on writing your pixel. I hope your library has something better to offer than the many graphic libraries already in existence.
When reading about the Mac OS X audio API, they seem to list quite a few functions, but not (that I can find) how to use them.
For instance, they list a subclass, IOAudioLevelControl. Should I just create an object with this, and assume that it controls the audio level? And if so, what should I assume? That it has a constructor that sets the audio level, so I should declare them IOAudioLevelControl levelControl(5);?
I'm very confused here.
Edit: My goal is to make a program that detects the audio level of all the running programs(like Chrome when you play music from Youtube etc) and lower the level if it goes over a certain level, set by the user.
IOKit is way too low level - it's the user-space proxy for device drivers on the system. MacOSX provides several layers that sit about this. Most likely, you can use these APIs directly without being root.
Core Audio provides the next layer up in the stack. The diagram on this page shows the architecture.
Setting CoreAudio are higher level APIs such as Audio Units and AVFoundation. It is likely that are what you want.
Both Windows (Win32 API) and OS X (Cocoa) have their own APIs to handle windows, events and other OS stuff. I have never really got a clear answer as to what Linux’s equivalent is?
I have heard some people say GTK+, but GTK+ being cross platform. How can it be native?
In Linux the graphical user interface is not a part of the operating system. The graphical user interface found on most Linux desktops is provided by software called the X Window System, which defines a device independent way of dealing with screens, keyboards and pointer devices.
X Window defines a network protocol for communication, and any program that knows how to "speak" this protocol can use it. There is a C library called Xlib that makes it easier to use this protocol, so Xlib is kind of the native GUI API. Xlib is not the only way to access an X Window server; there is also XCB.
Toolkit libraries such as GTK+ (used by GNOME) and Qt (used by KDE), built on top of Xlib, are used because they are easier to program with. For example they give you a consistent look and feel across applications, make it easier to use drag-and-drop, provide components standard to a modern desktop environment, and so on.
How X draws on the screen internally depends on the implementation. X.org has a device independent part and a device dependent part. The former manages screen resources such as windows, while the latter communicates with the graphics card driver, usually a kernel module. The communication may happen over direct memory access or through system calls to the kernel. The driver translates the commands into a form that the hardware on the card understands.
As of 2013, a new window system called Wayland is starting to become usable, and many distributions have said they will at some point migrate to it, though there is still no clear schedule. This system is based on OpenGL/ES API, which means that in the future OpenGL will be the "native GUI API" in Linux. Work is being done to port GTK+ and QT to Wayland, so that current popular applications and desktop systems would need minimal changes. The applications that cannot be ported will be supported through an X11 server, much like OS X supports X11 apps through Xquartz. The GTK+ port is expected to be finished within a year, while Qt 5 already has complete Wayland support.
To further complicate matters, Ubuntu has announced they are developing a new system called Mir because of problems they perceive with Wayland. This window system is also based on the OpenGL/ES API.
Linux is a kernel, not a full operating system. There are different windowing systems and gui's that run on top of Linux to provide windowing. Typically X11 is the windowing system used by Linux distros.
Wayland is also worth mentioning as it is mostly referred as a "future X11 killer".
Also note that Android and some other mobile operating systems don't include X11 although they have a Linux kernel, so in that sense X11 is not native to all Linux systems.
Being cross-platform has nothing to do with being native. Cocoa has also been ported to other platforms via GNUStep but it is still native to OS X / macOS.
Strictly speaking, the API of Linux consists of its system calls. These are all of the kernel functions that can be called by a user-mode (non-kernel) program. This is a very low-level interface that allows programs to do things like open and read files. See http://en.wikipedia.org/wiki/System_call for a general introduction.
A real Linux system will also have an entire "stack" of other software running on it, in order to provide a graphical user interface and other features. Each element of this stack will offer its own API.
To aid in what has already been mentioned there is a very good overview of the Linux graphics stack at this blog: http://blog.mecheye.net/2012/06/the-linux-graphics-stack/
This explains X11/Wayland etc and how it all fits together. In addition to what has already been mentioned I think it's worth adding a bit about the following API's you can use for graphics in Linux:
Mesa - "Mesa is many things, but one of the major things it provides that it is most famous for is its OpenGL implementation. It is an open-source implementation of the OpenGL API."
Cairo - "cairo is a drawing library used either by applications like Firefox directly, or through libraries like GTK+, to draw vector shapes."
DRM (Direct Rendering Manager) - I understand this the least but its basically the kernel drivers that let you write graphics directly to framebuffer without going through X
I suppose the question is more like "What is linux's native GUI API".
In most cases X (aka X11) will be used for that: http://en.wikipedia.org/wiki/X_Window_System.
You can find the API documentation here
XWindows is probably the closest to what could be called 'native' :)
The linux kernel graphical operations are in /include/linux/fb.h as struct fb_ops. Eventually this is what add-ons like X11, Wayland, or DRM appear to reference. As these operations are only for video cards, not vector or raster hardcopy or tty oriented terminal devices, their usefulness as a GUI is limited; it's just not entirely true you need those add-ons to get graphical output if you don't mind using some assembler to bypass syscall as necessary.
Wayland
As you might hear, wayland is the featured choice of many distros these days, because of its protocol is simpler than the X.
Toolkits of wayland
Toolkits or gui libraries that wayland suggests are:
QT 5
GTK+
LSD
Clutter
EFL
The closest thing to Win32 in linux would be the libc, as you mention not only the UI but events and "other os stuff"
GUI is a high level abstraction of capability, so almost everything from XOrg server to OpenGL is ported cross-platform, including for Windows platform. But if by GUI API you mean *nix graphics API then you might be wandering around "Direct Rendering Infrastructure".
When I used C# i was only able to access user-mode registry accesses.
Is it very difficult to access kernel-mode registry accesses using C++?
I recall reading somewhere I may have to create a dummy windows driver or something?
EDIT: Basically as a hobby project I wish to create a simple registry monitor. However, I do want to catch kernel mode (as well as user mode) registry accesses..... last time I did this, using C# I could not access the kernel mode activity.
There are two ways to achieve this:
Hook the relevant functions in the kernel - the traditional way - which requires a C/Kernel Driver. This is possible on x86 Windows, but on x64 Kernel Patch Protection will detect these modifications and shut down the system (with a bluescreen).
Build a registry filter driver - this is the now encouraged way to attack this problem and is the way process monitor works. You can also build file system filter drivers this way. Essentially, you simply need to pass the information back to userland which boils down to:
IoRegisterDevice(...somewhere in \Devices\YourDriverName...)
IoCreateSymbolicLink(\\DosDevices\Name -> \Devices\YourDriverName)
then a C, C++, C# application should be able to open the file \\.\YourDriverName and DeviceIoControl to it and receive responses.
It is possible to use C++ to write kernel drivers, but see this before you embark on doing so. To be clearer, you need to be really careful about memory in kernel mode (paged, nonpaged) and you're not going to have access to much of the standard library.
As an aside, you should be aware that:
Not all registry hives are accessible to kernel mode drivers, depending on context.
The paths are not common. So the kernel accesses \Registry\System whereas userland accesses HKLM.