Re: Fix for Emacs Crash - revisited

[bkey1]

  > IMHO the test should *exclude* the platforms where you know the call to
  > OpenProcessToken fails, not include the ones where it works, because the
  > first subset is more likely to remain stable than the second one.
Good idea, I will make this change tonight.

  > 
  > Usually it means that it consists of dead code, i.e., that no machine code
  > was generated for those source locations... Or there's something I'm
  > missing?
I would agree with this if it where not for the global variable test
I did (I set a global variable to a specific value in syms_of_w32menu,
set a breakpoint in initialize_frame_menubar which is called after 
syms_of_w32menu, and found that at this point the global variable had
that specific value).

  > 
  > Anyway, it is still interesting trying to determine why it does happens
  > in XP vs. 9x/Me and not, for example, 2K vs 9x/Me.
One of the grand mysteries of the universe.  I also would like to know
the answer to this question, but I was unable to find it.  As I said before,
I am uncomfortable when I cannot determine why a change that fixes a crash
is necessary.  That is why I tested this change as throughly as I did.

> 
> As an aside: According to the Platform SDK, OpenProcessToken only exists
> in NT 3.1 and later, not in the 9x series...
The Platform SDK documentation says it is only Supported in Windows
NT / 2000 / XP.  This does not necessarily mean it does not exist in
other versions of Windows.  I found out that it does exist in the
version of advapi32.dll found on Windows 9x by using dumpbin /exports.
If OpenProcessToken did not exist in Windows 9x, Emacs would not even
run in Windows 9x.  Instead, a dialog complaining about OpenProcessToken
not being found would be displayed and then Emacs would exit unless we
changed the code to call OpenProcessToken via a function pointer rather
than calling it directly.  NOTE: The call to OpenProcessToken was there
before I made my change.