I'm new to Win environment, trying to write code which use win kernel API but on Ubuntu 10.04 ... using mingw32 (more specifically, i586-mingw32msvc)
My code:
#include<ddk/winddk.h>
int main()
{
return 0;
}
But I'm getting to many errors with ddk/winddk.h header:
Compiling as: i586-mingw32msvc-gcc WaitForSingleObj_2.c
All errors are like this:
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/ddk/winddk.h:9208: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'NTSTATUS'
Am I missing something for this? As I tried to compile with headers iostream and windows.h, that works fine.
EDIT:
#include<ntdef.h>
#include<ddk/ntddk.h>
#include<ddk/winddk.h>
#include<ddk/ntddndis.h>
int main()
{
KTIMER *timer;
KeInitializeTimer(timer);
return 0;
}
till KTIMER its fine, now new error:
/tmp/cc0epAQA.o:WaitForSingleObj_2.c:(.text+0x1d): undefined reference to `_imp_KeInitializeTimer#4'
collect2: ld returned 1 exit status
Can anyone tell me, now which header file to include plz?
Edit: [As others commented already, and I experienced(!) PLEASE try to avoid using other platform for Windonws Kernel development]
I switched to Visual C++ Express, downloaded WDK, given additional include path from Project Property->c/c++ .. ->Additional Include directory (C:\WinDDK\7600.16385.1\inc\ddk;C:\WinDDK\7600.16385.1\inc\api;)
BUT (I hate this but!) I'm getting many compiling error like
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2143: syntax error : missing ')' before 'const'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2143: syntax error : missing '{' before 'const'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2059: syntax error : ','
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(543): error C2059: syntax error : ')'
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(550): error C2143: syntax error : missing ')' before 'const'
My Code:
#include <wdm.h>
int mian()
{
/*
* PKTIMER Timer;
*/
}
If anyone has idea please help!
Are you sure that ntdef.h is being included, either explicitly or by certain #define values being set? That's the header that defines NTSTATUS and that error message is the one gcc normally spits out when a symbol/type has not been defined.
In any case, developing Windows device drivers using a non-MS compiler will almost certainly have more problems than with Microsoft's own toolchain.
Dhara Darji, you still haven't quite understood what I was writing before. It is not merely the toolchain that is important. As I pointed out you will not be able to get your driver certified (although you might get it - or the .cat - cross-signed). I stand by every word from my comment:
Well, you should know your tools. Developing for KM on Windows (as for
many other platforms) is no kid's play. If your UM app crashes, the
app dies. If your driver crashes, the system dies. Please reconsider
using unsupported tools for creating Windows KM drivers. Not to
mention that your idea of drivers seems to be non-existent from the
code snippet above. It is completely different from UM and should not
be taken lightly.
Even now in your last attempt, except for the misspelled main (as mian), you don't seem to know that a driver requires an entry point called DriverEntry and that this takes parameters completely different from a classic main.
As I pointed out before, you are mixing user mode (UM) and kernel mode (KM) concepts. This will simply not work. There are no ifs and buts. A few years ago people even argued that C++ wasn't the right language to write KM code. Mostly because of the semantics of new and the implications with paged and nonpaged pool. These days C++ is accepted for its type-checking. There we have the next thing "pool", what's that? You have to learn at least the basics of the Windows internals, and I'm afraid that at least the edition of "Windows ???? Internals" I read back in the days didn't quite cut it. You'll want to get a proper book about drivers, such as Oney's "Programming the Microsoft Windows Driver Model" or a number of the books - including old titles - from the guys at OSR. Even very old books from NT4 times still contain a lot of valuable information, even though you will likely want something for at least Windows 2000, because of the overhaul of the PnP system and more in Windows 2000.
OSR is also an excellent online resource, although I have to caution you: they are selling courses and those courses are excellent. Natrually they'll not provide every detail in the online available resources. I thought I knew something about driver programming, until I took two of their courses in 2005. They also host three mailing lists
Other than the difference between paged and nonpaged pool you will have to learn concepts such as IRQLs and what you can do at which IRQL. Also, most people think of drivers as "programs", which is another fallacy. One can more compare them with DLLs, even though this comparison also has its shortcomings. It is hard for drivers to maintain global state because many threads from various processes in UM and KM may be hammering it with requests. And all of this still has to be running at a reasonable speed. You may also want to learn tools such as WinDbg, even though with the new VS 11 WDK integration you may not need that anymore (VisualKD is an older option for the same problem).
If you think you can get away with Windows UM programming skills in KM, think again! The best scenario I can imagine is that your driver will be badly written and will work only because you used one of the more recent driver models from the WDF, which simplify many of the things that otherwise require in-depth knowledge. However, will it run reliably? You must consider that a crashing program just crashes the program, but your crashing driver will inevitably crash the OS, the repercussions of which may become clear only later. Especially when considering that PCs are also used in hospitals or nuclear power plants.
Also one last note: as I pointed out before you do not need Visual Studio at all. Be it the Express edition or another. The reason being that the WDK is reportedly a subset of the environment used to build the OS (i.e. Windows) itself. This means you can use Vim or whatever your favorite editor and still build your driver. After all, the build environment of the WDK is nmake-based, with an application named build on top and the sources file in your folder being the central file in your make process. Look at any one sample in the WDK, there are plenty. But most of all RTFM (read the friendly manual). The WDK documentation is excellent, especially if you have the comparison from Windows NT4, 2000 or even XP times.
Related
I've switched over to using the new Modules in Visual Studio (2019 - 16.10.4). Everything compiles and runs just fine if I do a full compilation (i.e. Clean the solution first). Very often when I compile normally, though, I get a crash or initialisation. The error is Application Error (0xC0000005) and appears on startup.
In x86, there's no valid call stack to look at at all. In x64, the debugger points to a valid call stack, at exe_common.inl in a line that says __scrt_current_native_startup_state = __scrt_native_startup_state::initialized;. I realise that's a red herring, and the actual line is _initterm(__xc_a, __xc_z); which I understand is the global memory initialisation.
Is anyone aware of such issues with Modules in VC? The internet doesn't have much information on this case, which leads me to believe it has to do with various configuration options that I might be using. Any pointers? I'm really hoping I won't have to stop using Modules, which I was really looking forward to. There is also a slight chance a recent update to Visual Studio or perhaps something obscure I might have done in the conversion to Modules that is the culprit.
It's just strange that it's guaranteed to work with a full compilation, which would lead me to think that the compiler is to blame.
I am using Visual Studio on Windows together with Intel(R) Visual Fortran Composer XE 2011. I have a big old code with thousands of subroutines. I did some substantial changes adding other hundreds of subroutines and now I am having some access violation errors, the which reason that I have hard time to identify. It is likely due to non-matching number of dummy/formal argument, since it happened to me before and the symptoms were the same and it took me 2 days to figure out where the problem was. Is there an add-on to Visual Studio to catch this kind of error? The programming style is fortran 77 and in no case I am required to provide explicit interfaces as for 90 standard. I know explicit interface would help but adding them for all the code would be days of work.
thanks
A.
I don't have VS on this machine so can't check exactly which Properties page you need to find, but there is an option, probably under Diagnostics, to have the compiler check procedure calls at compile time. On the command-line the compiler option is /warn:interfaces and it causes the compiler to check implicit interfaces. No plug-in is necessary, the Intel Fortran compiler incorporates the necessary functionality.
Windows 7 SP1
MSVS 2010
Qt libraries 4.8.4 for Windows (VS 2010)
Visual Studio Add-in 1.1.11 for Qt4
I, at first, couldn't figure out why this slot didn't fire:
connect (lineEdit, SIGNAL(textChanged(const QString &)),
this, SLOT(enableFindButton(const Qstring &)));
A diff made it clear: Qstring should be QString.
My question: Why did it compile? In fact, it will compile with this:
connect (lineEdit, SIGNAL(textChanged(const nonsense &)),
this, SLOT(enableFindButton(const more_nonsense &)));
Is this expected behavior? Why wouldn't this raise an error?
As far as I know and understand how works Qt, the connection lines works on runtime, not in compilation time. This means that all the operations needed to connect a signal and a slot are performed when the code flow reach that part.
Remember something important about Qt, some of the calls are only macros, not C++ functions. For example, the line "Q_OBJECT" you should add in your class declarations to enable the signals and slots mechanims works, is a macro. Also, the connect call is a macro (...), emit is a macro, etc. Those calls expand into real code once MOC (a pre-compiler, translates Qt macros into real code) analize your code.
Also, the signal/slot mechanism, I repeat, as far as I know, works on runtime, not compilation time. If you read the documentation of the connect macro, it says that the "SIGNAL" and "SLOT" macros you place there, convert the stuff you put there into a string, obviously, with some kind of format, that maybe is too complex to used by hand, so, since it is a string working there, the compilation can't check if the string is correct or not, that is checked on runtime.
I hope my bad english let you understand me, and I hope my knowledge is big enough to not being saying (too much) incorrect tinghs.
We have an application built with Visual C++ 2005, and one customer has reported that he's getting this runtime error:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: [path to our application]
R6002
- floating point support not loaded
According to Microsoft (on this page), the possible reasons for this are:
the machine does not have an FPU (not in this case: the customer has an Intel Core 2 Duo CPU and I haven't seen a machine without FPU since the 486SX)
printf or scanf is used with a floating-point format specification but there are no FP variables in the program (our app contains FP variables but I'm pretty sure we never use printf or scanf with FP formats)
Something to do with FORTRAN (no FORTRAN code in our app)
Also, the error is occurring while they're using our application (specifically, just after they select a file to be processed), not when the application starts up.
I realise this is a long shot, but has anyone seen anything like this anywhere before? Google was pretty unhelpful (there were lots of unsupported claims that it was a symptom of some kind of virus infection but very little apart from that).
Any suggestions gratefully received :-)
Are you linking a static version of the CRT? If so, you need to have floating point variables in the binary that calls printf(). And these variables have to be really used (i.e not optimized out by the comppiler).
Another possibility is a race between the CRT initialization and the code that uses these FP routines, but that would be hard to produce.
R6002 can be caused by printf trying to print a string that contains a percent-sign.
Most likely root cause of such printf failure is a program that manipulates arbitrary files and prints their names. Amazing to me, there really ARE people who put percent-signs in file names! (Yes, I realize that is technically legal.)
printf("%f\n", (float)rand() / RAND_MAX);
I experienced the same runtime error in a program compiled with VS2010 command line cl.
The reported error occurred without the (float) cast and disappeared when I added it.
I'm using VC++ as professional developer for more than 10 years and it has been good to me, now I'm trying to broaden my horizons and learn C++ development on Linux.
On Windows things are simple, VC++ does it all (editing, project management, help, debugging), but on linux things are different, you have assemble your development environment from different tools.
I'm still trying to tie things together, and one thing I still haven't figured out is how to decipher GCC (G++) errors when compiling/linking C++ apps on Linux (although I realize GCC is multi-platform, I'll refer to my linux experience here only).
In VC++, things are very clear: If during compilation VC++'s compiler encounters error in program, it will create new entry in 'output' window with the 'compiler error ID'. Example:
c:\projectA\fileB.cpp(38) : error C2228: left of '.cout' must have class/struct/union
From here, you can click on the line in question in 'output' window, press F1, and 'Microsoft Document Browser' app will start (if it wasn't started already), which will load MSDN help file describing compile error connected to the compiler error ID (in example it's C2228), usually with sample you can check out to figure out what's wrong with your code. If you don't have MDB installed, you can always search on the web for C2228 and get the same help page, optionally finding other people's web pages describing their experience with this error.
The same thing is with linking, you'll get 'linker error ID' (e.g. LNK1123), which you can use to find help either locally or on web.
Try as I might, I can't find this kind of functionality in GCC's G++. All I can see is bunch of less experienced GCC developers asking another bunch of more experienced GCC developers to analyze their code based on descriptive compiler/linker errors with no associated error IDs.
Is there tool(set) that provides VC++ compiler-style help on GCC G++ compile/link errors for linux?
You may try to use qtcreator. At least it can show the errors in a more comprehensive way comparable to the VC++, that is, it can locate the error position and highlight the error line and variables.
If you can an alternative might be to use Clang instead. It gives much better error messages than g++. It compiles most code these days (but it still a work in progress). Highly recommended.
Alternatively (as another poster has mentioned) you could use an IDE such as Eclipse to capture the error messages, though I don't think that adds anything beyond taking you to the line number on double-click.