View Full Version : Some good ideas in my opinion
Ron
October 13th, 2002, 12:55 PM
1. I bet there is some tool on the internet that would do this. Unless more people need this I'm not going to program this.
2. I can change this but that would make a lot of people mad because they would have to relearn the eventstring. I might add an option to the keyboard plugin that switches between the old and the new eventstrings.
3. I'm actually working on getting Girder to run as a service. There are a few major bumps that have to be taken. Girder 3.2 has taken most of these bumps and in the course of the 3.2 releases we will probably see an NT-service option. I would be interested in how I can determine if a user logged on when running a service. Have you got any info/link on this ?
Ron
October 13th, 2002, 12:55 PM
3. Very cool! As soon as the Service implementation is needed I'll need this!
Ron
October 13th, 2002, 12:55 PM
Very good points Mark.
Ron
October 13th, 2002, 12:55 PM
Well,.. imagine Girder getting priority normal +1 ( or whatever it is called in Windows) then winamp might start skipping, so winamp ( or whatever other media program ) needs to be a little higher in priority. Then Girder is getting to few CPU cycles,... can we see a vicious circle here ? The problem is just to little cpu power or crappy programming as Mark put it. ( Not in Girder of course :-D )
Ron
October 13th, 2002, 12:55 PM
On a different note, what linkage do the Winlogon callback function use, the MSDN doesn't say anything about it, stdcall safecall ???
Never mind codeproject is a great source of info:
http://www.codeproject.com/useritems/winlogon_notification_package.asp
Ron
October 13th, 2002, 12:55 PM
Ah thats an easy question, never.
http://www.girder.nl/phpBB2/viewtopic.php?t=1621&postdays=0&postorder=asc&highlight=service&start=30
http://www.girder.nl/phpBB2/viewtopic.php?t=1386&highlight=service
basically a windows service doesn't have enough access rights to be usefull. As you can imagine Girder needs a lot of accessrights do to its magic.
Ron
October 13th, 2002, 12:55 PM
Jim, its still not possible because the service does not get access to the desktop or the user, I've tried. Besides even if this is solveable then we have the MFC/Borland plugins that don't work as a service.
Ron
October 13th, 2002, 12:55 PM
Yes girder can run as a service, but many functions of girder won't work. Also the advantages of running girder as a service are minimal, not big enough to force the plugin developers to thow out the MFC/Borland stuff and go plain API. ( girder kernel is plain win32 api ). If you want to know why read the 2 threads linked above.
I'm going to lock this thread, cause its not going to happen people. I've said it many times now, there are too many limitations in windows service mode to get girder to function properly.
Mark F
October 13th, 2002, 12:55 PM
In my opinion, number 1 (arbitrarily changing the priority of Girder) is not a good idea.
Three things that cause me to say this:
It can impact plugin development.
Girder is not a stand-alone application controlled by one developer. Ron does the main code but other developers do some of the plugins. Some plugins have threads of their own. By changing Girder's priority, these plugin threads may get starved or boosted in ways they don't expect. If nothing else, it increases the development and debugging time required to make a plugin as developers need to test with Girder set to all the different priorities.
It can impact other applications.
Allowing users to change the priority of Girder allows them to make other applications FAIL. Check the FAQ under the IGOR plugin. That tid-bit is in the FAQ because Ron gets bombarded with questions about Girder causing skips in WinAMP, Media Player, etc. You are asking for Girder to include a knob that will cause skipping by itself. The number of questions and "bug" reports would skyrocket.
It does not a solve the problem, it treats a symptom.
Changing an application to a high priority because another piece of sh**, I mean code, is hogging the CPU is the start of a self defeating circle. Sooner or later, the CPU hog will fail and it's priority will need to be adjusted up again. Then everything else will start to fail again and so on. Before you know it, all programs are marked REAL_TIME and dymanic scheduling/load balancing stops. The three approaches that have worked for me to fix this in the past are to either stop using the CPU hog, get the CPU hog to stop hogging the CPU (get it re-written) or get a machine that has more power.
Does really nobody need this?
To answer your question, for myself, I don't need it and I don't want it. I don't want to field the questions of why my plugins fail at REAL_TIME priority when they shouldn't be at REAL_TIME priority. I don't want to do the testing with Girder set to priorities from IDLE to REAL_TIME (or whatever the gamut would be) when it should be running at NORMAL.
Sorry, this is freeware and I have other things that have a higher priority (NPI) in my life. (despite all evidence to the contrary :) )
As Ron stated, there are programs that allow users to alter the priority of running applications from the outside. In my opinion, this is the best approach as now the user takes responsibility for this change and any impact it may have in their system.
Corpse
October 13th, 2002, 12:55 PM
1. The first, and the simpliest. It would be very nice if girder could set and remember self priority. I would like to set it to high because now, when I have some processes wasting my cpu time, girder react too slowly on imcoming events due to normal priority. So volume control looks rather bad :(
2. It seems to me to be not very convenient that keyboard driver makes human-unreadable representation of keyboard events. When I edit my event files, I can`t see what a particular keyboard event really is. Maybe, I say this because I don`t understand enough the potential troubles of such realization... ok, in such case please explain me this...
3. The last, and the most hard. It would be really cool if girder could work as a service, and as a result could have an apportunity to use some hardware plugin for catching logon, logoff, lock, unlock and other user events... I would help to create this plugin :)
Corpse
October 13th, 2002, 12:55 PM
1. Yeah, the tool really may exist, but it hardly can be convenient to use it. Girder automatically controls "Launch on windows startup" option, and the simpliest way to control the priority is to do it also inside the main code. So I think it`s not a good way to use third-party products for such trivial features. Furthermore, many programs, including a lot of freeware, have this option.
I perfectly understand that you are not interested in programming this until people do not really need it. My exclusive desire should not be taken into account. But PEOPLE! Does really nobody need this?
2. Yes, backward compatibility is really needed, it`s not a question at all. If it would not strain you, it would be very nice :) I hope this option will be useful for other people also.
3.
I would be interested in how I can determine if a user logged on when running a service. Have you got any info/link on this ?
Yes, I wrote a test dll, which catches winlogon events, and logs them into a file.
Look here:
Creating a Winlogon Notification Package (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/notify_9r51.asp)
Registering a Winlogon Notification Package (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/registering_a_winlogon_notification_package.asp)
We can catch events in notification package via hadler-functions and resend them to a service application in our own format.
If you`re going to try this yourself, be careful when testing this dll - don`t attach to logon event unless you become sure that other similiar handlers work well. Otherwise you can get into big trouble, like I did first time :) I hardly repaired my system after that. Just imagine blue screen in windows xp when loggin on any user, even in safe mode, and restoring of system profile does not help this also :)
Corpse
October 13th, 2002, 12:55 PM
Mark F
Thanx for the complete and perfect explanation of your opinion. It seems that you finally convinced me :) i.e. i almost have understood your point of view.
...except one but: You talked so much about real time priority... In my opinion, no application should permit to set this. REAL_TIME should never appear in user-configurable options, in any application.
josjojo
October 13th, 2002, 12:55 PM
When can we expect the first release of Girder with an option to run it as a service? I'm very curious about it!
josjojo
October 13th, 2002, 12:55 PM
Okee, I see! :(
josjojo
October 13th, 2002, 12:55 PM
Is it possible to run only Girder as a service? I mean Girder without any plugin. If it is, then the plugin-developers should deal with the problems when their plugin is run as a service.
Maybe the above is a stupid thought, then it is because I'm not fully understand the difficulties of running Girder as a service :-? .
JimHugh
October 13th, 2002, 12:55 PM
FYI - not taking either side in this discussion, but wanted to point out the following:
Under NT, 2000 and XP you can use cmd /c START to start a process at a different priority. Type "help start" from a command prompt to see options.
A Windows service does not have to run as System, the logon can be set to any machine or domain account and the rights granted accordingly. For example, many people do this with SQL Server to gain access to network shares and enable SQLMail for the SQL Service Account
Powered by vBulletin® Version 4.1.8 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.