In a nutshell, I want to write my own device driver for windows, so that I can emulate a piece of hardware. I know very little about writing device drivers for windows, but I have a very firm understanding of the C and C++ languages, and I know enough x86(_64) assembly to get around.
I'm not really sure how one would go about even compiling a device driver, or what is required to create one. I'm certainly not against coding the entire thing in assembly if that needs to be done, but does it?
I'd like to do this using Windows tools obviously, I'm planning on trying to put it together using a windows GCC compiler, but I've got access to Visual Studio if that's needed. Can someone point me at resources that would be helpful, like reference manuals, tutorials, specs?
Oh: My target OS here is Windows 7, 64bit, which if I understand should be the same as Windows Vista 64bit, but correct my wrongness if it exists.
Thanks.
Everything you need to build your driver (including the compiler) comes from the WDK. Everything you need to know what to write comes from Walter Oney's books. Be prepared for a rough ride.
Related
I have an embedded device with WinCE 6.0 as OS. The manufacturer provides an IDE for 3rd party development to it. The IDE pretty much allows nothing else than
.NET 3.5 Compact Framework scripting that's invoked from various events from the main application
Adding files to the device.
The included mediaplayer seems to be using DirectShow and the OS has media codec only for mpeg-1 encoded video playback. My goal is to to be able to play media encoded with some other codecs as well inside that main application.
I've already managed to use DirectShowNETCF (DirectShow wrapper for .NET Compact Framework) and successfully playback mpeg-1 encoded video.
I'm totally new with this stuff and I have tons of (stupid) questions. I'll try to narrow them down:
The OS is based on WinCE, but as far as I've understood, it's actually always some customized version of it (via Platform Builder). Only "correct way" of developing anything for it afterwards is to use the SDK the manufacturer usually provides. Right? In my case, the SDK is extremely limited and tightly integrated into IDE as noted above. However, .NET CF 3.5 is capable for interop so its possible to call native libraries -as long as they are compiled for correct platform.
Compiled code is pretty much just instructions for the processor (assembler code) and the compiler chooses the correct instructions based on the target processor setting. Also there's the PE-header that defines under which platform the program is meant to be run. If I target my "helloworld.exe" (does nothing but returns specific exit code) to x86 and compile it with VC, should it work?
If the PE-header is in fact the problem, is it possible to setup for WINCE without the SDK? Do I REALLY need the whole SDK for creating a simple executable that uses only base types? I'm using VS2010, which doesn't even support smart device dev anymore and I'd hate to downgrade just for testing purposes.
Above questions are prequel to my actual idea: Porting ffmpeg/ffdshow for WinCE. This actually already exists, but not targeted nor built for Intel Atom. Comments?
If the native implementation is not possible and I would end up implementing some specific codec with C#...well that would probably be quite a massive task. But having to choose C# over native, could I run into problems with codec performance? I mean.. is C# THAT much slower?
Thank you.
I've not seen an OEM that shipped their own IDE, but it's certainly possible. That shouldn't change how apps can created, however. It's possible that they've done a lot of work to make sure only things from their IDE work, but that would be a serious amount of work for not that much benefit, so I'd think it's unlikely.
As for your specific questions:
The OS is Windows CE, not "based on" it. The OS is, however, componentized, so not all pieces are going to be available. An SDK generally provides a mechanism to filter out what isn't available. You can actually use any SDK that targets the right processor architecture, but if your app calls into a library for something that isn't in the OS, then you'll get at the very least an error. For managed code this is all not relevant because the CF isn't componentized. If it's there, and CF app can run (and if it's not, you can often install it after the fact). This means that if the platform supports the CF, then you can write a CF app and run it. That app can then call native stuff via P/Invoke (unless, of course, the OS creator decided to add security to prevent that. This is possible in the OS, though I've never seen it implemented).
Yes, compiled code is just "instructions". For native, yes, they are processor instructions. For managed, they are MSIL instructions that the managed runtime in turn converts to processor instructions at JIT time. If your target is an ARM platform, you cannot use an x86 compiler. Broadly speaking, you need to use the correct Microsoft compiler that support Windows CE, and call that compiler with the proper switches to tell it not only the processor architecture, but also the target OS because the linking that needs to be done will be different for OS-level APIs and even the C runtimes. The short of this is that for your platform, you need to use Visual Studio 2008 Pro.
For native apps, you need some SDK that targets the same OS version (CE 6.0) and processor architecture (e.g. ARMv4I). Having it match the OS feature set is also useful but not a requirement. For managed code, you can just use the SDKs that ship with Studio because managed code is not processor-dependent. Still, you have to go back to Studio 2008 because 2010 doesn't have any WinCE compilers.
If you've found an existing library, then you can try to use it. Things that might impede your progress are A) it's unlikely to use an SDK you have so you probably have to create new project files (painful, but workable) and B) if it uses features not available in your OS, then you'd have to work around those. If you're missing OS features, you're probably out of luck but if it already has a media player and codec, I suspect you'll be ok.
Don't implement this in managed code. Seriously, just don't do it. Could you? Yes. Performance could probably be made to be nearly the same except to avoid GC stuttering you're going to have to basically create your own memory manager. The amount of work involved in this path is very, very large.
I'm trying to find a good GUI library I could use to create a program on the computer that connects to a microcontroller by USB. I've never done any GUI work before but I have done a lot of webpage design/tools. We are going to program the microcontroller with C but I don't think the GUI will need to be C. It needs to work on Windows, so probably compile on Windows too. I've also never done any USB transmission but I'm hoping to take it one step at a time.
Right now I'm looking at using GTK but it needs a bunch of other things to download with it. I'm also going to look at QT and someone else suggested making a Windows Forms Application. There's a lot of options out there so I'm having trouble figuring it out.
As for my requirement, it just needs to be a very simple GUI that has a few control buttons, a display area (info from microcontroller), a notification area (basically error messages go here), and maybe a graph. I've included a prototype GUI help give you an idea of what I'm doing.
Edit: It needs to run and compile on Windows. We don't really have a budget for it, free open source is preferred. I don't need something elaborate and fancy, I just want to get it done as fast as possible.
We are using a TTL-232R cable, UART interface. I know nothing about USB transmission, school has crushed me.
From what you've specified, I would set base-camp up at Java.
Java in Eclipse to write the code.
Java Swing libraries (helped by the WindowBuilder plugin for Eclipse) to "draw" the GUI. It is very easy to create "Windowsy" GUIs using these.
JFreeGraph libaries to allow you to create graphs very easily, again from within Eclipse.
RXTX library for "virtual COM port" serial communication within Java (it doesn't sound like you're using proper USB, but just RS232 with a USB adapter).
Your created GUI would run on any machine with Java installed, which is not a big ask for the end user. You can even create a Windows executable/installer from the resulting Java files if you wanted it to be a (apparently) native Windows application.
And - bonus - all the tools mentioned are free as a bird.
It will kind of depend on what kind of compiler, IDE, etc you will settle on. If you are going to windows cold, and
money is an issue, then open source is always a good thing to look at. I have enjoyed using eclipse and Code::Blocks IDEs. For C/C++, I use minGW. In terms of GUI plug-ins, HERE are some conversation with GUI recommendations specifically for use with Code::Blocks.
If money is not an issue, I have use National Instruments LabWindows/CVI full dev kit forever. It is one of the easiest ANSI C compilers/IDE I have ever used. It is only ANSI C, but has extensions to make using instrumentation easy. I have written a little USB stuff (not much), sockets, instrumentation, and many GUI apps.
Please comment what tools you currently prefer, I may have other suggestions.
Lazarus CodeTyphon has cross platform native compiler with GUI working on every supported platform. It supports 8 OS-CPU host layers (Win32, Win64, Linux32, Linux64, FreeBSD32, FreeBSD64, Solaris32 and Solaris64), and 25+ OS-CPU target layers. It also incorporates many graphical widgets and SCADA like behaviour with PascalSCADA and other components. There are wrappers for LibUSB.
I would use Microsoft Visual Studio to develop the GUI. They offer a free version called Express. I would use the C# language but MSVS supports other languages as well so just choose whichever you're most comfortable with. The best thing about MSVS is that there are millions of developers out there, which means that you will be able to search for and find lots of examples for how to use an RS-232 COM port or USB interface. I'm guessing that you'll be able to find GUI objects for graphing and other objects as well. (The basic stuff like buttons and edit boxes is all built into MSVS.)
BTW, you need to sort out whether you're using an RS-232 COM port or a USB interface. They're both serial interfaces but they're not the same thing. Either could work.
I need to port an application (written in XE2) to Mac.
My application is split into a simple UI executable (single-threaded) and an invisible engine (which heavily relies on OmniThreadLibrary 3.02 and Cromis DirectoryWatch)
Both EXEs communicate via Cromis.IPC
This is to say that I mainly have issues with these 3 components (OmniThreadLibrary, Cromis IPC & DirectoryWatch)
My focus right now is the Engine, which has most of the code.
My question is: Is there something similar to OmniThreadLibrary, Cromis DirectoryWatch & Cromis.IPC for Mac? (Whether with lazarus or XE2 with Mac as a target compiler)
The answer will help me a lot in deciding whether I should use Delphi XE2 or Lazarus (an IDE which I'm not familiar at all with) and see what's the best long term approach to offer/support both Windows & Mac with the minimum headaches
I am answering the part of your question dealing with compiler /IDE. I've used Lazarus and I must say that it won't take you too long to get up to speed (except for your exact requirements). Lazarus is getting more and more professional; a number of the developers are professional Delphi / XE2 coders by day. I think since you want to make your application available on Mac, you are going to have some work cut out anyway. But, it you decide to use Lazarus, you can for the most part build applications for Linux, Mac, and Windows without much effort ... most things just build right for each of the platforms from the same mostly unmodified source. Of course, as you say, your code heavily leans on OTL With OTL being a windows only library, I think you are going to have your work cut out for you. (read ... you might have to write an equivalent library yourself, or have someone do it for you) As for Chromis Directory watch, I haven't found anything yet.
I hope this helps a bit. CHEERS
This Lazarus tutorial shows that threading functionality built in. I am unaware of an equivalent library for what you are searching for. CHEERS
I want to write something like DaemonTools: a software that presents itself to the system as a real device (a DVD-ROM in the previous example) but it reads the data from a file instead. My requirement is not limited to DVD-ROM. The first goal is a joystick/gamepad for Windows.
I'm a web developer, so I don't know from where I could start such a project. I believe it will have to be written in C/C++, but other than that, I have no clue where to start.
Did anyone tried something like this and can give me some starting tips ?
Most drivers are written in either C or C++, so if you don't know those languages reasonably well, you'll want to get familiar with them before you start. Windows programming uses a lot of interesting shortcuts that might be confusing to a beginner - for example PVOIDs (typedef void* PVOID) and LPVOIDs (typedef void* far LPVOD;). You'll need to be happy with pointers as concepts as well as structures because you'll be using a lot of them. I'd suggest writing a really straightforward win32 app as an exercise in getting to grips with the Windows style of doing C/C++.
Your next port of call then is to navigate the Windows Driver Kit - specifically, you'll need it to build drivers for Windows. At this stage my ability to advise really depends on what you're doing and the hardware you have available etc, or whether or not you're really using hardware. You'll need to know how to drive your hardware and from there you'll need to choose an appropriate way of writing a driver - there are several different types of driver depending on what you need to achieve and it might be you can plug into one of these.
The windows driver kit contains quite a large number of samples, including a driver that implements a virtual toaster. These should provide you with starting points.
I strongly suggest you do the testing of this in a virtual machine. If your driver successfully builds, but causes a runtime error, the result could well crash windows entirely if you're in kernel-mode. You will therefore save yourself some pain by being able to revert the virtual machine if you damage it, as well as not having to wait on your system restarting. It'll also make debugging easier as virtual serial cables can be used.
This is quite a big undertaking, so before you start, I'd research Windows development more thoroughly - check you can't do it using the Windows APIs first, then have a look at the user-mode driver framework, then finally and only if you need to, look at the kernel level stuff.
I have written a code in visual c++ , which is a sort of GUI used in virtual com PORT connection. However , i need to run that code in linux so that i can make it an open source. Since , visual c++ doesn't work in linux, I need to find out some alternatives.
So, please me what all alternatives I have
Thanks for your valuable time..!!
i need to run that code in linux so that i can make it an open source.
No, you can license code as open source without it running on linux.
If you simply want your code to run under linux you need to learn how to port from VC++ to Linux/GNU. It's not simply a matter of re compiling it.
See the following URL for advice and google search for more if required: http://www.johndcook.com/blog/2008/05/29/porting-visual-c-code-to-linuxgcc/
In my experience you can get a looooong way with
http://www.winehq.org/docs/winelib-guide/winelib-toolkit
winemaker (doing things as making all your includes case-sensitive correct on Linux)
winegcc (linking to the winelib runtime libs so you can have _WinMain and stuff like that just work)
Of course there are libraries that simply don't exist. Also, installing an SDK can be daunting; winetricks.sh is very helpful in that department. Also, you can consider 'XCOPY' deploying the SDK into your linux build tree and working with that;
This has successfully let me cross compile MSVC projects linked with 3rd party windows libraries in the past. Note minor incompatibilities due to having slightly different linkage semantics with gcc/GNU ld by default; expect this to affect areas like RTTI and exceptions thrown across DLL boundaries).
YMMV
Edit I want to confirm the fact that you can have perfectly valid opensource code for windows only, and you can build it using Visual Studio too. If you want to be nice to your (prospective) contributors, make sure you only depend on Visual Studio Express C++ (not MFC, e.g.) but hey, that's really up to you!
which is a sort of GUI used in virtual com PORT connection
This will be probably hardly portable (because of the BIG differences how virtual ports and GUI are handled in linux and windows - unless you used some cross-platform library already in Windows).
You can release your code as OpenSource for Windows only.