I have recently discovered how wonderful modifying the DSDT table in Windows is. I already remapped some Fn keys to do some other things, but those things were located in the actual DSDT (like turn LEDs off, turn fan on/off).
Now, I would like to step up the game and control the things from the OS. Like, define some custom methods in the DSDT, and then using software from Windows, call those things. That would open the door to an entire new level of posibilities.
So, what are the steps to do to acomplish this under Windows, using C++ for example? And, is there an app that can call generic methods from the DSDT already? Because that would be so awesome.
Thanks!
Related
Is there a Windows standard way to do things such as "start fan", "decrease speed" or the like, from C/C++?
I have a suspicion it might be ACPI, but I am a frail mortal and cannot read that kind of documentation.
Edit: e.g. Windows 7 lets you select in your power plan options such as "passive cooling" (only when things get hot?) vs. "active cooling" (keep the CPU proactively cool?). It seems the OS does have a way to control the fan generically.
I am at the moment working on a project that, among other things, controls the computer fans. Basically, the fans are controlled by the superIO chip of your computer. We access the chip directly using port-mapped IO, and from there we can get to the logical fan device. Using port-mapped IO requires the code to run in kernel mode, but windows does not supply any drivers for generic port IO (with good reason, since it is a very powerful tool), so we wrote our own driver, and used that.
If you want to go down this route, you basically need knowledge in two areas: driver development and how to access and interpret superIO chip information. When we started the project, we didn't know anything in either of these areas, so it has been learning by browsing, reading and finally doing. To gain the knowledge, we have been especially helped by looking at these links:
The WDK, which is the Windows Driver Kit. You need this to compile any driver you write for windows, With it comes a whole lot of source code for example drivers, including a driver for general port-mapped IO, called portio.
WinIO has source code for a driver in C, a dll in C that programmatically installs and loads that driver, and some C# code for a GUI, that loads the dll and reads/writes to the ports. The driver is very similar to the one in portio.
lm-sensors is a linux project, that, among other things, detects your superIO chip. /prog/detect/sensors-detect is the perl program, that does the detecting, and we have spent some time going through the code to see how to interface with a superIO chip.
When we were going through the lm-sensors code, it was very nice to have tools like RapidDriver and RW-everything, since they allowed us to simulate a run of sensors-detect. The latter is the more powerful, and is very helpful in visualising the IO space, while the former provides easier access to some operations which map better to the ones in sensors-detect (read/write byte to port)
Finally, you need to find the datasheet of your superIO chip. From the examples, that I have seen, the environment controllers of each chip provide similar functionality (r/w fan speed, read temperature, read chip voltage), but vary in what registers you have to write to in order to get to this functionality. This place has had all the datasheets, we have needed so far.
If you want something real quick to just lower fans to a level where you know things won't overheat, there's the speedfan program to do so. Figuring out how to configure it in the early versions to automatically lower fans to 50% on computer startup was so painful that my first approach was to simply byte-patch it to start the only superio managed fan I had at lower speed. The newer versions are still bit tough but it's doable - there's a graphical slider system that looks like audio equalizer except that the x axis is temp and y is fan speed. You drag them down one by one. After you figure out how to get manual control for the fan you want, this is next step.
There's a project to monitor hardware (like fans) with C#:
http://code.google.com/p/open-hardware-monitor/
I haven't extensively looked at it, but the source code and use of WinRing0.sys atleast gives the impression that if you know what fan controller you have and have the datasheet, it should be modifiable to also set values instead of just getting them. I don't know what tool is suited (beside kernel debugger) to look at what Speedfan does, if you preferred to snoop around and imitate speedfan instead of looking at the datasheets and trying things out.
Yes, It would be ACPI, and to my knowledge windows doesn't give much/any control over that from user space. So you'd have to start mucking with drivers, which is nigh impossible on windows.
That said, google reveals there are a few open source windows libraries for this for specific hardware... so depending on your hardware you might be able to find something.
ACPI may or may not allow you to adjust the fan settings. Some BIOS implementations may not allow that control though -- they may force control depending on the BIOS/CMOS settings. One might be hard-pressed for a good use case where the BIOS control (even customized) is insufficient. I have come across situations where the BIOS control indeed was insufficient, but not for all possible motherboard platforms.
WIndows Management Instrumentation library (WMI) does provide a Win32_Fan Class and even a SetSpeed method. Alas, the docs say this is not implemented, so I guess it's not very helpful. But you may be able to control things by setting the power state.
The problem
I would like to use c++ to create an application that uses the new macbook pro touch bar. However I am not able to find any really good resources. And apple does not have any docs on using c++ to program the touch bar.
What I have done
I found this article on c++ and the touch bar, However I cannot find either of the header files for the script GLFW/glfw3.h and GLFW/glfw3native.h. These both seem critical to the script working.
More on the issue
Even if the above article's script works, there are no official docs for programing the touch bar with c++ (That I know of). I think that this is an important thing to have given the fact that many, if not most applications are written in c/c++.
Thank you in advance for the help!
So the article that you link to basically does not need the GLFW/glfw3.h and GLFW/glfw3native.h files if you are not using GLFW.
What UI framework are you using for your C++ app?
Unless it is still using Carbon, at the lowest level, the framework will be creating NSWindows to actually have windows in the UI. You need to get access to the NSWindow that your framework is using to host it the UI. If it is still using Carbon, I think you are probably not going to be able to accomplish this.
If the framework provides some mechanism to get the native platform window (which will be an NSWindow), you would replace the author's call to glfwGetCocoaWindow(window); with the correct call from your framework.
If the framework does not provide access to the NSWindow, then you will need to use the code that is commented out at the bottom of the article to attach your touchbar to the windows in your app.
Please note that all that code is Obj-C code; you'll need to have at least one .m or .mm file in your project to provide that Obj-C glue code to get access to the touchbar. Basically that code is a C-calleable wrapper around the Cocoa API.
Also note that you'll need to expand the list of buttons and actions for all the different things you want to put in the touchbar. You could add your own wrapping API so that the construction of the toolbar is done from C++ and registers actions that call-back into your C++ app to handle the events.
Fundamentally though, the touchbar is not available on any other platform, so there is no great benefit to trying to avoid writing Obj-C to implement your touchbar as that code will only run on macOS anyway. If you use .mm files to implement Obj-C++ for this code, you can still call into your C++ objects from your touchbar code.
I'm actually in charge of a FIP networking c++ application, working for the first time with Embarcadero C++ Builder XE5.
The app is nearly finished, but I can't find how to implement the last feature...
I wanted to open an external Windows HyperTerminal in order to see what happen on a given COM port, for this purpose I'm using ShellExecute() to launch it from my application but it's a bit ugly since there is 2 different windows.
I was wondering if it was possible to integrate this newly opened HyperTerminal into an existing form (Panel for instance). I couldn't find nothing related excepted this =>
Delphi style, but i don't understand a byte of #mghie answer since it's delphi.
If anyone have a clue I'm really interested, even the most basic clue!
For almost all of my projects where COM port interaction is needed I use AsyncPro. The project is very well documented with a ~1000 page reference manual.
Reference Manual
Developer's Guide
For this case, the package provides a VCL terminal that simply drops onto a form. It's quite flexible with a lot of options to configure its behaviour.
I wanted something similar in past but with no success.
1.The only thing I was able to do is the exact opposite.
dock my VCL window inside another (not VCL app) but that solved my problems
If you terminal is console window then I doubt even this can be done.
anyway find handle of desired window
find handle to a dockable subcomponent
set the parent of your subwindow to it / or use manual dock
2.maybe you can do some funny stuff
like hide terminal somewhere
and continuoslly copy its graphics to your window
newer done that hide thing
but copy the contents is doable (although on windows a little unstable sometimes)
done it once to feed my App with IR-camera feed from different App
while 'focus' stays on hidden terminal it should work
also you can try to post messages to it somehow if you need the focus ...
Sorry for a vague answer but at least you see some approaches of mine
maybe someone has a better way to do this
I know this is kind of reinventing the wheel, but how hard would it be to implement an android user interface with C++? Is it hard to create things like buttons, and to handle touch screen events like button clicks? Is this feasible and if so, how would you go about doing it?
Take a look at Necessitas, its a Qt port for android which seems to work pretty well.
It might still be in Alpha or Beta stage though, so it will depends on how "serious" your project is. But that proves for sure that one can use plain C++ to build a complete application, not only libraries.
You can always use the JNI to go back up into java to get UI components on the screen. If you set it up to be little more than an API, you can simulate actually doing it in native code. NVidea has some good samples on how to do this: http://developer.nvidia.com/tegra-resources This library code isn't doing it for UI components, but is for various other things (sound, resources, etc). and the idea should work for UI components too.
Also, this project supposedly supports the entire sdk in c++, and I would imagine it's doing it the same way. I don't know how up to date it is, as I haven't actually used it: http://code.google.com/p/android-cpp-sdk/
You can use JNIpp to create wrapper for activity and all UI classes you are interested in.
Take a look at HelloJNIpp sample, it features native Activity, native custom drawn View and a button.
Spoiler:
void MainActivity::OnCreate(const jni::LObject& bundle) {
Activity::OnCreate(bundle);
SetContentView(R::GetLayout("main"));
FindViewById(R::GetID("changeColor"))->
SetOnClickListener(*this,&MainActivity::ChangeColor);
}
The scenario is such: there's a program which loads my .dll/.so and calls a function from within it, possibly multiple times, each time expecting a different pointer to state. It uses the different states later in other calls into the dll. (It's a game AI, if you need context; each state is a AI player.)
What I want is a cross-platform way of creating a canvas window for each of those states (for visualization, debugging, etc.) I tried wx, but put it on hold, since it didn't appear to be easy at all. Are there any neat and small libraries that could do that or should I just go with WinAPI/X...?
Edit: Assume I cannot modify the host program.
Qt is simpler to set up and drive than Wx, in my experience. It's very cross platform too.
If you want to render some graphics from inside your DLL function without passing in any pointers to QImage or QWidget type things, probably the thing to do is use OpenGL. Your DLL should just render to the current OpenGL context, which is global state and can just be setup outside the DLL (maybe using QGLWidget).
Update: Ah, I just noticed your edit re not being able to modify the host code. This is a problem: any windows you create really need to be plugged into the host apps' event loop to work properly (e.g receive WM_PAINT when exposed/resized). It's certainly possible in win32 for any old code (e.g your library) to just CreateWindow and draw its contents with GDI whenever it gets the chance, but the general window behaviour may be pretty broken (it may not work at all with Vista's double buffering; I haven't tried). What I typically find easiest in this situation is simply to dump out image files and review then afterwards with image viewer of choice. IMHO this is actually more useful for debugging than a "live" window because you can step backwards and forwards, zoom in, apply image-enhancement to highlight various issues, compare against previous runs for regression testing etc etc. (If you really want the "live" views, write an image displayer which monitors a directory for new images, or streams them through a named pipe or something).
If you just want simple graphics, no widgets, SDL is very easy to use. If you do need complex controls, use Qt, as timday said.
You might check out IUP. It interfaces really well with Lua, and can be used entirely from an extension DLL there so it seems plausible that its C API could be used from a DLL plugged into something else.
IUP will get you a framework for opening a window containing the usual suspect kinds of controls, including a canvas. Its related library CD will give you the usual drawing operations in that canvas.
Current releases are portable between Windows and *nix. The next major release will support MacOSX too.