I am new to OSDev, and I am currently trying to write my OS from bare bones, i.e. using GRUP as my bootloader, on x86 arch. I want my OS to support both BIOS and UEFI boot.
I am currently trying to write my own graphical interface. And I am kind of confused on how to do it so it would work on all platforms.
I observed that on UEFI 2.x I must use GOP, while on UEFI 1.x I should use UGA and on BIOS I must use either VESA or VGA.
Does it means that in order to implement a cross-firmware OS I would have to support all of them? And only choose one from the supported interfaces? How can I even tell from my OS if I was booted by UEFI? And what version of UEFI?
Should I just abandon the compatibility goal and simply pick one setting and implement my OS for that one?
Related
This question already has answers here:
How does OpenGL work at the lowest level? [closed]
(4 answers)
Closed 5 years ago.
I am writing an x86 os and a question popped into my mind:
If I would want to create a simple opengl game in my os, would I be able to do that without reinventing opengl?
SO what I am asking is, is opengl included in e.g. the nvideo drivers, or is it located in the gpu firmware?
If it would be in the gpu, i could simple port/create a opengl wrapper right?
Can someone elaborate on this?
Thanks
OpenGL is the API of the GPU driver. Taking nVidia as an example, they release closed source drivers for supported operating systems. There are also open source drivers (the nouveou project) that try to reverse engineer the nVidia graphics cards and implement an open source driver for them. The same is also true for other vendors to some extent.
So considering your scenario, you should either implement an ABI compatibility layer in your OS with a widely supported OS so that you could run the closed-source drivers, or port the open-source community drivers to your OS.
The GPU hardware executes specific code. Some of this code is programmable, which means that you write special code that runs inside the GPU card.
The instructions to pass this special code (shaders in OpenGL parlance) and the data they handle are the graphics API (OpenGL, DirectX). There are also more instructions for the GPU, they are also handled by the API.
This API lives in the graphics card driver.
First, an app asks the OS to provide the function pointers to the API commands. These pointers are retrieved from the driver. Then the app use these pointers to comunicate with the GPU (via driver).
Two details: Retriving pointers is not needed in MAC, they provide them as any C++ instruction. This is also true in Windows, but just for OpenGL 1.1
The drivers for Windows and Mac are propietary software.
In Linux nVidia, AMD and Intel provide their drivers (but mostly as closed source). Also in Linux, there are open source drivers, which some developers wrote on their own.
Finally, There is a software inplementation of the OpenGL API done by Mesa. Mesa also is one of those that writes open source drivers for Linux.
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.
I wrote a simple application that checks if NVIDIA CUDA is available on the computer. It simply displays true if a CUDA-capable device is found.
I send the app to a second PC, and the application didn't run - a dialog box showed up that cudart.dll was not found. I want to check if CUDA is present and it requires CUDA to do that :)
I am using CUDA 5.0, VS2012, VC++11, Windows 7.
Can I compile the application in a way, that all CUDA libraries are inside the executable?
So the scenario is:
My app is compiled & sent to a computer
The computer can:
be running windows, linux (my app is compatible with the system)
have a gpu or not
have an nvidia gpu or not
have CUDA installed or not
My app should return true only if 2.3 and 2.4 are positive (GPU with CUDA)
As an opening comment, I think the order and number of steps in your edit is incorrect. It should be:
Programs starts and attempts to load the runtime API library
If the runtime library is present, attempt to use it to enumerate devices.
If step 1 fails, you do not have the necessary runtime support, and CUDA cannot be used. If 2 fails, there is not a compatible driver and GPU present in the system and CUDA cannot be used. If they both pass, you are good to go.
In step 1 you want to use something like dlopen on Linux and handle the return status. On Windows, you probably want to use the DLL delay loading mechanism (Sorry, not a Windows programmer, can't tell you more than that).
In both cases, if the library loads, then fetch the address of cudaGetDeviceCount via the appropriate host OS API and call it. That tells you whether there are compatible GPUs which can be enumerated. What you do after you find an apparently usable GPU is up to you. I would check for compute status and try establishing a context on it. That will ensure that a fully functional runtime/driver combination is present and everything works.
Linking to a different post on stackoverflow: detecting-nvidia-gpus-without-cuda
This shows the whole sequence to check if the cuda api is available and accessible.
I think that using only the software there is no reliable way to ensure that a GPU is Cuda-capable or not, especially if we consider that Cuda is a driver-based technology and for the OS Cuda doesn't exist if the driver says that Cuda doesn't exist.
I think that the best way to do this is the old fashion way, consider checking this simple web page and you will get a much more reliable answer.
create a plugin for your application that dynamically links to the relevant CUDA-libraries and performs the check.
then try loading the plugin and run it's check.
if the plugin fails to load, then you don't have the CUDA-libraries installed, so you can assume False
if the plugin succeeds to load, then you have CUDA-libs installed and can perform the check, whether the hardware supports CUDA as well.
As a late andditional answer:
I am struggling with the same problem (detecting cuda installation without using it) and my solution so far is
ensuring LoadLibraryA("nvcuda.dll") != nullptr (tells you pretty much only if there is an nvidia card installed, though)
checking for environment variable CUDA_PATH (or in my case, CUDA_PATH_V8_0), since that seems to be set by the cuda installation: const char * szCuda8Path = std::getenv("CUDA_PATH_V8_0"); (must be != nullptr)
Use cudaGetDeviceCount() to know if the computer is CUDA-capable.
According to this thread, you cannot statically link cudart.dll.
There are workarounds: embed the CUDA runtime as a resource in your executable, then extract it when your program runs, then dynamically link.
You can also use nvidia-smi to see if CUDA is installed on a machine.
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".
I'm a long time Windows developer, and it looks like I'm going to be involved in porting a Windows app to the Mac.
We've decided to use Flex/Air for the gui for both sides, which looks really slick BTW.
My Windows application has a C++ DLL that controls network adapters (wired and wireless). This is written using the standard library and Boost, so most of it should work cross platform.
On the Mac, what IDE/complier do most folks use if they want to write C++? Also, can someone provide a pointer to whatever APIs the Mac has that can control WiFi adapters (associate, scan, disconnect, etc)?
Xcode is the IDE for Mac OS X, you can download the latest version by joining the Apple Developer Connection with a free Online membership.
I don't believe there are any supported APIs for controlling wireless networking adaptors. The closest thing would be the System Configuration framework, but I don't know if it will let you do everything you want.
Also, I would strongly recommend against trying to use Flex/Air for your application's user experience. It may look slick to you on Windows as a Windows developer, but when it comes to providing a full Macintosh user experience such technologies aren't always a great choice.
For one example, I think Air applications don't support the full range of Mac OS X text editing keystrokes. While not all Mac users will use all keystrokes, for those people used to them trying to type in a text field that doesn't handle (say) control-A and control-E to go to the beginning and end of field is like swimming through syrup.
For a new application that needs to be cross-platform, I'd strongly consider building the core logic in C++ while using Cocoa on the Mac and WPF on Windows to get the best user experience on each platform. Both Mac OS X and Windows have modern native user experience technologies that their respective users are getting used to, and also have good ways for C++ code to interoperate with these technologies.
The de-facto OS X IDE and compiler is Xcode. It comes with every Mac, you just install it from the OS X install CD.
Apple's developer site is the place to get more information on OS X APIs
Xcode and a custom GCC I believe...
xcode is the hotness, as people have already pointed out.
Having maintained a windows/mac codebase in the past, take a look at MVC.
So long as you keep the background logic distinct from the UI and from the platform-specific stuff (like file handling, networks, drawing to the screen, etc). That way, when you want to go to Linux in the future, you just have to write those platform specific components.
As for mac networking, are you on the level of connecting and so forth? Why not just let the OS handle that, and then you just see what connections are available? Why bother with whether or not the connection is wired or wireless? Because the OS has a lot of those tools already built in and users are used to making sure that the connection is there to do work, it seems odd to have an extra program to want to manipulate the network.
Xcode is used a lot, as far as I know the combination editor (e.g. Textmate), command line gcc is in fairly heavy use too. (that's what I do on OS X)
For all API needs head to Apple's developer site e.g. the networking API's