> Date: Wed, 01 May 2013 11:15:23 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 14326@debbugs.gnu.org

>
>  > I am running Emacs 24.3 on Windows 7, with only two commands in my Emacs
>  > init file:
>  >     (w32-send-sys-command 61488) ;; maximize frame at startup
>  >     (set-default-font "Monaco-10")
>  > The first command works well alone, but it stops to maximize frame after
>  > the second one is
>  > added to init file. However, if eval them after Emacs starts up by M-x
>  > eval-expression, then  (w32-send-sys-command 61488) still works.
>
> Does interchanging the order of these two lines change anything?

I'd be surprised if it didn't.  It does here.  See below.

> and what happens when you do
>
> (progn
>    (w32-send-sys-command 61488) ;; maximize frame at startup
>    (sit-for 1)
>    (set-default-font "Monaco-10"))
>
> instead?

Doesn't work, either.  Triggering redisplay doesn't help here.

> Conceptually: Does anyone know whether sending a 61488 request to
> Windows has Windows call us back with a maximize request?

Of course, it does.  (And the 61488 request is not sent to Windows, it
is sent to our own window procedure.)  Since we don't process the
61488 (a.k.a. WM_SYSCOMMAND) message, we get WM_SIZE as its result.
Until we get that WM_SIZE message, our frame is not really maximized,
and its dimensions are not reflected in the frame object's internals.
So set-default-font uses the previous dimensions, and effectively
resets or countermands the effect of w32-send-sys-command.

Invoking the commands in the reverse order doesn't have this problem,
because the effect of set-default-font is immediate.

Moreover, I submit that the OP does not _want_ to invoke
set-default-font after maximizing the frame, even if it did work.
That's because changing the font of a maximized frame will either make
it not maximized (if the new font is smaller) or make some of its
parts, such as the minibuffer, invisible (if the font is larger).  The
machinery that maximizes the frame takes the font into account, so
changing the font afterwards defeats what it does by invalidating all
the pixel calculations Windows does using the previous font.

IOW, this is not a bug, but rather a cockpit error.  The correct way
is to swap the order of these two lines.