|
The builded exe is in your Release and / or Debug folder. Look for it. I didn't say the exe will be called TimeStamp.exe at you local PC! It was just an example. The name of the exe depends on your Project Settings (the project name by default).
But then if you want to use only the logic shown in the code that you've linked in a program of yours, of course you don't need to build this exe at all but rather use the code that fullfills the desired task. And then again you dont have to provide the filename as command line parameter. This is totally up to you.
For the beginning .. it would for your case probably enough if you change the following line.
hFile = CreateFile(argv[1], GENERIC_READ, FILE_SHARE_READ, NULL,OPEN_EXISTING, 0, NULL);
The argv[1] here contains the file name. You could also hard code this filename like
hFile = CreateFile("C:\tmp.txt", GENERIC_READ, FILE_SHARE_READ, NULL,OPEN_EXISTING, 0, NULL);
You'd also have to remove this if you dont want the code to be dependent of the number of command line parameters..
if( argc != 2 )
{
printf("This sample takes a file name as a parameter\n");
return 0;
}
Or get the filename somewhere else. i dont know what you want to do but you'll have to think of stuff like that for yourself.
I strongly advise you to go through some basic C/C++ tutorials, since you seem to lack some basic understandings of the language here.
|
|
|
|
|
Having compiled and built this program you must have a program (xxx.exe?) in either your Debug or Release folder; check again. This is a simple console program that can be run in a command prompt window (are you really saying you do not understand this basic facility?) thus:
ProgramName C:\filename.txt
In order to add this functionality to your own project you can just copy and paste the relevant parts of the sample into your own project.
The best things in life are not things.
|
|
|
|
|
Maybe you should start here first.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
I have been working on SetupDi API functions with VC++ 2010 during these couple days. It works well with 32-bit and 64-bit debug-build, but not the 64-bit release-build. I added some AfxMessageBox'es to narrow down where the problem was. It failed in the API SetupDiEnumDeviceInfo.
But when I formatted a CString in the error handling block after the SetupDiEnumDeviceInfo call, the problem was gone. It looks like some memory alignment issue (well, I guess). Anyone knows the correct way to resolve this kind of issue?
(1) The below code fails.
bool SetupDi::EnumDevInfo(DWORD dwIndex, SP_DEVINFO_DATA* pDeviceInfoData)
{
if(!m_hDevInfo) {
TRACE(_T("SetupDi::EnumDevInfo, m_hDevInfo is NULL. \n"));
return false;
}
if(!pDeviceInfoData) {
TRACE(_T("SetupDi::EnumDevInfo, pDeviceInfoData is NULL. \n"));
return false;
}
memset(pDeviceInfoData, 0, sizeof(SP_DEVINFO_DATA));
pDeviceInfoData->cbSize = sizeof(SP_DEVINFO_DATA);
BOOL bRet = SetupDiEnumDeviceInfo(m_hDevInfo, dwIndex, pDeviceInfoData);
if(!bRet) {
TRACE(_T("SetupDi::EnumDevInfo, SetupDiEnumDeviceInfo(index: %d) failed (0x%08X). \n"),
dwIndex, GetLastError());
}
return (TRUE == bRet);
}
(2) The below code works well.
bool SetupDi::EnumDevInfo(DWORD dwIndex, SP_DEVINFO_DATA* pDeviceInfoData)
{
if(!m_hDevInfo) {
TRACE(_T("SetupDi::EnumDevInfo, m_hDevInfo is NULL. \n"));
return false;
}
if(!pDeviceInfoData) {
TRACE(_T("SetupDi::EnumDevInfo, pDeviceInfoData is NULL. \n"));
return false;
}
memset(pDeviceInfoData, 0, sizeof(SP_DEVINFO_DATA));
pDeviceInfoData->cbSize = sizeof(SP_DEVINFO_DATA);
BOOL bRet = SetupDiEnumDeviceInfo(m_hDevInfo, dwIndex, pDeviceInfoData);
if(!bRet) {
TRACE(_T("SetupDi::EnumDevInfo, SetupDiEnumDeviceInfo(index: %d) failed (0x%08X). \n"),
dwIndex, GetLastError());
CString s;
s.Format(_T("SetupDi::EnumDevInfo, SetupDiEnumDeviceInfo(index: %d) failed (0x%08X). \n"),
dwIndex, GetLastError());
}
return (TRUE == bRet);
}
Maxwell Chen
|
|
|
|
|
Why the size of the passed memory is not passed by the EnumDevInfo caller (i.e. how could you be sure you have sizeof(SP_DEVINFO_DATA) bytes available?)?
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]
|
|
|
|
|
Because I am using it this way... 
SetupDi DevInfo;
if(!DevInfo.GetClassDevs(SetupDi::eDC_System, _T("PCI"), true, true, true, false, false)) {
TRACE(_T("CFindDeviceDlg::FindDevice, GetClassDevs failed. \n"));
return false;
}
DWORD dwIndex = 0;
SP_DEVINFO_DATA spDevInfoData;
while(1) {
if(!DevInfo.EnumDevInfo(dwIndex, &spDevInfoData)) {
TRACE(_T("CFindDeviceDlg::FindDevice, EnumDevInfo failed. \n"));
break;
}
Maxwell Chen
|
|
|
|
|
It is the same project, isn't it?
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]
|
|
|
|
|
Yes.
Maxwell Chen
|
|
|
|
|
And what is the error code in the 'buggy' version?
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]
|
|
|
|
|
CPallini wrote: And what is the error code in the 'buggy' version?
I could not get the error code. Only the 64-bit release-build got error code from this API call, not the debug-build. So I was not able to view the debug messages with DebugView. And when I added the message string for message box, the error would not come out.
Maxwell Chen
|
|
|
|
|
You can, of course: you don't need to locally allocate a CString to show a DWORD value (you may set a global variable value, for instance).
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]
|
|
|
|
|
Now it is very interesting. GetLastError() = 0 when SetupDiEnumDeviceInfo fails. 
Maxwell Chen
|
|
|
|
|
Yes, that's really interesting.
Anyway, are you sure you didn't make any other API call before calling GetLastError?
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]
|
|
|
|
|
CPallini wrote: Anyway, are you sure you didn't make any other API call before calling GetLastError?
No.
Here is the latest code for testing.
bool SetupDi::EnumDevInfo(DWORD dwIndex, SP_DEVINFO_DATA* pDeviceInfoData)
{
if(!m_hDevInfo) {
TRACE(_T("SetupDi::EnumDevInfo, m_hDevInfo is NULL. \n"));
return false;
}
if(!pDeviceInfoData) {
TRACE(_T("SetupDi::EnumDevInfo, pDeviceInfoData is NULL. \n"));
return false;
}
m_dwErrCode = 0;
memset(pDeviceInfoData, 0, sizeof(SP_DEVINFO_DATA));
pDeviceInfoData->cbSize = sizeof(SP_DEVINFO_DATA);
BOOL bRet = SetupDiEnumDeviceInfo(m_hDevInfo, dwIndex, pDeviceInfoData);
if(!bRet) {
TRACE(_T("SetupDi::EnumDevInfo, SetupDiEnumDeviceInfo(index: %d) failed (0x%08X). \n"),
dwIndex, m_dwErrCode = GetLastError());
AfxMessageBox("SetupDiEnumDeviceInfo");
}
return (TRUE == bRet);
}
bool CPccCfgApp::FindSMBusHost()
{
SetupDi DevInfo;
if(!DevInfo.GetClassDevs(SetupDi::eDC_System, _T("PCI"), true, true, true, false, false)) {
TRACE(_T("CFindDeviceDlg::FindDevice, GetClassDevs failed. \n"));
return false;
}
DWORD dwIndex = 0;
SP_DEVINFO_DATA spDevInfoData;
while(1) {
if(!DevInfo.EnumDevInfo(dwIndex, &spDevInfoData)) {
TRACE(_T("CFindDeviceDlg::FindDevice, EnumDevInfo failed. \n"));
AfxMessageBox(_T("CFindDeviceDlg::FindDevice, EnumDevInfo failed."));
CString s;
s.Format(_T("Error = 0x%08X"), DevInfo.m_dwErrCode);
AfxMessageBox(s);
break;
}
}
Maxwell Chen
|
|
|
|
|
I would remove the TRACE macro and try again.
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]
|
|
|
|
|
CPallini wrote: I would remove the TRACE macro and try again.
Now the GetLastError() = 0x103 ( ERROR_NO_MORE_ITEMS ).
Maxwell Chen
|
|
|
|
|
Hi CPallini,
The issue is resolved. The detailed information is here[^].
Maxwell Chen
|
|
|
|
|
The below was his comment.
Modern CPUs have no "memory alignment" issues. In the worst case scenario, the CPU will burn a few extra cycles fetching an adjacent memory word, to execute the instruction or fetch the data. No impact on the application, except for it taking a few ticks of the clock to complete.
Memory alignment issues were often an issue with older CPUs, such as the earlier versions of the Motorola 68K CPU family, where attempting to fetch a word at an odd address caused a trap. Modern CPUs just deal with this by burning more fuel, no harm done. Whatever your problem really is, a "memory alignment" issue would be on the bottom of my list of suspects.
The symptoms being described -- adding a debug statement making an apparent error go away -- often happen as a result of subtle memory corruption; such as wild pointer dereferencing, using memory after it's been freed, etc... Adding some debug statements does not really fix anything, it merely masks the bug. Many times, effects of memory corruption are very sensitive to the layout and the internal arrangement of the code in the final executable. Often, one might think that adding an innocuous debug statement magically fixes their problem, only to see things come crashing down hard, after making some other innocent change to some completely unrelated part of the same application.
There is no universal answer how to fix this, or where the problem is. Roll up your sleeves, it's old-fashioned debug time.
I often found a lot of value in a memory instrumentation and usage checker. For MS-Windows, your apparent platform, Purify is a popular tool for pin-pointing where things go astray. On Linux, I find valgrind to be indispensable, and worth every penny of its no-cost. Very often it began screaming at me about bugs in my code that I didn't even know about, yet!
Of course instrumenting code changes its runtime behavior, and might also have unpredictable results that depend on the timing of its execution -- especially with multithreaded applications. Can't win them all.
I do not have the IBM Rational Purify tool (IBM asked me to register a user account), but I downloaded and installed the 30-day trial version of Intel Parallel Inspector 2011. It reported about 30 memory errors: most of them were in the built-in source code of Visual C++ 2010, but one occurrence was in my project source code. I looked some lines back before this line, initialized a DWORD variable with value 0 (the DWORD dwFilter in the code snippet below), and this issue is resolved.
The below is the related code snippet.
bool SetupDi::GetClassDevs(SetupDi::DeviceClass DevClass, PCTSTR sEnumerator,
bool bAllClasses, bool bPresent, bool bProfile,
bool bDefault, bool bInterface)
{
const GUID* pGuid = NULL;
switch(DevClass)
{
case eDC_System:
pGuid = &GUID_DEVCLASS_SYSTEM;
break;
default:
break;
}
DWORD dwFilter = 0;
if(bAllClasses) {
dwFilter |= DIGCF_ALLCLASSES;
}
if(bPresent) {
dwFilter |= DIGCF_PRESENT;
}
if(bProfile) {
dwFilter |= DIGCF_PROFILE;
}
if(bInterface) {
dwFilter |= DIGCF_DEVICEINTERFACE;
}
if(bDefault && bInterface) {
dwFilter |= DIGCF_DEFAULT;
}
m_hDevInfo = SetupDiGetClassDevs(pGuid, sEnumerator, NULL, dwFilter);
if(!m_hDevInfo) {
TRACE(_T("SetupDi::GetClassDevs, SetupDiGetClassDevs failed (0x%08X). \n"), GetLastError());
}
return (NULL != m_hDevInfo);
}
Maxwell Chen
|
|
|
|
|
OK, so it was a 'surviving the realease build' issue. I'm happy you finally won.
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]
|
|
|
|
|
I am currently reviewing many programs I wrote for Windows 2003/2000 where I call the NetServerEnum Function to enumerate all the servers in a domain. Calling the NetServerEnum Function is dependant on the Computer Browser Service (NETBIOS) running on a Domain Controler in the specified domain. In Windows 2003, this service was on by default.
In a Windows 2008 built domain, Microsoft has decided to disable the Computer Browser Service (NETBIOS) on all windows 2008 machines. This means that if your domain controller is windows 2008, the NetServerEnum Function will not work at all. Enabling the computer Browser Service on the Windows 2008 Domain Controller and setting it to Automatic will solve the issue.
In a quest to update my code to avoid having to start services on domain controllers, does anyone have, or know of another function that can enumerate servers on a windows 2008 based domain that is not based on Netbios calls. I am prgramming in VC++.
thanks in advance
|
|
|
|
|
search the AD for computers?
All DC's have a 'RID Set' child
|
|
|
|
|
Hello i was just wondering if this can be done?, i want to be able to see the windows that overlapped by my window.
Thanks
|
|
|
|
|
I'm sure it can be done, don't know if there's any libraries that can already do this for you (may be), but if you want to do it yourself you'll have to override the OnPaint() method.
|
|
|
|
|
thanks
but how to do that myself i know that using NULL brush on the WM_PAINT draws the window transparent but just it does that draws a no fill rect, so i can see the back of the window but just the moment it gets drawed, so i am thinking of using a timer but that is not efficient can someone they me how i can do it myself without libraries?
|
|
|
|
|
OnPaint() is the method that the MFC infrastructure calls to draw the screen, that would be the appropriate override for this, if you do it there, it should do it the same every time, if you need to get the screen redrawn at any time, just invalidate it and MFC will once again go to OnPaint() to redraw.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
