OK, this is basically just about any non-default OS API running on all different OS. But for my example let´s consider platform Windows, API SDL (Simple DirectMedia Layer).
Actually this question came to my mind when I was reading about SDL. Originally, I thought that on Windows (and basically any other OS) you must use OS API to make certain actions, like writing to screen, creating window and so on, because that API knows what kernel calls and system subroutines calls it has to do. But when I read about SDL, I surprised me, because, you cannot make computer to do anything more than OS can, since you cannot access HW directly, only thru OS API, from Console allocation to DirectX.
So, my question actually is, how does this not-default-OS APIs work? Do they use (wrap) original system API (like MFC wraps win32 api)? Or, do they actually have direct access to Windows kernel? Or is there any third, way in between?
Indeed, SDL is a wrapper for OS-specific calls, although with many simplifications and convenience functions. On Windows, SDL uses DirectX.
Related
Is there a generic way to access device specific functionality from within the MBED development stack or am I S.O.O.L and need to go to a lower level tool chain? (want to use the integrated op-amps of the STM32F303RE device)
You can just use the STM32 HAL functions like you'd normally do. Mbed OS wraps around these. Note that these functions are not guaranteed to be thread safe (unlike the Mbed HAL).
I have a 64 bit cocoa project that needs to use a 32-bit rendering library, which I cannot port to 64-bit.
I decided to separate it to a rendering service, which will be compiled in 32-bit and will provide an interface for the library, and the main project, which will be compiled in 64-bit and will access the rendering service.
I am wondering what is the best way to do the interprocess communication. I am looking for a solution that will provide fast communication and easy api.
It seems that XPC (and specifically, NSXPCConnection) is the recommended solution nowadays. However, I'm not sure - is it implemented for 32-bit applications?
In addition, I need to pass a fairly large quantity of data (max ~5MB), and so I worry about the performance and speed of the XPC. Is shared memory mapping is possible/recommended in this situation? can it work in conjunction with xpc?
For 32-to-64-bit APIs, Apple does use XPC services in their own apps, like Pages, to migrate old data to a more recent API.
Although I have yet to get it to work using NSXPCConnection, and Apple's own apps use the functions found in xpc/xpc.h.
I have a desktop app based on HTML/JS that needs WebKit to function at a reasonable speed. Normally, I would live with IE behaving badly, but its JS engine is just too slow.
I would normally go to Appcelerator for this, but it seems they have discontinued their desktop SDK and left it for the "community"...
This needs to function on Windows PCs, or I would just use Fluid (http://fluidapp.com)...
Is there a simple Webkit wrapper that I can use, or should I build one really quick in something like Qt. I haven't used Qt in a while, so I'd have to look at it again and make sure WebKit is implemented in it...
While it is somewhat node.js-oriented, AppJS may offer what you're looking for. If it doesn't already support other scripting languages, it might at least provide a good example to start from.
Update: in the time that's passed since my original answer, it seems node-webkit fills a similar role but has gathered and maintained more momentum than AppJS. It's a little more focused, in that it doesn't attempt to provide much additional "framework" on top of simply exposing the node.js API to the window's JS context.
There's also https://github.com/atom/atom-shell, which I just learned of and may be similar.
One other thing to note is that (presumably with either, but at least with node-webkit), you MUST be cautious of any XSS-like vulnerability in your app that an attacker could exploit to gain complete access to the user's native machine. So if you are simply needing to package an offline web app in a downloadable desktop distribution, you may wish to research more PhoneGap-like solutions (e.g. Mac OS X as PhoneGap platform) or a plain web view wrapper (like mentioned in the OP) that do not expose an entire OS-level native API — as node.js does — into the JavaScript environment.
I wrote an application in a JS-based framework called Titanium. This framework doesn't have some functions, so I'm bundling autohotkeys, and using STDIN/STDOUT to connect the two. Autohotkeys has a cool function DllCall which allows to interconect with the operating system and should help me close the gap between the JS-based framework and the missing functionality.
To give you an example, Titanium allows me to bind to a specific port. But if I bind to 0 and let the OS pick a free port (as it should), it will work, but there's no way to tell which port it actually bound to.
Now since I come from web applications, DLLs are new to me; so I have a few questions:
Is there like a big doc with all the DLLs and all their methods?
How do I know if some methods are dependent on some services? I mean I've heard some rely on RPCs, COM, COM+, WMIs, etc. which a user can turn off and if it does, these methods won't work. Is there also a place where I can get more info on this?
Are there any off-the-shelf DLLs, with their methods, which I can trust that they will work 100% from XP up to 7?
Are there any access permissions I should know about? Are they documented.
If you also come from web programming, is there anything else I should be aware about?
Thank you very much.
You can find a (mostly) complete documentation of all Windows API functions (which reside in DLLs) either online on MSDN or offline using the documentation from the Windows SDK.
For example look at the documentation for SHGetSpecialFolderPath. There you can find various information, like the DLL (shell32.dll), any prerequisites (min. IE 4) and the platform availablity. (min. Windows 2000) Also security considerations are documented.
All API functions are documented more or less in this manner. A good starting point is the Windows Developer Reference. From there you can browse through the many API functions.
Basically the answer to every question is that you should search MSDN for the functions or APIs you are interested in and read the documentation there:
http://msdn.microsoft.com/en-us/library/ms123401.aspx
They document which operating systems the functions are available in so it should be easy to write something that works in Windows XP and up.
Is it possible to make an operating system using VB.NET?
Yes it is possible to make an operating system using vb.net.
You've got a serious bootstrap problem. Compiled VB.NET code cannot run without the services of the CLR and the JIT compiler. Existing implementations of it (mscorwks.dll and mscorjit.dll for example) have a heavy dependency on services provided by an operating system. You'll have to write your own, that's non-trivial to put it mildly. In addition, many classes in the framework rely on P/Invoke to directly call a Windows API function. Very basic classes like Console, Control, FileStream, Socket. You'll have to replace those too. That's where Singularity was stuck last time I saw a video of it.
The "starter kit" for any project like this is Rotor. That's how Mono got started. Take a look at what your in for, focus on the Platform Adaption Layer (PAL). Needs to be written in unmanaged C/C++ in its current form though.
It has been done (well C# at least, but since they are both CLR languages...)
It's called Singularity by Microsoft Research.
http://en.wikipedia.org/wiki/Singularity_(operating_system)
https://github.com/CosmosOS :::: here is the Answer; Cosmos Allows you to develop your own kernal with c#
Yes, it is possible.
But first you will have to identify what an operating system is; and then define what would you want in your operating system? An operating system does a lot of work on the background as well as on the foreground; there are applications, memory, threading, network, ports, a separate world that make things work.
I would agree with Aviad that probably your OS may be called a .NET CLR, but thats what that would be called. An answer to your question is that it is possible provided that you define your OS and probably limit yourself to what you really require.
No!
Unless you re-define what an operating system is and make the problem fit the solution. This has been standard practice in this industry for decades. Given the right definition of Operating System, you can even use Esperanto to write it:) So what is your definition of Operating System?
Yes, but that would not be easy. Or hard, as a matter of fact. It would be insanely difficult! You would have to write a Visual Basic interpreter (in asm or c), then you would need to implement System and a lot of other CLR stuff. What you may be looking to do is create a virtual OS. This would mean that it lays over the Windows gui and acts as an interface. Good luck.