Following is an extraction of a WinAPI test quiz.
I've researched quite a bit, but haven't found the answers to these:
1. Which statement, regarding dynamic link libraries (DLL), is WRONG:
a) DLLs can be used to exchange data between applications in Windows
b) DLLs can call Windows modules
c) DLLs can use DOS file functions
d) DLLs can control a user dialog in Windows
2. Which statement, regarding the messages in Windows, is WRONG:
a) messages can be exchanged between the objects of an application
b) messages can be generated when events happen
c) messages can be exchanged between applications
d) messages can be exchanged with the help of temporary queue storage
3. Which statement, regarding the system message queue, is CORRECT:
a) it serves for communication and exchange of messages between applications
b) it serves for exchange of messages between common resources
c) it serves for temporary storage of messages from the peripheral devices
d) it serves for communication and exchange of messages between window objects
4. In order to hide a window or a control, the following function is used:
a) SetWindowHide
b) HideWindow
c) UnshowWindow
d) DeleteWindow
I am absolutely positive question 4 is just wrong.
The correct answer is ShowWindow.
And I'm almost certain that 2 does not have a correct answer at all.
I have no additional details or clarifications about the questions.
1c. DLLs are mainly used to share common code but objects stored in them are only available locally within the memory space within which that instance of a DLL is currently mapped.
2a. The answer to this one depends on your interpretation of the question. Strictly speaking you can. To send messages all you need is for the receiving end to have a window with a message loop to send to. For example WM_COPYDATA is 'sort of' used to exchange data between objects. If you view the receiving window as an 'object' and the sender (which does not need to be a window) to also be an 'object' then this does not hold.
3d. Again as above it depends on your interpretation of 'object'. A message can be sent from an application that does not have a window.
4.. None. You would either use SetWindowPos() or more commonly
ShowWindow() with SW_HIDE
Related
For Javascript, there exists this excellent intro that explains the runtime state: http://latentflip.com/loupe/
For Smalltalk, I have never found a similar overview of how the runtime and image snapshots are structured.
It is said that a Smalltalk image consists of objects that can send each other messages. This creates many questions:
Is only one object ever active at a time?
Is there a "root scheduler" that starts up designated "process" objects?
Does each suspended image have a list of active objects?
What happens if two active objects send a message to a third one?
Can only one message be handled at a time? What is the level of "atomicity"?
How do two active objects communicate?
Does every object have an "inbox" of messages received, but not yet processed?
Does every object have an event loop?
Is only one object ever active at a time?
Yes, while the systems can schedule different "processes", which are instances of the class Process running at different priorities, these take control one at the time. Since the scheduling is non-preemptive, processes must explicitly yield or wait on a semaphore (instance of the class Semaphore).
Is there a "root scheduler" that starts up designated "process" objects?
Yes, the global Processor (an instance of ProcessorScheduler) keeps and manages the prioritized list of processes that are ready to run (the others being the ones that are waiting on some semaphore).
Does each suspended image have a list of active objects?
The suspended image is nothing but the image. So, yes, it has everything in it, in particular the Processor, which knows who the activeProcess is.
What happens if two active objects send a message to a third one?
Messages are sent one at a time (even though they may be interrupted by the Virtual Machine)
Can only one message be handled at a time? What is the level of "atomicity"?
The level of atomiciy (non-interruptibility) is essentially the bytecode: message sends, assignments, etc. Any operation perceived as atomic by the programmer.
How do two active objects communicate?
Objects communicate by means of message sends.
In some way, the answer to your question depends on the virtual machine that one is using. And while many Smalltalk implementations or derivatives stick pretty close to the original concept, that may vary a lot.
As from your question, it looks like you are interested in conceptual answers, I recommend you to read the original Smalltalk "blue book".
Smalltalk-80: The Language and Its Implementation. By Adele Goldberg and David Robson, 1983, Addison-Wesley
The book talks in-depth about the design of the system and implementation of the core classes, but also has a few sections, in the end, providing specifications from the VM, interpreter, object memory, etc…
May I know how could I get notified in MQL4, if any of my placed or opened positions have been modified, due to getting [stop loss] or [take profit] or a pending order got triggered?
The reason is that I need to perform certain actions when my placed or opened positions are changed.
Yes, it is, Sir.
One may opt to run an MQL4 code, that monitors the state of the set of both the placed and opened orders, as required above, and send you either an email or other message of your choice, whenever a monitored event happens to show up in the MetaTrader Terminal ( the Market events get reported into the Terminal from the Broker side as events ).
So feel free to use this approach to solving the expressed need. It is programmatically doable either using a Script or an ExpertAdvisor MQL4-code-execution functions. Can even go into distributed framework, if not willing to rely on MetaTrader platform constraints and implement just event-signalling and process the event externally, outside of the MQL4-code-base ( in C, C++, java, php, python, go, Erlang etc. depending on your preferences and performance / latency needs ).
In mql5 - OnTradeTransaction() event, in mql4 it is not supported so need to keep everything in memory and loop over the open trades every tick/second/N milliseconds and compare current orders and their types with previous tick orders and notify if something has changed.
This is somewhat of a general question regarding Windows programming:
Are Window messages "reliable"?
For example (these are just examples):
Can you be certain that a WM_MOUSEMOVE will happen before a cursor enters your screen?
Can you be certain that you will get a WM_DEVICECHANGE message if a device is inserted?
Can you be certain that you will receive a WM_KILLFOCUS message if your window loses focus?
Or, in other words: Can you be certain that you'll get the appropriate message at the appropriate times, or do you always have to code defensively in case that, somehow, you might miss a message for no apparently documented reason?
Example:
It is guaranteed (AFAIK) that a file system filter driver will not "miss" a file operation or change notification.
By contrast, it is not guaranteed that ReadDirectoryChangesW will not miss a notification. In fact, it can miss quite a few if its buffer overflows.
Note:
I am not talking about a situation against an adversary (e.g. someone hijacking your window procedure or installing a hook/filter); that would pretty much invalidate any guarantee. I'm only asking about obscure situations that could really happen even if no one meant anything bad intentionally, like if some random buffer overflows, if someone uses SendInput, etc., assuming you have control of your own code.
No you cannot be certain that a given message will be delivered in a specific order. Here are a couple of reasons why not
Messages can be sent progamatically and this can be used to simulate "impossible" scenarios like a WM_KEYUP followed by a WM_KEYDOWN.
Another routine could sub-class your window and selectively intercept messages and not send them on to your WNDPROC
It's best to code defensively around any scenarios where ordering is important
MSDN advises that RegisterWindowMessage() function is only used for registering messages to be sent between the processes. If a message is needed for sending within one process it can be safely selected from the range WM_APP through 0xBFFF.
However in our codebase I often see that RegisterWindowMessage() is used for messages only sent within one process. I suppose that this was done because of perceived simplicity of using RegisterWindowMessage() since it doesn't require manually distributing the message identifiers in the WM_APP..0xBFFF range.
Do I understand correctly that if many applications are run on one machine and they all call RegisterWindowMessage() with different strings they could exhaust the range of message identifiers allowed to return by RegisterWindowMessage() and for some of them it will just return a value indicating a failure? What could be a valid reason for using RegisterWindowMessage() messages in cases where WM_APP..0xBFFF range messages would suffice?
IMHO there is no valid reason to use RegisterWindowMessage if you are only sending messages to yourself
There is no (documented) way to un-register a message, so after your app quits, that registered message will stay in the atom table until reboot/logoff (I can't remember exactly where this atom table is stored, the window station or terminal server session instance probably)
The reason you need to use RegisterWindowMessage even when messaging to yourself is that it protects you from the idiot who broadcasts messages in the WM_APP + N range.
Yes, this does happen.
Abusing RegisterWindowMessage can potentially make a windows box unusuable. This is especially true if the window message names are dynamically generated and a bug causes out of control windows message allocation. In this case the global atom table in your windows station/ desktop will fill up and any process using User32.dll (basically, any app) will fail to start, create windows, etc.
There is a bug out there in Delphi / Borland products that registers messages that start with ControlOfsXXXXXX where XXXX is a memory address (or other dynamic modifier). Apps that are started and stopped frequently will register multiple ControlOfsXXXX atoms and eventually exhaust atom space. For more details see:
http://blogs.msdn.com/b/ntdebugging/archive/2012/01/31/identifying-global-atom-table-leaks.aspx
And
https://forums.embarcadero.com/thread.jspa?threadID=47678
A possible advantage is that Spy++ can display more informative text, therefore debugging is a bit easier. Compare
<00058> 00330CA2 S message:0x0419 [User-defined:WM_USER+25] wParam:00000000 lParam:00000000
with
<00129> 004F0DA0 S message:0xC2B0 [Registered:"AFX_WM_ONCHANGE_ACTIVE_TAB"] wParam:00000001 lParam:02B596E8
Of course, in principle there is a chance to run out of message IDs. On the other hand, in the source code of the MFC Feature Pack there are 52 calls to RegisterWindowMessage. So there are still 16300 IDs left for other applications.
This may be the simplest win32 program ever ..
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR cmdLine, int show)
{
MessageBox(0, "Hello world..", "Salutations!", MB_OK);
return 0;
}
.. which makes no calls whatsoever to the usual GetMessage() call. My question is this: if my program doesn't process any window messages, can the OS cope with that? I.e., does it cause memory leaks? Or some other resource that wouldn't be apparent unless I ran it 16K times?
In a broader sense, exactly how 'dependent' is Win32 on applications taking care of their messages? I would hope that when the compiler links the executable as a windows program, that the run-time would be capable of cleaning up any kind of message queue, be it emptied or not.
Just a technicality, but you do have a window, and you do have a message loop, just not in your code.
The call to MessageBox() creates a window (of class #32770) and runs a local message loop, not returning to your code till the message loop drops out, presumably when WM_NCDESTROY is sent. I think it's the same message loop that runs in response to DialogBox().
But you could substitute your call to MessageBox() with anything else that really doesn't create a message loop, and you'll still be fine. Windows doesn't care if you have a message loop, although some functionality (primarily UI related) is difficult or impossible to use without it. In fact, you don't have to link to user32 at all, and some apps that have no user interface don't.
Now if you create a window and don't process messages for it in some way, Windows XP and up will replace your window with a "ghost" window that has a white client area and Task Manager will tell the user that the application is not responding.
Although it seems so at first, the message loop is not magic or a strictly required part of Windows boilerplate. It is highly ingrained as a standard in most Windows applications, though, because it's the best way to handle the dispatching of window messages. The "event-driven" nature of most Windows applications makes us forget sometimes that Windows applications were originally designed to be single-threaded, and in this model, it is code running within that single thread, not some unseen force within the operating system, that must make every function call within our code. The addition of multithreading changed that somewhat, but the basic model still remains the same.
EDIT
A note about message queues:
As is mentioned elsewhere, a message queue is only created (and on a per-thread basis) when a window is created by that thread. Your example program, upon creating a message box, does create a message queue. But this queue need not be empty when your application exits. This queue is just a memory structure. It's a block of memory that can hold a certain number of message objects (specifying destination hWnd, message id, wParam, lParam, system time when message was posted, mouse position when message was posted, and some data that allows the derivation of keyboard and mouse button state when the message was posted), along with pointers to the head and tail of the queue (I assume it's a circular queue). When the application exits, this memory, like all memory belonging to the process, is summarily freed.
There are, of course, other things that must be cleaned up outside your process. The OS must keep a table of all existing windows, for example, along with the thread and process that created them. Of course, these are all cleaned up automatically as well.
Since you don't have a window, you don't need a message loop. In Win32 the messages are sent to windows, not to applications.
You do have a message loop - MessageBox is a modal dialog and therefore contains a message loop within.
You don't have to create windows. But still, there are some kind of messages, like
WM_TIMER
WM_TIMECHANGE
WM_CLIPBOARDUPDATE
WM_COPYDATA
WM_POWER
that you may need. So, a ghost window hanging around wouldn't be bad.
If you don't have a window, then that is fine, but if you do then you need to make sure that you pump messages for it. Otherwise the system can hang on broadcast messages waiting for you to respond. This is important for things like COM which create hidden windows for message processing. If your main thread does not pump messages (e.g., by calling WaitForSingleObject) then calls to your COM objects will not be processed, and any programs which send broadcasts will appear to hang.
I have read somewhere (and can't find the reference) is that Windows will create a message queue on demand. If you never call a function that looks for a message queue, one will never be created. And this occurs on a per-thread basis.