Re: destroying a window on windows
Michael C <[email protected]> Thu, 18 May 2017 08:41:43 -0700
| Newsgroups | gmane.comp.python.ctypes |
|---|---|
| Message-ID | <CANyKM1jJXD3NBEHX8n4r74nxCrRiLf11Aj6XQYACAW80O2jegQ@mail.gmail.com> |
--===============4788871916410361519== Content-Type: multipart/alternative; boundary="001a114871c6e006ec054fce3d1a" --001a114871c6e006ec054fce3d1a Content-Type: text/plain; charset="UTF-8" Ok, I tried to read https://msdn.microsoft.com/en-us/library/windows/desktop/ms633573(v=vs.85).aspx But it doesn't say which one it belongs to, User32 or Kernel32... I guess 'User-defined function name' is something I have never seen before, I see that I should send this to the application: #define WM_CLOSE 0x0010 But I haven't figured out how. thanks! On Wed, May 17, 2017 at 10:03 PM, eryk sun <[email protected]> wrote: > On Thu, May 18, 2017 at 2:14 AM, Michael C > <[email protected]> wrote: > > where can i read up on what a thread is and what it does? > > A book on operating systems would be a good place to start. > > A Thread is a CPU execution context. A Process can and generally will > have multiple threads executing code concurrently. A Process is a like > a container for threads, i.e. the virtual address space and security > context in which they execute (and a Windows Job is a container for > processes, and they're all contained in an NT Session). > > The operating system preemptively dispatches threads to give each a > time slice (quantum) that fairly distributes execution across the > available CPUs based on a combination of thread priority, process > priority, and CPU affinity (i.e. whether the process/thread has been > set to run on a subset of the available CPUs). A CPU context switch to > another thread is expensive, so the scheduler needs to strike a > balance between fairness and performance. > > With all of these threads executing concurrently, it's important to be > able to synchronize their operation. That's where dispatcher > (synchronization) objects come into play -- e.g. timers, events, > mutexes, semaphores, and even threads themselves (i.e. have one thread > wait for another thread to terminate). In Windows a thread can wait on > a dispatcher object using the *WaitFor*Object* family of wait > functions. A waiting thread doesn't get scheduled to execute until the > object its waiting for becomes signaled. However, an alertable wait > can be interrupted by posting an APC routine to the waiting thread's > APC queue, e.g. via QueueUserAPC. > > That said, a thread in Windows is more than just a CPU execution > context. For example, a thread can have an impersonation token to act > on behalf of another user on the system. This feature is typically > used by threads in service processes that are running as LocalSystem > (SYSTEM), LocalService, or NetworkService. That said, it's far more > common for a thread to implicitly operate in the security context of > the primary token of its owning process. > > (The user's access token is created by the Local Security Authority > (LSA) and kernel security reference monitor when the user is logged > on. The access token gets duplicated for every process, which allows > groups and privileges in the token to me enabled and disabled > separately in each process. All copies share the same logon session -- > e.g. for cached network credentials and for the object manager's > per-logon DosDevice directory.) > > Threads also own windows and receive window messages that are > sent/posted to their message queue -- such as WM_CREATE, WM_CLOSE, > WM_DESTROY, WM_QUIT, WM_KEYDOWN, WM_KEYUP, WM_CHAR, WM_HOTKEY, > WM_PAINT, WM_COPY, WM_CUT, WM_PASTE, WM_COPYDATA, WM_TIMER, > WM_SETTINGCHANGE, WM_DEVICECHANGE, WM_POWERBROADCAST, > WM_QUERYENDSESSION, WM_WTSSESSION_CHANGE, etc (way too many to list > them all). > > Also, I/O requests have thread affinity. In this case it's via the > thread's APC (asynchronous procedure call) queue and list of pending > IRPs (I/O request packets). I/O thread affinity is great for a client > application that's requesting I/O, but servers that have to maintain > throughput for thousands of I/O requests need to instead use a pool of > many threads to service requests. In this case I/O thread affinity is > a detriment, which is why Windows has an alternative: I/O completion > ports. When I/O completes via IOCP, it can be handled by the first > available thread in the pool. > > > more importantly, how do i switch to the proper thread? > > That's not something you should do. It may be possible to inject code > into the address space of another process and forcibly cause a given > thread in that process to execute it. But that's a rude thing to do > and would devolve into chaos if everyone wrote code like that. Just > send a WM_CLOSE message to the window. The window manager (implemented > in the win32k.sys kernel module) will send it to the message queue of > the owning thread, which can decide for itself whether it should call > DestroyWindow -- e.g. by asking the user if it's ok to close the > window. > --001a114871c6e006ec054fce3d1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Ok, I tried to read <a href=3D"https://msdn.microsoft= .com/en-us/library/windows/desktop/ms633573(v=3Dvs.85).aspx">https://msdn.m= icrosoft.com/en-us/library/windows/desktop/ms633573(v=3Dvs.85).aspx</a></di= v><div><br></div><div>But it doesn't say which one it belongs to, User3= 2 or Kernel32... I guess 'User-defined function name' is something = I have never seen before, I see that I should send this to the application:= </div><div><br></div><div>#define WM_CLOSE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0010</div><div><pre s= tyle=3D"padding:5px;margin-top:0px;margin-bottom:0px;overflow:auto;word-wra= p:break-word;word-break:break-word;white-space:pre-wrap;color:rgb(0,0,0);fo= nt-size:14px;font-family:consolas,courier,monospace"><br></pre><pre style= =3D"padding:5px;margin-top:0px;margin-bottom:0px;overflow:auto;word-wrap:br= eak-word;word-break:break-word;white-space:pre-wrap;color:rgb(0,0,0);font-s= ize:14px"><font face=3D"arial, helvetica, sans-serif">But I haven't fig= ured out how.</font></pre><pre style=3D"padding:5px;margin-top:0px;margin-b= ottom:0px;overflow:auto;word-wrap:break-word;word-break:break-word;white-sp= ace:pre-wrap;color:rgb(0,0,0);font-size:14px"><font face=3D"arial, helvetic= a, sans-serif"><br></font></pre><pre style=3D"padding:5px;margin-top:0px;ma= rgin-bottom:0px;overflow:auto;word-wrap:break-word;word-break:break-word;wh= ite-space:pre-wrap;color:rgb(0,0,0);font-size:14px"><font face=3D"arial, he= lvetica, sans-serif">thanks!</font></pre><pre style=3D"padding:5px;margin-t= op:0px;margin-bottom:0px;overflow:auto;word-wrap:break-word;word-break:brea= k-word;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px;font-family:con= solas,courier,monospace"><br></pre></div><div class=3D"gmail_extra"><br><di= v class=3D"gmail_quote">On Wed, May 17, 2017 at 10:03 PM, eryk sun <span di= r=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">eryksu= [email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex"><span class=3D"gmail-">On Thu, May 18, 2017 at 2:14 AM, Michael= C<br> <<a href=3D"mailto:[email protected]">mysecretrobotfactory@= gmail.<wbr>com</a>> wrote:<br> > where can i read up on what a thread is and what it does?<br> <br> </span>A book on operating systems would be a good place to start.<br> <br> A Thread is a CPU execution context. A Process can and generally will<br> have multiple threads executing code concurrently. A Process is a like<br> a container for threads, i.e. the virtual address space and security<br> context in which they execute (and a Windows Job is a container for<br> processes, and they're all contained in an NT Session).<br> <br> The operating system preemptively dispatches threads to give each a<br> time slice (quantum) that fairly distributes execution across the<br> available CPUs based on a combination of thread priority, process<br> priority, and CPU affinity (i.e. whether the process/thread has been<br> set to run on a subset of the available CPUs). A CPU context switch to<br> another thread is expensive, so the scheduler needs to strike a<br> balance between fairness and performance.<br> <br> With all of these threads executing concurrently, it's important to be<= br> able to synchronize their operation. That's where dispatcher<br> (synchronization) objects come into play -- e.g. timers, events,<br> mutexes, semaphores, and even threads themselves (i.e. have one thread<br> wait for another thread to terminate). In Windows a thread can wait on<br> a dispatcher object using the *WaitFor*Object* family of wait<br> functions. A waiting thread doesn't get scheduled to execute until the<= br> object its waiting for becomes signaled. However, an alertable wait<br> can be interrupted by posting an APC routine to the waiting thread's<br= > APC queue, e.g. via QueueUserAPC.<br> <br> That said, a thread in Windows is more than just a CPU execution<br> context. For example, a thread can have an impersonation token to act<br> on behalf of another user on the system. This feature is typically<br> used by threads in service processes that are running as LocalSystem<br> (SYSTEM), LocalService, or NetworkService. That said, it's far more<br> common for a thread to implicitly operate in the security context of<br> the primary token of its owning process.<br> <br> (The user's access token is created by the Local Security Authority<br> (LSA) and kernel security reference monitor when the user is logged<br> on. The access token gets duplicated for every process, which allows<br> groups and privileges in the token to me enabled and disabled<br> separately in each process. All copies share the same logon session --<br> e.g. for cached network credentials and for the object manager's<br> per-logon DosDevice directory.)<br> <br> Threads also own windows and receive window messages that are<br> sent/posted to their message queue -- such as WM_CREATE, WM_CLOSE,<br> WM_DESTROY, WM_QUIT, WM_KEYDOWN, WM_KEYUP, WM_CHAR, WM_HOTKEY,<br> WM_PAINT, WM_COPY, WM_CUT, WM_PASTE, WM_COPYDATA, WM_TIMER,<br> WM_SETTINGCHANGE, WM_DEVICECHANGE, WM_POWERBROADCAST,<br> WM_QUERYENDSESSION, WM_WTSSESSION_CHANGE, etc (way too many to list<br> them all).<br> <br> Also, I/O requests have thread affinity. In this case it's via the<br> thread's APC (asynchronous procedure call) queue and list of pending<br= > IRPs (I/O request packets). I/O thread affinity is great for a client<br> application that's requesting I/O, but servers that have to maintain<br= > throughput for thousands of I/O requests need to instead use a pool of<br> many threads to service requests. In this case I/O thread affinity is<br> a detriment, which is why Windows has an alternative: I/O completion<br> ports. When I/O completes via IOCP, it can be handled by the first<br> available thread in the pool.<br> <span class=3D"gmail-"><br> > more importantly, how do i switch to the proper thread?<br> <br> </span>That's not something you should do. It may be possible to inject= code<br> into the address space of another process and forcibly cause a given<br> thread in that process to execute it. But that's a rude thing to do<br> and would devolve into chaos if everyone wrote code like that. Just<br> send a WM_CLOSE message to the window. The window manager (implemented<br> in the win32k.sys kernel module) will send it to the message queue of<br> the owning thread, which can decide for itself whether it should call<br> DestroyWindow -- e.g. by asking the user if it's ok to close the<br> window.<br> </blockquote></div><br></div></div> --001a114871c6e006ec054fce3d1a-- --===============4788871916410361519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot --===============4788871916410361519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ctypes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ctypes-users --===============4788871916410361519==--