HI,
Im using Delphi and I want to make an application that can do the following
When started from within Terminal services (remote desktop), if another user logs into another terminal services session they should be able to see the application running in the desktop tray. However if a user sitting at the server logs in then they shouldn't see the application running in the desktop tray. Its fine if everyone can see it running in the process list, just not the desktop tray.
How can I do this?
Make your application launch on startup on every user, then use this function to determine whether to quit or not:
#include <windows.h>
#include <winternl.h>
BOOL IsRunningOnTerminalServerClient( void )
{
PWINSTATIONQUERYINFORMATIONW WinStationQueryInformationW;
WINSTATIONINFORMATIONW wsInfo;
HINSTANCE hInstWinSta;
ULONG ReturnLen;
hInstWinSta = LoadLibraryA( "winsta.dll" );
if( hInstWinSta )
{
WinStationQueryInformationW = (PWINSTATIONQUERYINFORMATIONW)
GetProcAddress( hInstWinSta, "WinStationQueryInformationW" );
if( WinStationQueryInformationW &&
WinStationQueryInformationW( SERVERNAME_CURRENT,
LOGONID_CURRENT,
WinStationInformation,
&wsInfo,
sizeof(wsInfo),
&ReturnLen ) &&
( wsInfo.LogonId != 0 ) )
{
FreeLibrary( hInstWinSta );
return( TRUE );
}
FreeLibrary( hInstWinSta );
}
return FALSE;
}
Pulled from http://msdn.microsoft.com/en-us/library/aa383827(v=VS.85).aspx
Assumption: You are logging into a Windows Server - two people cannot RDP at the same time on the Desktop OSes. My experience with this is that you should not see applications running visually - ie on the desktop or on the taskbar or tray icon area.
If you go into the task manager and look at the processes running - you may see process running. Also, if you are Administrator, then you may "Kill" the process, else there is nothing you can do with it.
Does this help?
Please clarify what you are asking.
Related
Is it possible to communicate with a launch daemon running as root and an application over XPC? When my daemon is running as my user I can communicate with it fine, when run as root it stops receiving my messages. Is this intended security inside Mac OS X?
I need to use low level xpc (for running on Lion as well). I know I can create a priviliged and signed helper tool that is running as root for my app. Will I be able to communicate with it with another process as well over XPC or sockets?
Thanks!
Small extract from my daemon code:
int main()
{
Logger::Start(Poco::Path::expand("/Users/Shared/Me/Service.log"));
Logger::LogInfo("Starting xpc_main...");
void* observer = nullptr;
CFStringRef observedObject = CFSTR("com.me.service.close");
CFNotificationCenterRef center = CFNotificationCenterGetDistributedCenter();
CFNotificationCenterAddObserver(center, observer, notificationCallback, CFSTR("ClientClosing"), observedObject, CFNotificationSuspensionBehaviorDeliverImmediately);
xpc_connection_t listener = xpc_connection_create_mach_service("com.me.service", NULL, XPC_CONNECTION_MACH_SERVICE_LISTENER);
xpc_connection_set_event_handler(listener, ^(xpc_object_t event)
{
// New connections arrive here. You may safely cast to
// xpc_connection_t. You will never receive messages here.
// The semantics of this handler are similar to those of
// of the one given to xpc_main().
Logger::LogInfo("Event Handler on listener is called");
eventHandler((xpc_connection_t)event);
});
Logger::LogInfo("call xpc_connection_resume...");
xpc_connection_resume(listener);
CFRunLoopRun();
Logger::LogInfo("Main Program is Exiting...");
return 0;
}
The problem is that CFNotificationCenterGetDistributedCenter works only on the same user, root user will not send message to other logged in users..
You'll need to switch to CFNotificationCenterGetDarwinNotifyCenter.
Please note however, that you can't pass any data using this center.
I know the Brew application have 3 types: active, suspend & background. Launch one BREW application as active or suspend is very simple. I know in BREW2.0 and later version, there is a new application type can allow we create one application in the background. It will not stay in the application stack and change status by active or resume command. It will always stay in the background no matter what user command system received. In one of my small project, I need to create and launch one background application like this.
Unfortunately, I cannot find a simple example on Qualcomm or Google. Is there any programmer who has encountered the same problem?
Yes, you are right. BREW2.0+ do support background application.
When we initial a background application, just like other normal new application, it can be launched by the brew application interface directly. You also can launch it by ISHELL_StartApplet function.
When you want to put one brew application in the background, you need do it when handle EVT_APP_STOP event and must set dwParam to false. After handling EVT_APP_STOP by this, the application will be put in the background. And if you want to change it to normal application, you need call ishell_StartApplet function to active to itself again.
Example code:
typedef struct _bgApp
{
AEEApplet a;
boolean m_bGoBg;
} bgApp;
switch (eCode)
{
case EVT_APP_START:
if(pMe->m_bGoBg)
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
case EVT_APP_STOP:
if(pMe->m_bGoBg)
*((boolean*) dwParam) = FALSE;
return TRUE;
case EVT_USER:
if(pMe->m_bGoBg)
{
pMe->m_bGoBg = FALSE;
// make applet active
ISHELL_StartApplet(pMe->a.m_pIShell, AEECLSID_BGAPP); }
else
{
pMe->m_bGoBg = TRUE;
// trigger EVT_APP_STOP to send app to background
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
}
return TRUE;
}
There is a limitation of background application. You cannot change the screen or communicate with user directly. Developer should be careful on the memory used by the background application. This is very important.
I have created a Credential Launcher for Windows 7 and was able to run Windows application after the Tile button click event, it was very easy.
I added a few registry settings and *pbAutoLogon = FALSE;.
However now i am now trying to do the same for Windows XP.
Which function I should target or how to achieve the same results ?
I see you tagged your question with "Gina", so I guess you know that Credential Providers do not exist on XP.
Your answer depends on when exactly you want to run that program, especially with regards to the secure attention sequence (SAS, or when a user press CTRL-ALT-Delete)
Before the SAS, use WlxDisplaySASNotice
After the SAS, use WlxLoggedOutSAS
Since you don't want to write a whole GINA yourself, you could use a custom Gina that wraps msgina.dll. Here is one I wrote, you can find the original I started from in the Platform SDK.
Using that approch, you get a chance to execute code just before or just after certain events, like running your program after a successful logon, something like :
int WINAPI WlxLoggedOutSAS(PVOID pWlxContext, DWORD dwSasType, PLUID pAuthenticationId, PSID pLogonSid, PDWORD pdwOptions, PHANDLE phToken, PWLX_MPR_NOTIFY_INFO pMprNotifyInfo, PVOID * pProfile)
{
int result;
result = pfWlxLoggedOutSAS(pWlxContext, dwSasType, pAuthenticationId, pLogonSid, pdwOptions, phToken, pMprNotifyInfo, pProfile);
if (result == WLX_SAS_ACTION_LOGON)
{
//We have a successful logon, let's run our code
run_my_custom_code();
}
return result;
}
There are some caveats, though :
The code cannot block. Winlogon will wait, but your users might not. Spanw a process and let it run.
Your program will be running with SYSTEM privileges, which is a security risk. Sandboxing your process could be hard. If you can't break out of it, don't assume nobody can...
I am setting up a scratch desktop to run another application in a "silent mode" - the other app is noisy and throws all sorts of windows around while it processes.
I have used the info here: CreateDesktop() with vista and UAC on (C, windows)
and CreateDesktop works - I can create the other desktop, I can launch the application into the other desktop (I see it launching in task manager) - but when I try to interact with the app via DDE, the DdeConnect call hangs until it times out.
And here's how I'm calling CreateDesktop:
LPSTR desktopName = "MYDESKTOPNAME";
HDESK hDesk = CreateDesktop(desktopName , NULL, NULL, 0, DESKTOP_SWITCHDESKTOP|
DESKTOP_WRITEOBJECTS|
DESKTOP_READOBJECTS|
DESKTOP_ENUMERATE|
DESKTOP_CREATEWINDOW|
DESKTOP_CREATEMENU, NULL);
Here is CreateProcess to actually launch the app into the new desktop:
STARTUPINFO startupInfo;
GetStartupInfo(&startupInfo);
startupInfo.lpDesktop = desktopName;
PROCESS_INFORMATION procInfo;
memset(&procInfo, 0, sizeof(procInfo));
if (CreateProcess(NULL, exePath, NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &startupInfo, &procInfo)){
WaitForInputIdle(procInfo.hProcess, INFINITE);
CloseHandle(procInfo.hProcess);
CloseHandle(procInfo.hThread);
}
If it matters, the call to DdeInitialize:
DWORD afCmd = APPCLASS_STANDARD | APPCMD_CLIENTONLY | CBF_SKIP_ALLNOTIFICATIONS;
UINT rslt = ::DdeInitialize(&ddeInst, NULL, afCmd, 0);
Here is the DdeConnect call (the hsz* parameters, etc... are all fine - if I launch the app into the regular desktop, the calls all work perfectly).
hConv = ::DdeConnect(ddeInst,
hszService,
hszTopic,
NULL);
This call just hangs for ~60 seconds.
Is this a security issue of some sort? i.e. the windows messages aren't passing between desktops? Or does anyone have any suggestion on how to troubleshoot this further?
The documentation for CreateDesktop contains a cross-reference to the Desktops topic, which says
Window messages can be sent only between processes that are on the same desktop.
The overview topics are important. They provide background information to help you understand the feature.
Raymond explains why the messages don't get through. In order to solve the problem, assuming you continue with the separate desktop, you will simply need to run the process that performs the DDE in the same desktop as the target app. If you need to communicate between your process on the main desktop and the target process then you will need to use some other form of IPC.
I'm writing a service application that sometimes cannot be stopped immediately upon receiving the SERVICE_CONTROL_STOP from the Services MMC. I currently handle it like this: (in pseudo-code):
DWORD
HandlerEx(
DWORD dwControl,
DWORD dwEventType,
PVOID pvEventData,
PVOID pvContext
)
{
switch( dwControl )
{
case SERVICE_CONTROL_STOP:
if ( CanStopServiceNow() )
{
ReportStatus( SERVICE_STOP_PENDING );
DoStopService();
ReportStatus( SERVICE_STOPPED );
return NO_ERROR;
}
else
return ERROR_BUSY;
break;
}
return NO_ERROR;
}
It works well when the service can stop ( and it does stop), but when it cannot stop, I would expect Windows to report the error I'm returning (ERROR_BUSY in this example.) Instead, Windows displays a message saying:
"The service did not return an error.
This could be an internal Windows error or an internal service error."
So my question is, how to make the service report back to SCM that it cannot stop now and make MMC display a message about the actual error code that I'm returning?
Answering my own question (after investigating the problem in more detail): instead of returning an error code from the HandlerEx function, the service should report its status to SCM indicating whether or not it can accept the SERVICE_CONTROL_STOP code. If the service detects that it cannot be stopped immediately, it should clear the SERVICE_ACCEPT_STOP bit in its SERVICE_STATUS structure and call SetServiceStatus(). This should prevent SCM from attempting to stop the service in the first place. When the condition clears and the service decides it's safe to stop, it should set the SERVICE_ACCEPT_STOP bit and call SetServiceStatus() again.
I am aware that this won't answer your specific question. But as I think that the answer is "There is no way". I will make a suggestion anyway. Most applications that need more control on their startup and shutdown, offhand I can think of Sap and Oracle, use the windows service as administrative service, and implement a gui or command line interface to start and stop the actual "worker process".