I'm looking at developing a device which will need to support Ethernet over USB (hosted in Linux, XP, and Vista). As I understand it, Vista and Linux support the industry standard USB CDC. However, in classic Windows style, XP only supports it's own Remote NDIS. So, now I'm thinking of just bowing down and doing it over RNDIS, as opposed to rolling my own CDC driver for XP.
I've been reading some older documentation that says even XP is pretty buggy with NDIS (suprise!). Does anyone have experience with XP's RNDIS drivers? Are they safe for product development? Any insight would be much appreciated.
We use RNDIS at work. and I've found that it blue screens my machine every now and again (about every month or two). However others (at my work) have not had this happen, so it could just be the particular device that I use.
I think it is stable enough for development, so give it a go.
The problem here is that Linux does not support RNDIS in the host mode, and you can't develop custom driver due to MS RNDIS license restrictions. MAC does not support RNDIS as well due to same reason (licensing).
So if you need multiplatform solution you need a standard approach which is CDC/ECM.
There is number of available CDC/ECM XP/VIsta solutions in the market,you can google for them i don't want to advertise our solution here :)
After doing my own research and testing, a single NDIS device works reasonably well. However, if you are at all needing to support multiple NDIS devices, you are out of luck. My system became extremely unstable and was essentially unusable. This was very reproducible.
I would not recommend NDIS in any type of multiple-device scenario.
if you are looking for commercial solution, Jungo does provide decent ECM solutions works for Windows/Linux/Mac. The only problem is that you have to pay them non-trivial royalty fee if you are going for a mass volume product.
Related
I'm trying to implement an AVRCP/A2DP connection between my Android phone and my car PC. The A2DP bit basically works out of the box so no issue there. I want the PC to be the AVRCP CT (controller) and the A2DP sink. The phone is the AVRCP TG (target) and the A2DP source.
Where I'm having trouble is getting any sort of AVRCP connection that I can use. Windows 7 comes with a toolbar application that at least provides the basic play/pause/skip/stop type functions. So it definitely works with the software I have without any extra drivers or otherwise. However my searching has produced little results on any way to do this or documentation on creating an L2CAP connection which I believe I need.
The 32feet.NET libraries don't support L2CAP connections unless you use a Broadcom/Widcomm stack. Buying a new BT USB device may be a viable solution but at the moment I'm trying to do this all in software :). i.e. like this although there a problems noted there that weren't solve (or reported as solved)
link: How can I establish an AVRCP connection from Windows 7 (controller) to phone (target) using L2CAP on Widcomm SDK?
I'd prefer to do it C# if possible but if I had some kind of library to interface with my code, that would be fine (like the 32feet.NET library which works quite well for the things it does work on.)
This is about the closest I've got but is all a bit Greek to me and not quite enough to get me started (I'm an embedded guy):
http://msdn.microsoft.com/en-us/library/windows/hardware/ff536674(v=vs.85).aspx
Is Bluetooth really such a mess on Windows that it seems to be from my searching? There are multiple different stacks that all seem to be significantly different in terms of the API etc.
Can anyone point me in the right direction? I've done a lot of searching/reading other posts here and elsewhere and not really made any progress.
Thanks
Christian
I know this is not a direct programming question (which StackExchange site would fit better?) I just ask it here as I'm not sure where to post it alternatively.
Has the driver for multi-touch on Windows 7 a specific name? Windows 7 has multi-touch support if the hardware sends specific messages and they get translated to their W7 equivalent. How is the driver sub-system named? I think it's in the context of HID devices, but is there something more explicit? I should explain it to someone and I never thought about the name of that software.
I have described it as a driver for windows 7 and not named it specifically. Found out that there is no need to name it exactly. Hearing it is a vendor provided driver was just enough information for the audience.
I'm creating an application that needs to use some kernel level modules, for which I've divided the app into 2: one user-level program and one kernel level program.
After reading about device drivers and walking through some tutorials, I'm a little confused.
Can there be a device driver without any specific device associated with it? Is there anything other than the device driver (kernel code or something) which works in kernel mode?
How do anti-virus programs and other such applications work in kernel mode? Is device driver the correct way or am I missing something?
Yes, device drivers can work without an actual piece of hardware (i.e. the device) attached to the machine. Just think of the different programs that emulate a connected SCSI drive (CD-ROM, whatever) for mounting ISO images. Or think about TrueCrypt, which emulates (removable) drives using containers, which are nothing more than encrypted files on your hard drive.
A word of warning, though: Driver development requires much more thought and has to be done more carefully, no shortcuts, good testing and in general expects you to know quite a good deal about the Windows driver model. Remember that faulty and poor drivers put the whole system's stability in jeopardy.
Honestly, I don't think reading a tutorial is sufficient here. You might want to at least invest in a decent book on that subject. Just my 2 cents, though.
Sorry, but the Windows Internals book is more of a general reading for the curious. I cannot recommend it if you want to engage in driver development - or at most as prerequisite reading to understand the architecture. There are plenty of other books around, although most of them are a bit older.
Depending on your goal, you may get away with one of the simpler driver models. That is not to say that driver development is trivial - in fact I second all aspects of the warning above and would even go further - but it means that you can save some of the more tedious work, if instead of writing a legacy file system filter you'd write one based on the filter manager. However, Windows XP before SP2 did not have it installed by default and Windows 2000 would require SP4+SRP+patch if I remember correctly. WDF (Windows Driver Foundation) makes writing drivers even easier, but it is not suitable for all needs.
The term device is somewhat of bad choice here. Device has a meaning in drivers as well, and it does not necessarily refer to the hardware device (as pointed out). Roughly there is a distinction between PDOs (physical device objects) and CDOs (control device objects). The latter are usually what you get to see in user mode and what can be accessed by means of CreateFile, ReadFile, WriteFile, DeviceIoControl and friends. CDOs are usually made visible to the Win32 realm by means of symbolic links (not to be confused with the file system entities of the same name). Drive letter assignments like C: are actually symbolic links to an underlying device. It depends on the driver whether that'd be a CDO or PDO. The distinction is more of a conceptual one taught as such in classes.
And that's what I would actually recommend. Take a class about Windows driver development. Having attended two seminars from OSR myself, I can highly recommend it. Those folks know what they're talking about. Oh, and sign up to their mailing lists over at OSR Online.
Use Sysinternals' WinObj to find out more about the device and driver objects and symlinks.
As for the question about AVs, yes they use file system filter drivers (briefly mentioned above). The only alternative to a full-fledged legacy FSFD is a mini-filter.
It is possible to load a special kind of DLL in kernel mode, too. But in general a driver is the way into the kernel mode and well documented as such.
Books you may want to consider (by ISBN): Most importantly "Programming the Windows Driver Model" (0735618038), "Windows NT Device Driver Development" (1578700582), "Windows NT File System Internals" (0976717514 (OSR's new edition)), "Undocumented Windows NT" (0764545698) and "Undocumented Windows 2000 Secrets" (0201721872) - and of course "Windows NT/2000 Native API Reference" (9781578701995) (classic). Although the last three more or less give you a better insight and are not strictly needed as reading for driver developers.
Anti-virus (and system recovery) software generally make use of file-system filter drivers. A device can have multiple filter drivers arranged like a stack, and any event/operation on this device has to pass through all the stacked up drivers. For example, anti-viruses install a filter driver for disk device so that they can intercept and scan all file system (read/write) operation.
As mentioned in above post, going through a good book would be a nice way to start. Also, install DDK/WDK and refer the bundled examples.
Either the OpenGL_ES_Programming_Guide_v1.0.2 samples or the Imagination Technologies\POWERVR SDK\OGLES2_WINDOWS_PCEMULATION_2.06.26.0649\Binaries\Demos?
Either or both above using either AMD's OpenGL ES 2.0 emulator or Imagination Technologies' PVRVFrame emulator?
Does anybody see runtime activity other than blank client areas with nothing in them for either of those two example sets under 64 bit Windows 7?
Thanks for any replies.
I can't speak for the AMD demos, but the Imagination ones get tested on a 64bit Windows 7 system internally so it seems more likely that it's a problem with your graphics setup. What card do you have and are the drivers for it up to date?
It might also be worth getting in contact directly here:
http://www.imgtec.com/forum/default.asp
or by email: devtech#imgtec.com
BTW A new version of this SDK has just been published, it might be worth trying that as well.
I have some ideas for improvements on my touchpad, ranging from the run of the mill scroll horizontally at the bottom, tapzones for right click, to more complicated ones. But I have no idea where to get started? I'm working on Windows 7 Home Premium, its an Asus laptop, and I have none of these options natively available to me. Regardless, I want to write something that anyone can use.
Where would I start?
(it'd be nice to write in c++? is that possible? what are the requirements here? what language would be recommended?)
This is dependent on the hardware and driver for the touchpad. Just because Windows 7 supports gestures and multitouch doesn't mean that your touchpad does automatically; assuming that the hardware supports it (doubtful), the driver has to be specifically updated to support it as well.
If you have none of the options available natively, you won't automagically get them just by upgrading to Windows 7.
If you plan on writing software that supports gestures or multitouch, you have no real option other than investing in the hardware as well. After all, how will you test your software without it?
Scrolling functionality such as you describe is handled in touchpad drivers, which are hardware specific. However, you may be able to accomplish what you want by using a hook. This is a mechanism by which you intercept and pre-process system messages before they're sent to applications. This could allow you to designate some areas of the touchpad for extra functionality without having to write a driver. But you're probably better off seeing if there is an existing driver with the functionality you want available from the ASUS site. If your laptop didn't come with Windows 7 originally, you're probably just running a generic driver and an actual touchpad specific driver might fix your problem.