I'm looking to create a "driver" I guess for a custom file system on physical disk for Windows. I don't exactly know the best way to explain it, but the device already has proper drivers and everything like that for Windows to communicate with it, but what I want to happen is for the user to be able to plug the device in to their PC, have it show up in My Computer, and give them full support for browsing the device.
I realize it's probably a little scary thinking about someone who doesn't know the basics of doing something like this even asking the question, but I already have classes and everything constructed for reading it within my own app... I just want everything to be more centralized and without more work from the end user. Does anyone have a good guide for creating a project like this?
The closest thing I know of to what I understand from your description is an installable file system, like the Ext2 installable file system that allows Windows computers to work with
Linux originating ext2 (and to a certain degree ext3) filesystems.
Maybe that can serve as a starting point for your investigations.
As an alternative approach there's the Shell extension which is a lot less complicated than the IFS. The now-defunct GMail shell extension used that approach, and even though it's become nonfunctional due to changes in GMail, it can still serve as inspiration.
Your options are:
Create a kernel mode file system driver. 9-12 months of work for experienced developer.
Use a framework and do everything in user mode. A couple of weeks of work to get the prototype working. The only drawback of this approach is that it's slower, than kernel-mode driver. You can play with Dokan mentioned above, or you can use our Callback File System for commercial-grade development.
I think you need to look through the Windows Driver Kit documentation (and related subjects) to figure out exactly what you're looking to create.
If you're intending to rely on the drivers that already exist, i.e. you don't need to actually execute your code in kernel land to communicate with it, I would recommend you take a look at FUSE for windows Dokan
If you indeed need to run in kernel space, and communicate directly with the hardware, you probably want to download windows DDK (driver development kit). Keep in mind that drivers for communicating with a block device and filesystems are separated, and it sound like you're talking about the filesystem itself. I believe that anything you run in kernel space will not have access to the c++ runtime, which means you can only use a subset of c++ for kernel drivers.
Related
I've received a dk 3200 kit recently. I know it's old but I would like to start using it to have more of a challenge than just arduino. It came with the board, an st flashlink FL-101B and some cables. I do not have the install disc, but I found the software for psd soft express online. It doesn't work with current windows 7 64bit. If I could use my arduino to program it, that would be great! Or maybe just do it through USB or the parallel ports? I've read that st provides a stm32 library used to help make code. If that works for my mcu, I'll use that.
Thanks
ST is a company that loves to re-organize their website and break links, but a data sheet for a part of what seems to be the same family as on your board is available from a toolchain vendor at:
http://www.keil.com/dd/docs/datashts/st/upsd321x_ds.pdf
On page 118 this seems to indicate that programs can be loaded using JTAG In System Configuration commands, which may be somewhat standardized though quick searching isn't producing a lot of leads. A reference is also made to ST's AN1153 which would be worth trying to locate a copy of, however it's not entirely clear if that will say anything about the programming, or if it only covers the additional two optional signals which have been added for hardware acceleration of the interface.
In theory, if you can find sufficient information about this device (looking at related devices may provide clues) then you should be able to craft a programming from an Arduino or anything else that can be adapted to twiddle bits at the appropriate voltage/threshold levels.
In practice, you may be better off trying to find an old Windows XP box, or even trying to run that software on a virtual/emulated environment and trap the I/O access either to proxy or to figure out what it is doing and reverse engineer your own programmer.
But unless you have a large installed base of boards using these chips, or particular need some unusual feature of them (I thought I saw something about a built-in CPLD?) it's really not going to be worth the effort.
I've been looking into centralising my computer game saves to make it easier to backup and restore as well as putting them up on the cloud via dropbox but there in so may places that it makes it quite difficult. I noticed the Windows 7 and Vista now support Symbolic links so I've been playing around with that but I was wonder the follow:
Is it possible (code example or a point in the right direction) for an application (vb.net or C++) to spoof a file or folder?
E.g. Application A (a game like Diablo III or Civilization V) attempts to read or right from file A (the game save), application B (the save repository) detects this read/write request and pipes the request through itself preforming the request on file B (the actual game save in another location). Application A is in no way altered and treats the file normally.
Note: I realise there are many simple ways of preforming the same task in essence such as monitoring the use of Application A or periodically checking file A and copying it if it has been altered since the last check etc but all these methods have draw backs and less interested in making it work than if it is possible.
It is entirely possible to do this through a file system filter driver. For information about these, take a look here:
http://msdn.microsoft.com/en-us/windows/hardware/gg462968
Filter drivers can hook into CreateFile operations and redirect the create to a different place if you want, but they are much harder to write as compared to normal applications. They run in kernel mode and must obey the limitations of drivers.
You can "fake" special folders, like control panel does, but I don't think you can create anything accessible/writeable (in an easy way). I might be wrong though. I had the same idea once too (as a compatibility step for some company stuff), but couldn't find anything supporting an easy way to do it. It seems like it might be easier to be done on Unix systems (but that's obviously no option here). Also, I wouldn't expect any nice or easy solutions for .net.
Only approach I could think about right now, would be highjacking the according API calls (e.g. FileOpen) to reroute/manipipulate them (similar to what root kits do), but I wouldn't say that's a good idea, considering it might be detected as possible malware or cheats by things like punkbuster or antivirus solutions.
Yes or no depending on (using your terms) the level of abstraction that Application A is using.
If Application A is performing a CreateFile wto start access and passing a fixed filesystem path then Application B would need to emulate a file system and do so in the kernel.
On the other hand if Application A were to user HTTP with RESTful URLs then the HTTP server could answer all requests from files or by dynamically creating the content.
So the question can only be answered in specific by knowing the details of Application A.
I'm writing a metro app for Windows 8 (C# 5) to act as a power control app allowing the user to enable and disable various devices the computer will likely have. For now, I'm just thinking bluetooth and wireless network adapter. Eventually I'll add other devices, but one step at a time.
The main aspects I'm worried about is reliably finding devices, enabling and disabling them, and querying their state (is the device already enabled?). I need to be able to do any of these on a variety of machines with a variety of different devices, including multiple NIC or Bluetooth hardware setups.
I've looked into devcon on Win7, but I'm worried about reliably discovering the devices. If I grab the wrong devices, who knows what I'll be disabling, not to mention it won't disable what I intend to disable. Also I haven't tried it on Win8 yet and it may not be a portable app, I don't want people to install it and then my app.
WMI is powerful but always a bit intimidating to wander around in without a little guidance. If that's my best bet, I would appreciate some resources.
Command line or .Net library is what I'm hoping for, but I haven't tried this kind of stuff before so I'm open to any other alternatives. Also, any foresight into working with other devices like cellular network cards or devices I haven't thought of yet would be great.
Much of what you want (eg Bluetooth APIs) are indeed sandboxed away from Metro apps. There are some substitutes in the Windows namespace, though whether they will meet your needs I don't know. Take a look at http://msdn.microsoft.com/en-us/library/windows/apps/hh464945 which has links to the suggested alternatives for working with devices.
Specifically the Windows.Devices.Enumeration namespace says it's about finding devices. However as I read the page it seems like it's more about discovering and less about controlling. I wouldn't be surprised to find you can't control them. But that's where I'd start digging.
I have a program that is using a configuration file.
I would like to tie the configuration file to the PC, so copying the file on another PC with the same configuration won't work.
I know that Windows Activation Mecanism is monitoring hardware to detect changes and that it can tolerates some minor changes to the hardware.
Is there any library that can help me doing that?
My other option is to use WMI to get Hardware configuration and to program my own tolerance mecanism.
Thanks a lot,
Nicolas
Microsoft Software Licensing and Protection Services has functionality to bind a license to hardware. It might be worth looking into. Here's a blog posting that might be of interest to you as well.
If you wish to restrict the use of data to a particular PC you'll have to implement this yourself, or find a third-party solution that can do this. There are no general Windows API's that offer this functionality.
You'll need to define what you currently call a "machine."
If I replace the CPU, memory, and hard drive, is it still the same computer? Network adaptor, video card?
What defines a machine?
There are many, many licensing libraries out there to do this for you, but almost all are for pay (because, ostensibly, you'd only ever want to protect commercial software this way). Check out what RSA, Verisign, and even microsoft have to offer. The windows API does not expose this, ostensibly to prevent hacking.
Alternately, do it yourself. It's not hard to do, the difficult part is defining what you believe a machine to be.
If you decide to track 5 things (HD, Network card, Video card, motherboard, memory sticks) and you allow 3 changes before requiring a new license, then users can duplicate the hard drive, take out two of the above, put them in a new machine, replace them with new parts in the old machine and run your program on the two separate PCs.
So it does require some thought.
-Adam
If the machine has a network card you could always check its mac address. This is supposed to be unique and checking it as part of the program's startup routine should guarantee that it only works in one machine at a time... even if you remove the network card and put it another machine it will then only work in that machine. This will prevent network card upgrades though.
Maybe you could just keep something in the registry? Like the last modification timestamp for this file - if there's no entry in the registry or the timestamps do not match then fall back to defaults - would that work? (there's more then one way to skin a cat ;) )
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm an MFC programmer. I just had my first taste of Vista (on a VPC... Yup, I'm late). I should be evaluating things in depth in the coming days. On taking a casual look, I noticed two major changes:
The shell is new
User Access Control
Event Viewer has changed (would like more info on this)
What other new features should I look out for from a programmer's point of view?
There's a significant set of changes depending on what sort of software you write.
It's never a bad idea to check out the Windows Logo Certification (for Vista). There's a link to the Software technical requirements here. It always gives you a bit of an idea what to avoid doing (and what to design for).
In my opinion, Vista mostly started to enforce [existing] Logo certification requirements, in particular:
Don't write to HKLM
Don't save application data under the Program Files directory
Don't assume administrative permissions
Do save data to the user's application data directory
Regarding User Access Control (new to Vista), It's also a good idea to get across Manifest files. The best thing I could find on them is this blog entry here.
Windows Drivers are under higher scrutiny under Windows Vista and pretty much require certification IMHO.
The TCP/IP stack was rewritten and so too the audio subsystem (and multimedia streaming etc). Obviously advances in graphics, plus the inclusion of DirectX 10 and usual rollout of an updated Media Player, etc.
Sorry, I also forgot to mention that Microsoft replaced ActiveSync (for Windows Mobile) with a completely new framework in Vista.
Vista is much more strict about enforcing rules that you were supposed to follow for XP anyway.
For example, you're not supposed to do anything that requires write access to your program's install folder. In XP a lot of programmers got away with breaking that because so many users run as adminstrator, but Vista will actually enforce it. A bunch of folders did move around ("Users" instead of "Documents and Settings", my Documents is different, etc), but if you're using the correct methods to retrieve those paths rather than assuming they're always in the same place you'll be fine.
Perhaps wikipedia's Features new to Windows Vista and possibly Features removed from Windows Vista will be of use to you.
Processes and resources have "integrity levels". A process is only able to access resources at or under its own integrity level.
If you ever do any work with IE extensions this will become a PITA when you want to access something and discover that everything has a higher integrity level than IE in protected mode (default).
Well, from a programmer's point of view, WPF is "built in" to the system. That means that if you target an app to the 3.0 version of the .NET Framework, it should be able to install on Vista without a .NET Framework Install.
DirectX 10 is also new in Vista, but I assume if you didn't know that, you probably won't be programming against it.
Search is pervasive. Numerous kernel improvements. SuperFetch (friggin' awesome if you have enough RAM). IMO Vista goes to sleep and wakes up a LOT easier and more reliably than XP ever did. I/O priority -- now apps like AntiVirus and search indexers can request lower priority for disk access than they did in XP or before. That makes the user experience much more enjoyable when something's indexing the drive or a scan is running. All in all, Vista is good stuff IF you have gobs and gobs of memory to throw at it. I run Vista x64 with 4GB of RAM, and I actually like it.
The audio subsystem has been redeveloped, so if you do anything audio related it is worth checking very carefully if everything still works.
Although many of the older API calls still work, some may not work as expected.
As a simple example, sound devices have much longer and more descriptive names than in XP, but if you continue to use the older APIs then you may find these longer names are truncated.
Oh, yeah. There's a completely different driver model where much of the code is kicked out of kernel space and back into userland, to prevent poor drivers from trampling over the system. So if you do any driver work it's almost like starting over from scratch.
1- Machine with Vista have usually more Ram, this is a good news for you :)
2- Path to "Program files" are splitted in 2 : \Program Files (x86)\ and \Program Files\
3- My Document has changed
VIRTUALIZATION is also an interesting and necessary feature of vista.