How can in retrieve the Operating system context for my application programmatically?
As others have posted this site answers the question: http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx
Use the Version Helper API
To know whether this will actually suit your needs though -Why- you want to do this needs to be examined. If this is related to feature support testing, then you may want to read the suggestions here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).aspx. The article discusses some various ways to perform feature detection such as:
A combination of LoadLibrary and GetProcAddress
GetSystemMetrics e.g. GetSystemMetrics(SM_CMONITORS)
Of course, this is more relevant if you are directly coding outside of the .NET world.
Related
I'm trying to modify a Windows kernel-level disk driver to properly respond to updated control codes. For example, it only had a handler for the obsoleted IOCTL_DISK_GET_DRIVE_GEOMETRY control code, but not the newer IOCTL_DISK_GET_DRIVE_GEOMETRY_EX control code, so I added that.
Of course, I updated the driver to use all the new Windows structures and functions too, like the IoReadPartitionTableEx() function and the DRIVE_LAYOUT_INFORMATION_EX structure (I am trying to add GPT support to the driver). The issue is, when I use the disk driver, I can see (using DebugView) that Windows (I think it's Windows... perhaps it's something else...) is still sending the old IOCTL_DISK_GET_DRIVE_GEOMETRYcontrol code to my driver. I would like Windows to send the newer control codes to my driver. Is it even Windows that is sending these control codes? Is there perhaps some other layer between Windows and the driver that I'm just not yet aware of?
Is the driver supposed to somehow identify its "type" to Windows, so that Windows knows exactly how to "speak" to it? How does Windows know exactly which control codes to send to a particular driver? I've Googled around for answers to these (seemingly very basic) questions, and haven't found a clear answer, which leads me to believe that I've fundamentally misunderstood something about Windows drivers here. Does my question even make sense?
The OP has 5 questions (count based on number of question marks). Each of the following answers the questions in the same order as they were asked in OP.
To find out who is calling your driver with IOCTL_DISK_GET_DRIVE_GEOMETRY put a breakpoint on the handler for that IOCTL in your driver. When break occurs then look at the callstack. You'll see who called.
You'll actually have a layered set of callers. This will answer your question about layers.
Windows knows about your drivers capabilities in several different ways. If you have a miniport driver, then there is a minimal set of functionality that each type of miniport must implement.
In addition there are APIs to StorPort miniports can use to indicate optional capabilities. For example StorPortInitializePerfOpts is used to inform StorPort about various perf optimizations in StorPort miniports. To better answer this question please provide the type of driver that you have. In case you're not familiar with the various driver types, I suggest you read this from MS HW dev center. In fact you may want to read it anyway.
The question assumes Windows sends different control codes to different drivers based on some hypothetical driver attribute. However the model Windows uses is like that mentioned in the previous answer. There are base capabilities based on the driver model and then in some cases APIs to communicate capabilities. (In other cases it is up to the driver to indicate it doesn't support a particular operation.)
There is another aspect to the answer and that is Windows and non-Windows components are free to choose whatever control codes they want. So a 3rd party disk partitioning program could use the older geometry IOCTL, even though a newer one exists because it wants to be compatible with earlier versions of Windows. Or a Windows component (eg Storage Spaces) could use a newer IOCTL because it doesn't carry about backwards compatibility.
(This question is asking for an opinion, so this answer is my opinion). Assuming by "question" you mean "questions", then I'd say more or less. But if this is your first (or second) foray into Windows drivers, I again suggest reading the relevant MS documentation (linked above).
Finally, even though the OP doesn't ask directly, it sounds like there is a question "How do I test the IOCTL_DISK_GET_DRIVE_GEOMETRY_EX functionality I've added?". The simplest way, IMO, is to write a Win32 test program. To invoke and display this one IOCTL would only take 20 or so lines of code. Which would be easier and quicker then, say, scripting DISKPART or similar.
I have written an simple applications in C++, and I need to connect with any RIA just for viewing the process ... is there is any good RIA based on C++
Qt is a good, popular cross-platform GUI library for C++.
I don't know whether it matches your definition of "RIA", though.
Silverlight is the nearest framework for you. You may find this Stackoverflow question interesting.
Update
After seeing your comment, I'd recommend you using ISAPI or CGI programming in C or C++
Update 2
After figuring that you need to execute C++ code from browsers, The answer is ActiveX. But portability is an issue, rather.
Generally speaking, this is difficult to do. Clients don't trust running arbitrary C++ code from the internet, because people don't want every website under the sun to be able to install malware, and generally hijack the entire machine, every time they visit a web site. In the general case, therefore, what you want is not really possible.
If you're willing to require the user to answer a ton of prompts, and are okay restricting your application to Internet Explorer on Windows, you could familiarize yourself with COM and write an ActiveX control.
I would strongly advise against doing so, however.
Have you looked at Qt? It comes with Webkit built-in. It is also more portable than other RIA implementations. BTW, most RIA implementations run on language virtual machines that are in turn implemented in C or C++ :-)
Microsoft has this nice little feature called CardSpace. This is a Microsoft implementation of InfoCards. Microsoft has a nice document which explains how it can be used, which is useful. And doing a Google search doesn't provide me many useful answers but it does provide an enormous amount of noise. (Mostly because people wonder what it is or sites offering this DLL as some kind of download. The latter is suspicious since it's just part of Windows Vista and .NET 3.0 and higher.)
Basically, I need to call all functionality from this DLL within Delphi 2007. If there's a C++ header for this DLL then I can convert it. Or maybe some other information about it's functions, parameters, datatypes and whatever more.
There is an InfoCard.h file included with Microsoft's Windows SDK which should be what you need. Bit of a hefty download for a single file if you don't already have it - you might be better visiting the MSDN reference for the CardSpace API and getting the info from there.
I'm looking to add full text indexing to a Linux desktop application written in C++. I am thinking that the easiest way to do this would be to call an existing library or utility. This article reviews various open source utilities available for the Gnome and KDE desktops; metatracker, recoll and stigi are all written in C++ so they each seem reasonable. But I cannot find any notable documentation on how to use them as libraries or through an API. I could, instead, use something like Clucene or Xapian, which are generic full text indexing libraries. They seem more straightforward but if I used them, I'd have to implement my own indexing daemon, an unappealing prospect.
Also, Xesam seems to be the latest thing, does anyone have any evidence that it works?
So, does anyone have experience using any of the applications or libraries? How did you use it and what documentation was useful?
I used CLucene, which you mentioned (and also Lucene.NET), and found it to be pretty good.
There's also Strigi which AFAIK works with Xesam and is the default used in KDE.
After further looking around, I found and worked with Recol. It believe that it has the best C++ interface to a full text search engine, in this case Xapian.
It is important to realize that clucene and Xapian are both highly complex libraries designed primarily for multi-user server applications. Cutting them down to a level appropriate for a client-system is not easy. If I remember correctly, Strigi has a complex, pure C interface which isn't adapted.
Clucene also doesn't seem to be that actively maintained currently and Xapian seems to be maintained. But the thing is the existence of recol, which allows you to index particular files without the massive, massive setup that raw Xapian or clucene requires - creating your own "stemming" set is not normally desirable, etc.
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 3 years ago.
Improve this question
What are your tips on implementing a plugin style system?
In C (and I think C++ too although I haven't done it myself), this is most typically done using dynamically loaded modules. The API:s for such are platform-dependent.
On POSIX (Linux), you use the dlopen() family of functions. Basically you build your plugin separately, then load it at run-time, look up its symbols by name, and can then call them.
For Win32, there is LoadLibrary() which does something very similar, you build your code into a DLL.
For a handy wrapper that makes all of these easy and transparent, check out GLib's GModule API.
In the '92/'93 time frame I worked on a plugin architecture for Aldus PageMaker, which was coded in C++. PageMaker was built on a C++ OOP framework called VAMP, which assisted its portability between Mac OS and Windows.
So we tried to use the features of C++ to build a plugin architecture. This proved to be very problematic for C++ classes due to the so-called brittle base class problem. I proceeded to write a paper that was published in journals and that I presented at OOPSLA '93 in a reflection workshop. I also made contact with Bjarne Stroustrup at a Usenix conference in Portland and proceeded to dialog with him for several months, where he championed the issue of dealing with the brittle base class problem on my behalf. (Alas, other issues were deemed more important at that time.)
Microsoft introduced the COM/DCOM system and for that platform that was looked on as a viable solution to the problem. C++ could be used as an implementation language for COM via abstract classes used to define COM interfaces.
However, these days developers shun away from COM/DCOM.
In contrast, NeXT devised a plugin architecture using Objective C in the early 90s in the NeXT Step framework. Today that lives on vibrantly in Mac OS X on Apple's computers and important platforms such as the iPhone.
I submit Objective C enabled solving the plugin problem in a superior manner.
I personally regard the brittle base class problem of C++ to be it's most fatal flaw.
If were building a plugin architecture with the C-based family of languages, would do so using Objective C.
The best platform and language neutral advice I can give is this:
Design your entire app around the plugin SDK.
IMO, a plugin SDK should not be an afterthought. If you design your app to basically be an empty shell which loads plugins, then the core features are implemented in your own SDK, you get the following benefits:
High modularity of components, and clear separation of purpose (it kind of forces your architecture to be good)
It forces your SDK to be really good
It allows other third party developers to make extremely powerful, core-level features as well
New developers/hires can easily start work on a major new feature without having to touch the main app - they can do all their work in a plugin (which prevents them screwing up anything else)
In C/C++, you probably use dynamic link libraries and either function pointers (C) or interfaces (classes solely consisting of pure virtual methods, for C++). However even if you use Javascript, I'd still recommend the above architecture.
Qt provides QPluginLoader:
http://qt-project.org/doc/qt-4.8/qpluginloader.html
If you need/want more fine grained control, Qt also provides a means to load libraries on the fly with QLibrary:
http://qt-project.org/doc/qt-4.8/qlibrary.html
Even better, these are portable across platforms.
This may not be what you're looking for, but you could embed a scripting language in your application, such as Lua. Lua was designed to be embedded in other programs and used as a scripting language for writing plugins. I believe it's fairly easy to add the Lua interpreter to your program, though I don't know Lua so I can't vouch for how effective of a solution this would be. Others with more experience with Lua, please add comments about your experience with embedding Lua in another application.
This would, of course, mean that your plugins need to be written in Lua. If you don't like Lua then the de-facto standard Perl, Python and Ruby interpreters are all written in C, and can be embedded in a C program. I know of a number of programs that use these languages as scripting language extensions.
However, I don't know what you're looking for, as your question is a little vague. Perhaps more information about what you want people to be able to do with said plugins would be appropriate. For some tasks, a full-blown scripting language may be a bit overkill.
I have written an article about how to implement a plugin system using Dynamic Linking Libraries. The article is written from the point-of-view of a Windows programmer but the technique can be applied to a Linux/Unix type environment.
The article can be found here: http://3dgep.com/?p=1759
The main point is, you should create a "common" DLL that is implicitly linked by both the main application (the core application) and by the plugin implementations. The plugins can then be explicitly linked and loaded dynamically at run-time by the core application.
The article also shows how you can safely share static (singleton) instance of a class across multiple DLLs by using the "common" DLL.
The article also shows how you can export a "C" function or variables from a DLL and use the exported functions in the application at run-time.
It's best to use a framework like ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) that shields you (as good as possible) from platform specific coding.
ACE contains a plugin framework that is based on shared libraries that you can use to create dynamically assembled applications.
For a higher level abstraction check out CIAO (http://www.cs.wustl.edu/~schmidt/CIAO.html) the Open Source C++ implementation of the CORBA Component Model.
Look at Poco Class Loader, it can be interesting for you.
I have written a plugin library Pugg that loads C++ classes from dll files and here is the logic I used:
User exports a c function from dll that has a unique name. This name has to be unique enough as functions cannot be distinguished using their arguments while loading from dlls.
C function registers one or several factory classes called "Driver". Every Driver class is associated with a string. When the main application wants to create a class, it gathers the related factory class using the associated string. I also implemented a version checking system to not load old plugins.
Dll loading is accomplished using the LoadLibraryA and GetProcAddress functions (Pugg currently works on windows).
One thing worth mentioning is that main application and dlls should be compiled using the same compiler and using the same compilation options (release/debug modes, optimization settings, stl versions etc...). Otherwise there might be issues with mapping of classes.
I have had some success using a fairly naive system:
Create API Specification for plug-ins
Use a singleton plug-in manager
Use LoadLibrary/GetProcAddress based run time dynamic linking
Implement Inversion of control based event handling for notifying the plug-ins
This podcast on plugin architectures might also be interesting.