|
|
Hi Experts,
Is there any way I can get all logical drives information with follwing attribtes:
1. Active Partition
2. Start Sector number
3. End Sector Number
|
|
|
|
|
Start here[^] for information on the logical volumes in your system.
.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Additionally, try looking around here[^], probably especially around here[^].
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
But I am intrested to get Stating sector of logical drives. How to get that?
|
|
|
|
|
I never used these so i don't know much either, i just thought it might give you some pointers in the right direction. Anyways, could this[^] be what you are looking for?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Class is there to get sector number but its very confusing to get that.
Can you help to get the start sector of logical drive?
|
|
|
|
|
As said, i never used these so this is "new land" to me too, but the example on the site seems to be usefull, try to check that out, particularry, try to change this line:
hres = pclsObj2->Get( _bstr_t(L"DeviceID"), 0, &vtProp2, 0, 0 );
into something like this:
hres = pclsObj2->Get( _bstr_t(L"StartingAddress"), 0, &vtProp2, 0, 0 );
and this:
printf("%ls : %ls\n", vtProp.bstrVal, vtProp2.bstrVal);
to this:
printf("%ls : %i64\n", vtProp.bstrVal, vtProp2.ullVal);
or somesuch. Good luck.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Thanks for your help but could not get the address...I will try google to find something like you suggested.
Again Thanks.
|
|
|
|
|
|
I'm ready to start my SQL Server part of my program, but can't decide which version to use.
There is the native SQL Server sqlncli.h which I think uses SQLOLEDB. Sounds like the way to go, but some caveats exist. If the customer does not have the client installed, I have to download the client and install it for them.
I was looking for something more portable.
There is a sqloledb.h that comes up when I add the include, seems builtin, comes from microsoft sdk's in program files.
I don't want to start writing code, and have to start again.
What do you think?
|
|
|
|
|
This isn't really a coding question (has nothing to do with C/C++/MFC), it's more of a design or tools question, so another forum may be more appropriate.
With that said, I would compare databases available and pick one that has all the features your customer needs, don't worry as much about installation, worry about meeting the requirements (installation can be dealt with documentation). For example, some databases are going to be more appropriate for certain applications (i.e. maximum database size, type of data stored, types of queries, platforms supported, interfaces, security), so I would start by compiling a list of requirements, then do a comparison of databases available and pick whatever suits the overall application best.
|
|
|
|
|
I apologize for not phrasing the question right.
I already have an established database using Microsoft SQL Server 2008 Express Edition RTM 10.500.1601. that was written for a asp.net application.
Now I want to connect to the same database server using c++.
|
|
|
|
|
Oh, I see.. sorry... I'd choose something that doesn't require installation of another component. Supporting interactions with yet another "middle-ware" when you don't have to can become a pain.
|
|
|
|
|
[Here] is an Example of "Connecting To SQL Server Using C++ ODBC".
|
|
|
|
|
Cool Thanks,
It's hard too find stuff on that, I've been looking for awhile. I'll going to try SQLOLEDB first and see how that works. I just needed a reference to get started.
|
|
|
|
|
[SQL OleDbConnection.ConnectionString Property]
void CreateOleDbConnection()
{
String* myConnString = S"Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=Northwind;Integrated Security=SSPI;";
OleDbConnection* myConnection = new OleDbConnection(myConnString);
myConnection->Open();
MessageBox::Show(String::Format( S"ServerVersion: {0}\nDataSource: {1}", myConnection->ServerVersion, myConnection->DataSource ));
myConnection->Close();
}
|
|
|
|
|
Thanks for the info. I ended up using SQLNCLI10, the native connector that comes with SQL Server.
What a pain in the ***, well at least till I figure it out. So I can initialize and connect, get a rowset back, just trying figure out how to process the rowset data.
|
|
|
|
|
Hi,
i have a console project. then an console exe.
i want in another project(dlg project), to execute this console exe. i execute it with calling ShellExecute() function.
now, i want to send some messages to this exe.(to send message from dlg to console) how do i do it? i don't have any hWnd of console exe in dlg project!
please help me.
Zo.Naderi-Iran
|
|
|
|
|
Console projects do not have the capability to interact in this way, as they do not have message queues.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
You are trying to do the impossible here, as the other poster stated. But you can pass data between proceses outside of the windows messaging system. Check out interproces communication in the MSDN. Windows hooks are one method I have used a lot.
==============================
Nothing to say.
|
|
|
|
|
A console application does not have a message pump and so cannot accept a windows message. However, you can still communicate with a console application with the help of several IPC mechanisms available (for example - sockets[^], pipes[^], etc.,)
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
As already (correctly) stated you can't use Windows messages to communicate with the console child process. Have a look at an alternative (to the proposed ones) way: "How to spawn console processes with redirected standard handles"[^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Windows offers a number of ways for two processes to communicate. See Here[^] Once you decide on a method, you can search for a reference implementation of that method on Code Project to on the net.
|
|
|
|
|
Hi,
For some reason I have been seeing this question alot... and the adequate responses. Although it is correct that console applications initially do not have a message queue... the first time a win32k.sys/GDI syscall greater or equal to 0x1000 is invoked... the windows kernel increases the thread stack-size and invokes KiConvertToGuiThread which will convert the console thread into a GUI thread with a message queue.
How do you 'invoke a system call above 0x1000' ?
WIN32K.SYS System Call Table[^]
As you can see in that table... the first GDI system call NtGdiAbortDoc is at index 0x1000. Because we know that the GetMessage function[^] results in a call to NtUserGetMessage and the DispatchMessage function[^] results in a call to NtUserDispatchMessage. We can infer that by simply creating a message loop... we will have in-fact promoted the thread into a GUI thread.
In other words... by simply attempting to pump the message queue... the thread is given one.
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
So what do you have now? Now you have a console process with a thread containing a message queue that has no window HANDLE so cannot recieve window messages. Is this the end of the road?
No, window messages are not the only type of message. You can still use the PostThreadMessage function[^] to post thread messages to the console.
Step 1: Create two console applications... Sender and Reciever.
Step 2: In the reciever begin an infinite message pump (console thread will be promoted to gui thread by the subsystem)
Step 3: In the sender call CreateProcess with the CREATE_NEW_CONSOLE flag that creates the reciever process. (otherwise messages will appear in senders console!)
Step 4: Using the PROCESS_INFORMATION.dwThreadId begin posting messages with PostThreadMessage to reciever from sender.
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
