How do programming languages/libraries communicate with hardware? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely开发者_运维百科 solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

so I was looking into if there was any way to get around the XNA/Silverlight lockdown Microsoft has set up for the Windows Phone 7, as so maybe I could use SFML(.net binding) for application development and other libraries I've come to know.

I found none.....

Now all I'm wondering is why the windows phone and other similar devices don't allow some languages and unmanaged libraries such as OpenGL to be used, especially since I just found out about platform invocation/ external linkage/ other bilingual techniques.

To understand this I guess I need to undersand the relationship between a language and a machines hardware: How does a c/c++ library like OpenGL communicate with the screen/graphics card ?

bonus question: XNA doesn't use OpenGL/DirectX so is it an entirely independent graphics API?

---

The Operation System encapsulate all the Hardware with the same API. In the OS internal, it used the hardware io address to control it.

And the OpenGL/DirectX/XNA encapsulate all the OS's system API with a simple, easy used interface to all the program upon it.

Just like below:

Hardware <- HAL <- DirectX / OpenGL <- XNA <- Your Program

Hope this helpful:)

Jason

---

An extended pipeline would look like:

Hardware <- Vendor Drivers <- HAL (Operating System) <- OS Native Methods (DirectX/OpenGL) <- Managed Wrappers (XNA / .Net Frameworks / Java) <- Your Program

There are a few different reasons why vendors lock down devices.

1. Locked devices tend to have less technical issues, and Verizon etc don't want to fix Apple/Microsoft/Google/Motorola/Blackberry software issues.
2. Locked devices can be (not always) more secure because there is less chance for third parties to write bad drivers/software.
3. OpenGL initial/current design was/is not intented run on a mobile platforms.
4. Locked devices can create increased revenue by the OS Manufacturer as some require you to purchase development software and/or development licenses to write software.

I'm not especially excited about any of these, but they just come to mind.