when executing a script, we did advance argp0 unconditionally
to replace argv[0] with the script name. this fails when
argv[] is empty, then we'd advance argp0 past the nil terminator.
the alternative would be to *not* advance if *argp0 == nil, but that
would require another validaddr() check for a case that is unlikely
to have been anticipated in most programs being invoked as
libc's ARGBEGIN macro assumes argv[0] being non-nil as it also
unconditionally advances the argv pointer.
to keep us sane, we now reject an empty argv[]. on entry, we
verify that argv[] is valid for at least two elements:
- the program name argv[0], has to be non-nil
- the first potential nil terminator in argv[1]
when argv[0] == nil, we throw Ebadarg "bad arg in system call"
this allows members of the -1 group to create new directories in /
without having to fiddle with the fileserver console. this also
makes it consistent to hjfs and cwfs.
this allows members of the -1 group to create new directories in /
without having to fiddle with the fileserver console. this also
makes it consistent to hjfs.
the psaux driver is not used in any kernel configuration and theres
no userspace mouse daemon. i8042auxcmds() is wrong as access
to the user buffer can fault and we are holding an ilocks.
little cleanups in devkbd.
on vmware, loading a new kernel sometimes reboots when
wiggling the mouse. disabling keyboard and mouse on
shutdown fixes the issue.
make sure ps2 mouse is disabled on init, will get re-enabled
in i8042auxenable().
keyboard isnt special anymore, we can just use the devreset
entry point in the device to do the keyboard initialization,
so kbdinit()/kbdenable() are not needed anymore.
the keyboard stops sending interrupts when its fifo gets full,
which can happen on boot when keys get mashed while interrupts
are still disabled. to work arround this, call the keyboard
interrupt handler when kbd.q is starved before blocking.
interpreting octal breaks parsing of decimal numbers with
leading zeros. the manpage listed this in the BUGS section,
so we'r going to fix it as this just causes confusion as
most callers of atoi() do not expect it.
add bootscreenconf(VGAscr *) function, that is called whenever
the framebuffer configuration is changed by devvga. that way, we
can pass the current setting of the framebuffer to the new
kernel when using /dev/reboot.
parsecookie() used to inplace modify the request path
for implicit path (to get the directory from path) and
also did it wrong. now have a static copy and do not
remove the last slash.
as usual, the dude with the hardware vanished so i cannot
develop this further. setting mode worked the last time
but only when using vesa before, so some bits are still
missing. commiting this as it is so i dont have to start
from scratch once we have hardware again.
basedefault[], the default path to the config file, is never set and remains
blank, unless -config %s is used (cd d_main.c). when games/doom attempts to
open the file, it silently fails and no config file is ever read or written.
this patch sets basedefault to a file in whatever directory a valid wad is
found in I_IdentifyWAD().
due to a typo in p_inter.c:P_TouchSpecialThing(), a message that is supposed
to show up when the player picks up a medikit while low on health (< 25), is
never displayed. the check for low health is done after the health is already
increased, so the condition is never true.
a cosmetic bug in all old doom executables that also seems interesting to fix.
to test: compare message displayed when picking up a medikit with and without
the patch
due to a typo in st_stuff.c:ST_updateFaceWidget(), doomguy mistakenly never
looks shocked when taking more than 20 damage, but rather when he gains more
than 20 health while being hit.
this is a cosmetic bug in all old versions of doom's executables, but it seems
appropriate to fix.
simple test: fire a rocket at a nearby wall, taking enough damage.
