|
Hi Stuart,
Thanks for the feedback. It has given me some good leads. I forgot to mention in my post that my process is high priority and its serial I/O thread is real-time priority. Do you know of anything else that I could do to encourage the serial device driver or Windows kernel to return the packets to my process more quickly?
|
|
|
|
|
Remove as many other Windows processes as you possibly can - services you don't need etc.
Tune the thread quantum to as small a value as you can.
The trouble is that the Windows scheduler gives processes a full time slice once they've started, even if your process suddenly gets data. That means that there is always the chance that some other process might be running when your data arrives. You have real time timing constraints, which means you need to design a real time solution - and Windows isn't real time capable.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Setting "thread-priority" to real time would help? 
|
|
|
|
|
Not really - the thread setting is actually 'time critical'.
Windows is not and cannot be a hard real-time OS with the scheduling policies it uses - the thread quanta are too large and are reltively uninterruptible. But as it's not marketed as a real-time OS, that's fine - until people's apps stray into the real-time area, in which case they're in for a whole heap of pain. I know, I've been there, trying to understand why (every so often) I would see 100ms delays for 'no reason'.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks for all the invaluable feedback, everyone. Many of my suspicions have been verified and I’ve learned some things about Windows scheduling that has given me a bit more gray hair.  Fortunately, setting the thread quanta to the minimum (about 33ms) provides just barely enough response time to make the protocol implementation work under typical conditions. The implementation doesn’t meet the specification, but it does work so it’s sufficient for now.
Thanks again for all the help!
|
|
|
|
|
"G d Answer"
|
|
|
|
|
I suggest you look for a long term solution, Windows is not meant to be this close to real time. Not jsut because of the serial port issue but if your system is this time senistive you are likely to hit further problems and trying to balance the scheduling will continue to be a headache.
|
|
|
|
|
I'm a little puzzled by the behavior you are seeing from your serial device. We run XPe and a dozen serial devices in real time, but they are purely interrupt driven and I think that's the difference. The requirement for the 5ms timeout is problematic, though it could be done with driver level code.
(If hard real time is needed and you want free, don't bother with Linux; check out eCos instead. If cost isn't an issue, there's plenty of choices like Windows CE or Integrity from Green Hill Software. [And VxWorks, but I detest it and found that dealing with Wind River Systems was a nightmare.])
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
The OS is Windows XP, writing in C using win32 API. I cannot find a (just spent an hour googling sigh!) way to have mixed colors in a text string. SetColorText() makes the text all the same color, and so does SetBkColor(). For example I would like to print the string "This is a test." and have the word "test" in red and the other words in black. If anyone could show me code to do this I'd really appreciate it.
Zach
|
|
|
|
|
You'll have to draw 'test' separately from the rest of the text, so you can change the DC's attributes between calls to the text output routine.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
If you don't mind the "clutter" you could try using a rich edit control and the EM_DISPLAYBAND message to display formatted text, using the rich edit control you could color your text the way you want or even have multiple font sizes and styles in on line and then use the forementioned message to render it onto a DC... i know it sounds ugly, but hey, sometimes ugly solutions are the only working solutions. (Not that i am saying this is the only way to do what you want)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Hello gentlemen,
Is there any option to disable/prevent window minimizing when I press window key(between Ctrl and Alt) + D?
I have one dialog without tile with transparent backgroud, I don't use MFC.
I am capturing these windows messages
case WM_WINDOWPOSCHANGING:
return true;
break;
case WM_WINDOWPOSCHANGED:
return true;
break;
case WM_SIZE:
if(wParam == SIZE_MINIMIZED)
{
return true;
}
break;
Thank you.
|
|
|
|
|
If you want your dialog to stay on top all the time, check out SetWindowPos()[^], and pass &this->wndTopMost to the function.
|
|
|
|
|
Thanks for reply,
my dialog must be at the bottom of the Z order.
I have dialog with text and the bg of the dialog is transparent.So it looks like the text is written directly on the desktop(but it isn't).
The problem is when I hit win. key+D so the dialog is minimized.
I know, it can be done using of windows hooks. I want to avoid of that(if it's possible).
|
|
|
|
|
Win+D does not mean minimize. It means show desktop.
Win+M is minimize.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
daavena wrote: I am capturing these windows messages
Have you verified with Spy++ that you are handling the correct message(s)?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
I use spy++, but when I hit win+D there is no message for my dialog(nothing about minimizing).
_Superman_ wrote
Win+D does not mean minimize. It means show desktop.
maybe that is the reason why I can not capture the proper message.
|
|
|
|
|
Hello all,
Firstly, does anyone have any info regarding the NtSetSystemPowerState function? I can't seem to find any documentation.
Secondly, is there any way to shutdown which is faster than calling ExitWindowsEx, but slightly better than calling NtShutdownSystem from the kernel?
Oh, and finally, can anyone provide me with some information on the entire windows shutdown process, beginning with the call to ExitWindowsEx?
Thanks in advance.
modified on Saturday, March 14, 2009 3:10 PM
|
|
|
|
|
I don't have much idea regarding this function but you may try at this.[^].... 
|
|
|
|
|
Too bad that's for ReactOS 
I wonder if the function params are the same on Windows, since ReactOS has almost the same kernel...
|
|
|
|
|
hxhl95 wrote: Oh, and finally, can anyone provide me with some information on the entire windows shutdown process, beginning with the call to ExitWindowsEx?
Some info is available here.[^]
hxhl95 wrote: I wonder if the function params are the same on Windows, since ReactOS has almost the same kernel...
It's quite possible since ReactOS is designed in such a way that existing windows program can run on it. So, for this the API parameters must be same... This can be verified by calling this function assuming those parameters are correct. If call succeeds then you have got the solution...
|
|
|
|
|
Well, I did try calling the function with those params...
Here's my code (after typedef-ing POWER_ACTION and SYSTEM_POWER_STATE:
typedef DWORD (WINAPI* lpNtSetSystemPowerState)(POWER_ACTION SystemAction,SYSTEM_POWER_STATE MinSystemState, ULONG Flags);
hNTDLL = LoadLibrary("NTDLL.DLL");
lpNtSetSystemPowerState NtSetSystemPowerState = (lpNtSetSystemPowerState)GetProcAddress(hNTDLL, "NtSetSystemPowerState");
NtSetSystemPowerState(PowerActionShutdown,PowerSystemShutdown,NULL);
The only param I don't get is flags, which I put NULL for. Not working.
|
|
|
|
|
hxhl95 wrote: The only param I don't get is flags, which I put NULL for
Flags is of type ULONG. Instead of putting it NULL you may try substituting it with some unsigned value like 0x123....
And since it's hit and trial approach after all, this might not work. Instead you may try looking for actual kernel calls and then finding right parameter values using tools like process explorer etc. Best of luck!!!
|
|
|
|
|
I just found out that NtSetSystemPowerState returns STATUS_NOT_IMPLEMENTED in NT 4.0. Now I'm wondering if it's implemented in 5.1 and above. I know for a fact that it's in Vista though. 
All my calls to NtSetSystemPowerState have been returning 0xC00000EF. STATUS_NOT_IMPLEMENTED is 0xC0000002. If my research is correct, 0xC00000EF is NT_STATUS_INVALID_PARAMETER_1
 Anyone have clues regarding the parameters? I can't find any calls to it inside anything.
modified on Saturday, March 14, 2009 6:53 PM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
