11,434,678 members (66,653 online)
Forgot your password?
Sign in using
Chapters and Sections
Article Help Forum
Submit an article or tip
Post your Blog
Ask a Question
View Unanswered Questions
View All Questions...
All Message Boards...
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work & Training Issues
Design and Architecture
C / C++ / MFC
ATL / WTL / STL
Ruby On Rails
Hardware & Devices
Hosting and Servers
Silverlight / WPF
Site Bugs / Suggestions
The Insider Newsletter
The Daily Build Newsletter
Most Valuable Professionals
The Insider News
The Weird & The Wonderful
General Indian Topics
General Chinese Topics
What is 'CodeProject'?
Ask a Question
Bugs and Suggestions
Article Help Forum
Advertise with us
Comments by Mike Nordell (Top 21 by date)
Seriously, you expect anyone to be able to give you ANY advice based on that description???
OP: Learn how to learn.
Admin: Close (and remove).
In 32-bit Windows (Vista and earlier I believe) the signing is optional, while for 64-bit drivers since at least Win7 (but possibly Vista too) it's mandatory.
I could be wrong, but I do believe this is correct, meaning any 64-bit drivers for Win7 and later are REQUIRED to be signed (unless you tell the system at startup to allow unsigned drivers).
There are a quite a few Free Software drivers having been hit by this change, but solved it. See f.ex. imdisk.
I suspect "myClassB" at some point in time was a pointer, making the assert make sense. Actually, anything else makes no sense to me.
Just remove that (useless) "assert" and get on to finding the actual bugs. :-)
Are you asking how to add VC10 msvcrt*.dll & co to WinSxS, or just dropping them into your application directory?
SYSTEM should have just about any privileges there are. What it hasn't got is a HANDLE to your HDESKTOP. Perhaps shutting down using that function requires a user (an actual user)?
I hope that hint will help.
How do you see this, in any way or form, relating to C++?
It's your exe. Please, at least debug it yourself and not expect us to do psychic debugging for you! Run the produced exe under a debugger! (I have stopped myself from calling you "Idiot!", even that this question displays all the hallmarks of it).
Also, I think many would prefer if you stopped posting deceptive questions that have NOTHING to do with your problem at hand.
OP: I want a fortune, good health and free electricity. You think I'm ever gonna get any of it?
The OP was concise, and completely off-topic. OP told us what it wanted to do. Correct. OP then didn't write a single word after that, seemingly expecting us to do the work - even that all of this is (many, many times) documented on the internet if OP had bothered to search.
"Design This, and Write The Code for me" (no please).
I suggest: Close question (not really a question, more like begging for both design and implementation).
I think you're going about this the completely wrong way. You want to create a syntax; use bison+flex. Yeah, you need to learn (E)BNF - but it will be something you WILL benefit from knowing (perhaps not the specifics, but the concept).
Trying to hard-code (the way you started) a parser is bound to fail. Greater minds have mathematically proved it I think. :)
Wasn't the horror of "TurboC" only 16-bit? (please, say it was)
Anyway, for stdin/out to/from a spawned console process, you can start by looking up the pipe() function. For a more interactive approach, you need to created the pipes yourself and... you'll get the hang of it. Eventually. :-)
It seems you are coming from a *nix background. You are very close, I think,.
read() is not the universal "read" function in Windows, and an "fd" is not the universal file descriptor.
I urge you to read the documentation at https://msdn.microsoft.com/en-us/library/windows/desktop/ms740642%28v=vs.85%29.aspx
(wicked URL, but it should take you to "What's New for Windows Sockets", and the vast majority of those functions have been there since NT4 (and earlier).
I'm baffled. You are a student, and you are not provided adequate material? This makes no sense to me. Could you elaborate?
I just wanted to apologize for pushing my idea as a "Solution". That was only due to me not really understanding the interface here on CodeProject. That "Solution" should be like this - a comment. If an admin reads this, and can correct it, please do.
GINA is gone? Aww, sh*t. There goes that idea. :-)
"but if I start the hook from the service it fails miserably"
Indeed, AFAIK services no longer have the "interact with desktop" privilege (not that I ever found it documented, but it's claimed to be there). That's most likely the problem.
On Windows 7, you could possibly use the (new to 7 I think, though it might also have been in Vista) - "Manage" your computer. Select Task Scheduler->... There you can add triggered actions, and in your case I'd say that triggered action is "User Logon" abd action is "Start executable" (I made up the names, but they are logical).
That way you could communicate with your actual service the credentials (and possibly HDESKTOP), and let the service interact with the interactively logged on user, using its credentials.
Please note I have no actual experience with this, I'm just trying to find a potential solution to your problem.
If this works, I expect an Article from you, here on CodeProject about it! :-)
While the brick is to me pretty much unreadable (the advice about pre-tags is good), have you tried running the program under a debugger to see
If you think your code is "good", next suspects would be CLAPACK and fftw3f. Do they perhaps have/use global data, making them inherently thread-unsafe (read: impossible to use in threded scenarios)?
Also, note that _beginthread can return an invalid handle. I suspect this could make WaitForMultipleObjects (a function you *really* should check the return code from!) return prematurely, and you free-ing memory some threads may be chewing on.
While I don't know anything about that environment, could perhaps __attribute__((packed)) work?
From my understanding of that documentation, especially since the
part is in italics, wouldn't "domain" in your literal example refer to a domain
That is, if you want to check if a user belongs to the domain FOO, you'd use the string "S-1-5-21FOO-23".
Hope it at least gets you closer to a solution.
Have you signed the driver, or otherwise modified the registry on Win7-64 to allow loading unsigned drivers?
Perhaps if the OP could be kind enough to provide at least a link to "Line" and perhaps explain what it is? I have never heard of it (and I think the author should be flogged for such a name :-) ).
Anyway, for any serious communications software, chances are the core library is written in C or C++. Interface to it would most likely be C. GUI? Use whatever you fancy.
Obviously. What use would a database be if you couldn't get any data from it?
I think you left out a massive amount of information in your question, but if you truly only wanted to know if it's possible - the answer is; Yes!
I wonder... could implementing your own GINA help? I.e. not even allowing any user but "your application" to log in (interactively)? That would void the need to "lock out" mouse and keyboard input. On the other hand, we have these clickable "Change keyboard language" and "Accessibility" icons even on the login screen in Win7. Could those interfere with your app, or could they perhaps even be useful?
As for the service working in XP but not 7, could it be due to stricter security in Win7 (probably also Vista)? Maybe grab a copy of a
Win7 (should be readily available from MS) and attach a serial or 1394 debugger?
Web04 | 2.8.150428.2 | Last Updated 1 Jan 1900
All Rights Reserved.
Terms of Service