|
BOOL QueryServiceStatus(
SC_HANDLE hService,
LPSERVICE_STATUS lpServiceStatus
);
get its detailed information from MSDN!
|
|
|
|
|
I have a simple server that seems to be leaking handles.
The handle is to a registry key :
HKLM\SYSTEM\ControlSet001\Services\DnsCache\Parameters
In particular 1 handle (key) to this is leaked for each client connection.
The service is simple, it calls socket(AF_INET, SOCK_STREAM, IPPROTO_TCP), bind(), listen() then waits in a loop on accept().
Each accept() creates a thread that handles the connection.
All the thread does is some predefined sync send() and recv() calls then exits.
Everything is being closed correctly, thread, socket, ...
But each closed connection leaves another one of these handles around.
The handles don't appear to be cached, as i have tried leaving the service running with no conncetions for hours to see if they get 'cleaned up' - no joy.
Short of disabling the DNS Client service, does anyone have any ideas ?
[EDIT]
The handle is being created by SQLConnectA().
[/EDIT]
[EDIT_2]
I'm able to get rid of the leak by enabling connection pooling via :
::SQLSetEnvAttr(NULL, SQL_ATTR_CONNECTION_POOLING, (void*)SQL_CP_ONE_PER_DRIVER, 0);
[/EDIT_2]
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Is it possible to read binary data from a music or karaoke CD using the standard I/O functions in Win32? My purpose is to examine the data structure and learn more about them, possibly to try writing my own programs for managing content. Is this likely to require, instead, something at the device driver level?
Will Build Nuclear Missile For Food - No Target Too Small
|
|
|
|
|
Can't really answer your questions, but here's a pretty good FAQ that gives an overview, as well as links to more in-depth information:
http://www.cdrfaq.org/faq02.html#S2-43[^]
How do you move in a world of fog, That's always changing things?
Makes me wish that i could be a dog, When i see the price that you pay.
|
|
|
|
|
Excellent link, Josh - Thanks!
It looks like, if I'm going to pursue this, I'll need to install the DDK and learn to use it. Oh well, nothing easy is worth having...
Will Build Nuclear Missile For Food - No Target Too Small
|
|
|
|
|
What OS do you want compatiblity with? You can use SPTI in NT and use ASPI in 9x
SPTI
Have a look for opening CDRom drives using CreateFile, you can read sectors other than data using DeviceIoControl and IOCTL_CDROM_RAW_READ
ASPI
If you using ASPI then you can use many of the read commands defined in the SCSI 3 specification. READ_CD being your best bet.
Regards,
Ceri
|
|
|
|
|
Sounds promising - thanks!
Will Build Nuclear Missile For Food - No Target Too Small
|
|
|
|
|
I'm writing an app that when a certain event is received it brings itself forward to the top window on the z-order. However I cannot get this to happen on a win xp pro environment.
I tried this example that I found but this does not work
AttachThreadInput(<br />
GetWindowThreadProcessId(<br />
::GetForegroundWindow(),NULL),<br />
GetCurrentThreadId(),TRUE);<br />
<br />
SetForegroundWindow();<br />
SetFocus();
<br />
AttachThreadInput(<br />
GetWindowThreadProcessId(<br />
::GetForegroundWindow(),NULL),<br />
GetCurrentThreadId(),FALSE);
I've also tried this:
<br />
::AttachThreadInput(GetWindowThreadProcessId(hWnd, NULL) ,GetCurrentThreadId(), TRUE);<br />
::DefWindowProc(hWnd, WM_SYSCOMMAND, SC_RESTORE, NULL);<br />
::SetForegroundWindow(hWnd);<br />
::SetFocus(hWnd);<br />
::ShowWindow(hWnd, SW_SHOWNORMAL);<br />
::AttachThreadInput(GetWindowThreadProcessId(hWnd, NULL) ,GetCurrentThreadId(), FALSE);<br />
Still does not being itself forward.
Does anyone have any suggestions?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
You could try setting it as the topmost window
::SetWindowPos(hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE);
Though you will have to revoke this if you want other windows to move over it afterwards.
Ant.
|
|
|
|
|
OR replace HWND_TOPMOST with HWDTOP to move to the top without making it permanent.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
So, you're actually trying to call SetForegroundWindow, but the lock feature is working.
Good. It's supposed to. The user doesn't want to be interrupted by your program. If you really must, it is possible to change the lockout behaviour using SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT), but you can only do this if you're already the foreground window or a call to SetForegroundWindow would succeed.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I do not believe that this is the case. This is why. Currently I'm writing this code in a dll that a COBOL application is calling (so that it can pop itself to the top of the z-order). This same code is in a test .exe and it works great. I type in the title of the window I want to come forward and it comes forward.
This same code works great on Winnt 4.0, w2k, but I cannot get it to work on XP. So what is the difference between 2000 and XP?
Thanks for the help
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
I have been using an application-defined comparison function for sorting CListCtrl in Report format. The item string is obtained by searching the list for a match on the item data (see below). This works fine if there are subitems, however with NO subitems the ASSERT fires. If the list control is redrawn during the sort, the row with lParam1 is missing - replaced by a duplicate of another row.
Any ideas?
Many thanks.
int CALLBACK CSortListCtl::CompareItems( LPARAM lParam1, LPARAM lParam2, LPARAM lParamData )<br />
{<br />
....<br />
<br />
LVFINDINFO findInfo;<br />
findInfo.flags = LVFI_PARAM;<br />
findInfo.lParam = lParam1;<br />
int index1 = pListCtrl->FindItem( &findInfo );<br />
ASSERT( index1 > -1 );<br />
CString text1 = pListCtrl->GetItemText( index1, subItem );<br />
<br />
....<br />
}
|
|
|
|
|
This is the incorrect usage of the comparison function. When you add items to a list control using InsertItem(), you should follow that with a call to SetItemData(). Then in the comparison function, the values passed in as lParam1 and lParam2 are used as pointers to the item data. Here's a brief example:
CString *pName = new CString("Mason");
int nItem = m_listctrl.InsertItem(0, *pName);
pName = new CString("Dixon");
nItem = m_listctrl.InsertItem(1, *pName);
pName = new CString("Woodrow");
nItem = m_listctrl.InsertItem(2, *pName);
...
int CompareFunc( LPARAM lParam1, LPARAM lParam2, LPARAM lParamData )
{
CString *str1 = (CString *) lParam1,
*str2 = (CString *) lParam2;
return str1->CompareNoCase(*str2);
}
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
If you use the sequence
pName = new CString("Dixon");<br />
nItem = m_listctrl.InsertItem(1, *pName);<br />
m_listctrl.SetItemData(1, pName);
repetitively, all the string data in the list is duplicated in the CString objects. You will also need to add extra code to delete all the CStrings before the control is destroyed (or possibly subclass and override OnDestroy()). Hence the attraction of using FindItem() albeit at the cost of lots of searches.
The point that I wanted to make is that FindItem() doesn't appear to work during sorting if you have no subitems - unless I've got my code wrong.
Of course, we would not be having this discussion if instead of supplying lParam's, LVITEM's were passed instead with a predefined mask.
|
|
|
|
|
Background:
My application restricts the capabilities of users without administrator privileges and provides an "administrator override" capability that allows an administrator to supply credentials so that restricted operations may be performed without terminating the app. This capability is designed to work on Windows 2000 and XP. The app requests user credentials with a logon dialog box. It then validates them and impersonates the user with administrator privileges using code modified from the samples supplied with Microsoft KB article Q180548. This mechanism works correctly on Windows 2000 SP3.
Problem:
After installing SP4 or some other recent Hotfix, the administrator override capability no longer works. After the app impersonates a user with administrator privileges, it can no longer open a registry key in HKEY_CURRENT_USER for reading and writing. The call:
RegOpenKeyEx (HKEY_CURRENT_USER, pszKeyName, 0,
KEY_READ|KEY_WRITE, &hRegKey);
fails, returning a value of 1346 (0x542), listed in Winerror.h as ERROR_BAD_IMPERSONATION_LEVEL.
What must I change in the app to fix this problem?
|
|
|
|
|
ICantChangeMyAcct wrote:
After the app impersonates a user with administrator privileges...
Are you sure this part still works? The 0x542 error has two meanings: either a required impersonation level was not provided, or the provided impersonation level is invalid.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I'm not sure what "works" means. The Q180548 code uses secur32.dll functions to generate a "client context" and a "server context", then calls the function ImpersonateSecurityContext() with the *server's* context handle (!?!) This function returns SEC_E_OK, indicating that the impersonation "worked". My app doesn't use the context handle in system calls or do anything that requires administrator privileges.
|
|
|
|
|
Hi.
Do anyone know how I make my programs to only open one time and not multiplie times? Exampel when my program is open and I start it again then the already open program shall show up and not open it again. Just like Windows Media player.
|
|
|
|
|
See here and here.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I have the following code that I am executing:
DWORD last_err;
WNDCLASS wc;
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = (WNDPROC) WindowProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.lpszMenuName = "MainMenu";
wc.lpszClassName = "MainWindowClass";
if (!RegisterClass(&wc))
{
last_err = GetLastError();
}
The RegisterClass call fails and when I run the code in debug and last_err gets set it has a value of 0. I'm expecting it to have a value that designates just what the error was. I got this code fom the following example:
int APIENTRY WinMain(
HINSTANCE hinstance,
HINSTANCE hinstPrev,
LPSTR lpCmdLine,
int nCmdShow)
{
WNDCLASS wc;
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = (WNDPROC) MainWndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hinstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = "MainMenu";
wc.lpszClassName = "MainWindowClass";
if (!RegisterClass(&wc))
return FALSE;
}
This comes from the help index under "Using Window Procedures".
Robert
|
|
|
|
|
Do you get the same results when using RegisterClassEx()?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
|
Looks ok to me. Check that your hInstance param is correct and also your WindowProc and lpszMenuName.
----
lpszMenuName
Pointer to a null-terminated character string that specifies the resource name of the class menu, as the name appears in the resource file. If you use an integer to identify the menu, use the MAKEINTRESOURCE macro. If this member is NULL, windows belonging to this class have no default menu.
----
I don't know why GetLastError() returns 0.
If you are using MFC you may want to look at AfxRegisterWndClass() or AfxRegisterClass().
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
Neville,
My hInstance param comes right from my main window creation, just like the example:
int PASCAL WinMain (HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR szCmdLine, int nShow)
{
hInstance = hInst;
I changed the name of my WindowProc routine to MyWindowProc just so that it wasn't the default anymore. That routine is at the top of the module that contains the code in question:
LRESULT CALLBACK MyWindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam
)
{
int dummy_var;
dummy_var = 1;
return 1;
}
My lpszMenuName is NULL. My intent is to create a window that is invisible later on by calling CreateWindow for the purpose of processing messages only. The reason that I am calling RegisterClass is because I assumed that I needed to do this prior to getting the CreateWindow to work. BTW, that is also returning a 0 when it fails and I check GetLastError. Very strange.
The help message that describes the kind of window that I want to create is here:
From CreateWindow...
hWndParent
[in] Handle to the parent or owner window of the window being created. To create a child window or an owned window, supply a valid window handle. This parameter is optional for pop-up windows.
Windows 2000/XP: To create a message-only window, supply HWND_MESSAGE or a handle to an existing message-only window.
Message-Only Windows
A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages.
To create a message-only window, specify the HWND_MESSAGE constant or a handle to an existing message-only window in the hWndParent parameter of the CreateWindowEx function. You can also change an existing window to a message-only window by specifying HWND_MESSAGE in the hWndNewParent parameter of the SetParent function.
To find message-only windows, specify HWND_MESSAGE in the hwndParent parameter of the FindWindowEx function. In addition, FindWindowEx searches message-only windows as well as top-level windows if both the hwndParent and hwndChildAfter parameters are NULL.
As to the last reference to MFC, I am not using it.
Robert
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
