For fun i'd like to write code that runs on OSless hardware. I think writing code that will run in a VM (like VMware or virtualbox) would be good. However i don't want to start from scratch. I'd like the C++ runtime to be available. Something that allows me to read/write (maybe FAT32 filesystem code). Graphics for text and if i can graphics for drawing on screen (pixel by pixel. sdl support would be a bonus but not essential).
I'll write my own threads if i want them. I'll write everything else (that i want to use) needed for an OS. I just want a basic filesystem, gfx and keyboard/mouse support.
Take a look at the list of projects on osdev.org - (http://wiki.osdev.org/Projects) - most of these are hobbyist, open-source and range from just-a-bootsector through to proper threads/graphics/terminal support.
Minix3 targets your desires pretty well.
You should definitely take a look at OSKit (links to source code on this site are dead but there is a mirror here). Unfortunately, OSKit has no support for C++ but using this information you may be able to use GCC libraries.
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.
I'm not actually well versed in C++ or SDL_Mixer, but I'm asking this question anyway on behalf on the Doom community. Put simply, nobody writing Doom source ports can seem to figure out how to control normal sound volume and MIDI sound volume independently using SDL_Mixer on Windows Vista or 7. I'll let James Haley, author of Eternity Engine, put it in his own words:
Seems the concept of independent volume for native MIDI doesn't exist under Windows Vista or 7, as using MIDI volume sliders in any application that has them (including most games that use SDL_mixer) also affects the volume of digital sound output. This makes attempting to adjust the relative volume of music for comfort impossible.
Has anybody found any workarounds for this? I'm guessing it's unlikely given how Microsoft seems to have skimped throughout the OS on any way to control the volume of individual sound devices separately.
I've heard of various workarounds all involving a Timidity driver, but this requires the user go above and beyond simply installing the game on his system. The only port that I know of that definitively fixes this issue is ZDoom, but it uses the GPL-incompatible FModEx and is thus not a suitable solution.
If you want some code to look at, Chocolate Doom is perhaps the easiest Doom source port to grok and you can grab its source here.
Any suggestions on other open-source sound and music libraries would be welcome as well.
A solution would be to ship with a FluidSynth-enabled SDL_mixer. You would also need to ship a SoundFont2 file to go with it. Fortunately, there are free SF2's out there, and some are even optimized for Doom's MIDI files. Licenses shouldn't be a problem, since SoundFonts are assets, not code.
You then load the SF2 using Mix_SetSoundFonts().
You may want to look at different MIDI libraries outside of SDL.
http://wildmidi.sourceforge.net/
http://sourceforge.net/apps/trac/fluidsynth/
http://timidity.sourceforge.net
I am maintaining a similar game port (Descent 2), and I have come across the same problem. Afaik there is no solution for it when using SDL_mixer. A cure to avoid sound being muted when turning off midi music I have found is to retrieve a handle to a temporary midi device, set the midi volume to max and then close the temporary device again.
For the longest time, the only solution we found was to use something like PortMIDI. However, Quasar of Eternity Engine fame has come across a neat solution:
http://www.doomworld.com/vb/showthread.php?s=&postid=1124981#post1124981
He essentially puts SDL_Mixer into its own process and controls it with RPC. Very clever.
So one problem with the previous answer I gave was that sometimes the MIDI subprocess did not behave itself, and would break or stop working in strange ways. Eternity's specific implementation used IDL, and I personally re-implemented it using pipes, but the subprocess itself was a bug magnet.
Thankfully, another answer was figured out rather recently. You can simply bypass SDL_Mixer entirely and deal with Windows' native MIDI support directly, which turns out to not require a ton of code once you know what you're doing.
https://github.com/chocolate-doom/chocolate-doom/blob/master/src/i_winmusic.c
You can also implement this sort of idea with PortMIDI and get the benefit of being able to communicate with external MIDI devices as well.
https://github.com/odamex/odamex/blob/stable/client/sdl/i_musicsystem_portmidi.cpp
every one. i am a newbie to cuda. i am wondering that can cuda be used combining with ActiveX technology，
the presented ocx or dll file can be used in webpage，
for example， using cuda can we simulate a fluid particle easily.
if combine cuda and activeX technology ,
we can see fluid particle in a webpage, am i right?
what's more, if there are problems when i simulate lots of particles?
Thank you very much.
I think that if ActiveX could access your GPU on such low level as running your arbitrary CUDA code, it would be a big security risk. If on the other hand, ActiveX could perform some of its computations on the GPU though some higher-level interface, that would be safer, but it is Microsoft who would have to implement it, not you.
A trusted ActiveX control can do anything. So, yes, you could theoretically spin up the CUDA runtime and go to town with the GPU. You would need to distribute the CUDA runtime with the ActiveX control, but everything else you need would already be installed assuming they're using an nVidia GPU. FWIW, distributing cudart.dll is permissable per the EULA on the CUDA Developer Toolkit.
Since, last I read, you cannot statically link against cudart.dll, you would need to distribute that dependency along with your ActiveX control by using a CAB file. Details on creating CAB files can be found here on MSDN. Then again that forum post is from 2008, so maybe newer versions of cudart.dll can be statically linked now... you might want to give it a try.
First and foremost, it runs on the client machine. What means that the client needs to have a CUDA enabled graphics card (nVidia only).
I'd like to capture the input from a TV remote control and detect which buttons are pressed in my application. The operating system is Linux (Windows answers won't be much use to me, but may be to others). I'm using C++ but C code would work for me also.
I'd like to use the code in a fashion similar to this:
if (remoteControl.buttonPressed(PLAY_BUTTON))
{
fooBar.doSomethingFun();
}
Also, I was thinking there may be a generic library I can use, which would with all remotes, or would I have to do some really low level coding?
First off you are going to need some hardware to detect the IR emissions, for example a USB-UIRT
On Linux, the USB-UIRT is support by LIRC which deals with the low level end of things for you.
There are a number of open source packages that work with this to provide control, so you can look at their code for examples, eg. Myth TV
This is NOT a question on plain old boring customization; I actually want to create an program, you know, with source code, etc...
I'm thinking about programming my own media centre interface, and I figured it'd look better if I coded my own splash screen for when the OS is loading.
Note: The media centre interface will be run in X, but this question is regarding what will happen before the X server loads.
Simply, I'd like to make a splash screen application to hide the linux kernel boot messages. Is there a way I can program some animation in to this like some sort of animated progress bar for example? I assume that I won't be able to code any 2D/3D graphics (as that'd require X to be running, right?), so how would I go about generating that?
I'd prefer to do this in C++, but C is also an option.
Note: I'm not looking to use any existing "themes" or anything like that, just interested in the programming side of things.
Update:
Some suggestions have been to use standard images (.bmp, .jpeg, etc), I am not interested in loading images in to an existing application. But obviously I may want to load images in to the boot screen application that I will make.
I'm not tied to a Linux distro, so this can be for anything, although Debian or a Debian-based distro would be nice.
I like the suggestion about loading the X server early and running a loading screen from there, however is there not a more direct approach? Surely you can make a program which hides the boot messages and shows a custom program? Obviously this would be very low level programming, but that's what I'm looking for...
Also, I'm not interested in altering the boot loader (LILO, GRUB, etc).
Update 2:
So far good suggestions have been looking at the source code for applications like splashy and fbsplash. Can anyone better this suggestion?
For the graphical output you can use the Linux framebuffer, for application development you can use gtk which support rendering directly to the framebuffer GtkFB.
For the video and such you can use mplayer which also support rendering to the framebuffer.
For the initialization you have to look around the system used, debian uses a sysv init style initialization http://www.debian-administration.org/articles/212, ubuntu uses upstart.
I'd look into splashy source code. But you will need to code in C.
If you have the skills, you can implement a software based 3D engine (like in the good old days). A simple rotating cube shouldn't be very hard to code and there are tons of tutorials.
The downside is that you will increase the boot time, something not very pleasant in a media center.
Here's the thing: there is a library/kernel patch, fbsplash, that has already been written to do exactly what it sounds like you want to do. It will display an image in place of the normal boot messages, and it can also incorporate a progress bar. When you're trying to do something for which a well-established open-source implementation already exists, there's really no better way to learn how to do it yourself than to look at the source code.
Even if you're looking for something more complicated (say if you want to create some fancier animation than a progress bar), you might be able to start with fbsplash and modify it to suit your needs.
There are several ways you could do this. You could have the X server load very early, and just write a program to display the splash screen. You could also use the framebuffer device. If you are using Intel hardware, or are willing to use the OSS AMD drivers, or Nouveau for Nvidia, you could use kernel mode setting. For this, I would look at Fedora's Plymouth. You could just write a Plymouth plugin to display your splash screen.
The splash screen is simply an image (.bmp, .jpg, etc.) and can be loaded by the boot loader. Since you haven't specified the distribution you're using, look into LILO, grub, or whichever one is appropriate. Check the /boot directory for clues that will direct your search.
If all you want to do is have a nice clean boot sequence with your own splash and absolutely no boot messaging you can do the following:
First, silence grub, boot messaging, and console cursor:
GRUB_CMDLINE_LINUX_DEFAULT = quiet fastboot splash vt.cur_default=1 loglevel=0
GRUB_TIMEOUT = 0
This will very quickly and silently (fade to black) bring you to your login screen, where you can place a splash. Your distro may show it's own splash briefly, which you can change if you like.
This yeilds a professional clean boot sequence, without all the usual linux warts and wrinkles. (Like OSX and Windows).
I personally use Ubunutu with LXDE, and have a clean splashy boot in under 3 seconds, even on older hardware.