Commit Graph
668 Commits
Author SHA1 Message Date
Ray Chason 94834df5d1 Revise the column width calculation
The last column in a line continues to the end of the line, and may
overhang any subsequent columns in other lines.
2026-08-21 08:19:04 -04:00
nhmall 29cb8b7d9a Windows: group accelerator and menu item collision
In the event that there is a collision between a menu group accelerator
and an individual menu item's accelerator, disregard the group
accelerator.

'$' is the only known collision in NetHack 5.0 presently.

Close #805
2026-07-31 14:53:19 -04:00
nhmall 98bb86ab33 Windows: fix ascii map hilite_pet
hilite_pet was working with tiles, but not with ascii map.
2026-07-06 11:00:50 -04:00
nhmall bb0016db0a Windows:OPTIONS=windowtype:tty NetHackW.exe issue 2026-07-06 10:59:53 -04:00
nhmall 198ac655e5 more 3.7 vestiges
A little later than this probably should have been committed.
2026-06-20 18:26:43 -04:00
nhmall d78a875110 more Windows curses size tinkering 2026-05-16 12:15:20 -04:00
nhmall f5456fa92c another Windows issue causing startup grief 2026-05-11 22:59:42 -04:00
nhmall 2337a2bae5 Windows follow-up
Remove some unused temporary code
2026-05-10 16:04:09 -04:00
nhmall 745c7fb8d8 some windows fixes
Resolves #1526
2026-05-10 16:00:33 -04:00
nhmall 596ca7756c Merge branch 'NetHack-3.7' into to500 2026-05-02 09:55:08 -04:00
nhmall a127ec7dca Windows MSGSTOP bit
This is a stop gap fix.
2026-05-02 09:54:12 -04:00
nhmall 97f8ad10b4 more updates 2026-04-26 13:21:18 -04:00
nhmall 0e10f82856 update sys win 2026-04-26 12:42:38 -04:00
nhmall 2a6e7c47ec leave outdated files as 3.6; more to 5.0 2026-04-26 09:29:50 -04:00
nhmall 97b6fad509 "NetHack 3.7" to "NetHack 5.0" in doc include src sys win 2026-04-26 09:25:42 -04:00
nhmall 3b7c0e8a19 follow-up: more Windows startup 2026-04-09 14:14:49 -04:00
nhmall 335cd65d5a some further Windows startup tweaking 2026-04-09 14:04:28 -04:00
nhmall 6234e96b57 Change Windows startup - take 2
remove the safeproc pseudo-windowport routines from
almost a decade ago.

A very early pass is made through the config file,
seeking out just the interface-related OPTIONS=windowport
and OPTIONS=soundlib and ignoring all other options in the
config file during that early pass, so the windowport
can be activated without the NetHack core initialization
in place that some of the other rcfile OPTIONS require.

Bundles the existing rcfile processing code into rcfile().

New functions to control which rcfile options will be
disregarded in the early config file pass, and which will be
processed:

    set_all_options_disregarded();
    set_all_options_heeded();
    disregard_this_option(opt_xx);
    heed_this_option(opt_xx);

Windows calls rcfile_interface_options(), which is
a bundling of a series of function calls to achieve
the desired result.

    void
    rcfile_interface_options(void)
    {
        allopt_array_init();
        set_all_options_disregarded();
        heed_this_option(opt_windowtype);
        heed_this_option(opt_soundlib);
        rcfile();
        set_all_options_heeded();
        disregard_this_option(opt_windowtype);
        disregard_this_option(opt_soundlib);
    }
2026-04-05 13:11:14 -04:00
nhmall db1f230772 Revert "Change Windows startup"
This reverts commit acb85b18cf.

Some optlist issues arose on some platforms, but not all.
I need to investigate the cause of those.
2026-04-05 12:07:57 -04:00
nhmall acb85b18cf Change Windows startup
remove the safeproc pseudo-windowport routines from
almost a decade ago.

A very early pass is made through the config file,
seeking out just the interface-related OPTIONS=windowport
and OPTIONS=soundlib and ignoring all other options in the
config file during that early pass, so the windowport
can be activated without the NetHack core initialization
in place that some of the other rcfile OPTIONS require.

Bundles the existing rcfile processing code into rcfile().

New functions to control which rcfile options will be
disregarded in the early config file pass, and which will be
processed:

    set_all_options_disregarded();
    set_all_options_heeded();
    disregard_this_option(opt_xx);
    heed_this_option(opt_xx);

Windows calls rcfile_interface_options(), which is
a bundling of a series of function calls to achieve
the desired result.

    void
    rcfile_interface_options(void)
    {
        allopt_array_init();
        set_all_options_disregarded();
        heed_this_option(opt_windowtype);
        heed_this_option(opt_soundlib);
        rcfile();
        set_all_options_heeded();
        disregard_this_option(opt_windowtype);
        disregard_this_option(opt_soundlib);
    }
2026-04-05 11:37:20 -04:00
nhmall b3db46fd71 clear up some warnings in win/win32/NetHackW.c 2025-11-23 09:40:39 -05:00
nhmall d5658018ac alternative to display_inventory for window-port
Several window ports that support perm_invent were
using a call back to the core display_inventory()
function.

While calling from the window port back to core functions
is arguably not ideal in the first place, it was recently
brought to light that code NetHack-3.7 code changes to
display_inventory() actually caused it to stop repopulating
the perm_invent window as intended under certain circumstances.

For now, provide an alternative function, repopulate_perminvent(),
that hopefullshould still work the way it did previously.

There will likely be some additional changes after this to
further improve things, at some point.

For now though, this
Resolves #1454
2025-11-08 14:26:07 -05:00
nhmall d5d40b322c fix broken Windows GUI ascii mode text color
Issue identified in
https://github.com/NetHack/NetHack/issues/1359

Resolves #1359
2025-09-05 16:38:56 -04:00
nhmall 6c3e70ad77 remove stray tabs from *.c files and config.h 2025-08-19 08:35:39 -04:00
nhmall be5143bb74 window-port updates
Remove start_screen() and end_screen() from the
Window-port interface.

They were only ever used by tty, and there was a comment
carried to several window-ports about how they "really
should go away. They are tty-specific"

term_start_screen() and term_end_screen() are part of
terminal/NO_TERMS supporting routines now.
2025-01-04 23:38:34 -05:00
nhmall 37758c7e48 some tty updates
Add a note about NO_TERMS to include/wintty.h for clarity.

Rename tty_startup and tty_shutdown to term_startup() and
term_shutdown(). They are found in termcap.c for !NO_TERMS
like most of the other term_ routines, as well as having
versions for several of the NO_TERMS platforms. They aren't
part of the tty_interface called from the core. The tty
implementation does call and rely on them.

Remove some conditional #ifdef's around term_shutdown()
(formerly tty_shutdown()) and just ensure that all the
tty platforms have an implementation that they can link
with, even if it is just a stub presently.

Put the protype for nethack_exit in extern.h to reduce
maintenance to a single spot, and remove it from other
locations. A warning in the msdos cross-compile led to
this change.
2025-01-04 19:01:34 -05:00
nhmall c7276bcf67 more MSYS2 warning clean-up 2024-12-12 22:35:38 -05:00
nhmall e08bd9ef8a Windows NetHackW memory leak bit 2024-12-10 14:49:56 -05:00
nhmall b89e792873 Some Windows gcc fixes 2024-11-30 19:06:05 -05:00
nhmall 0792e5fe9e expand implicit fallthrough detection to non-gcc compilers
gcc has recognized various "magic comments" for white-listing
occurrences of implicit fallthrough in switch statements for
a long time:

    The range and shape of "falls through" comments accepted are
    contingent upon the level of the warning. (The default level is =3.)

    -Wimplicit-fallthrough=0 disables the warning altogether.
    -Wimplicit-fallthrough=1 treats any kind of comment as a "falls through" comment.
    -Wimplicit-fallthrough=2 essentially accepts any comment that contains something
     that matches (case insensitively) "falls?[ \t-]*thr(ough|u)" regular expression.
    -Wimplicit-fallthrough=3 case sensitively matches a wide range of regular
     expressions, listed in the GCC manual. E.g., all of these are accepted:
        /* Falls through. */
        /* fall-thru */
        /* Else falls through. */
        /* FALLTHRU */
        /* ... falls through ... */
       etc.
    -Wimplicit-fallthrough=4 also, case sensitively matches a range of regular
     expressions but is much more strict than level =3.
    -Wimplicit-fallthrough=5 doesn't recognize any comments.

Plenty of other compilers did not recognize the gcc comment convention,
and up until now the compiler warning for detecting unintended
fallthrough had to be suppressed on other compilers. That's because the code
in NetHack has been relying on the gcc approach, and only the gcc approach.

The C23 standard introduces an attribute [[fallthrough]] for the
functionality, when implicit fallthrough warnings have been enabled.

Several popular compilers already support that, or a very similar attribute
style approach, today, even ahead of their C23 support:

       C compiler                       whitelist approach
       ---------------------------   -------------------------------------
       C23 conforming compilers         [[fallthrough]]

       clang versions supporting
       standards prior to
       C23                              __attribute__((__fallthrough__))

       Microsoft Visual Studio
       since VS 2022 17.4.
       The warning C5262 controls
       whether the implict
       fallthrough is detected and
       warned about with
       /std:clatest.                    [[fallthrough]]

This adds support to NetHack for the attribute approach by inserting a
macro FALLTHROUGH to the existing cases that require white-listing, so
other compilers can analyze things too.

The definition of the FALLTHROUGH macro is controlled in include/tradstdc.h.

The gcc comment approach has also been left in place at this time.
2024-11-30 14:16:27 -05:00
nhmall 7ff17845c6 Windows MSYS2 build fix 2024-11-13 16:14:49 -05:00
nhmall 52a9af7278 early_init() was being called twice on Windows GUI 2024-11-13 13:57:18 -05:00
nhmall fa9210aa65 Windows: free more allocated memory before exit
This gets rid of the final leak complaint on Windows as of Nov 13, 2024
2024-11-13 13:48:50 -05:00
nhmall 277a0e4464 Windows NetHackW.c bit 2024-11-12 19:30:43 -05:00
nhmall 7414b906b2 release some memory before exit under Windows 2024-11-11 16:50:57 -05:00
nhmall 87af3a8cac fuzzer under Windows GUI hangs on minimize window
On the Windows GUI (nethackw.exe), while running the fuzzer,
if the NetHack window gets minimized, or someone minimizes all
desktop windows, the NetHack window stops responding and won't
even repaint itself. The NetHack process continues to use the
CPU.

A break in the debugger shows that it is caught in a do loop.

I didn't delve into the issue of why minimizing the window
triggers a condition that leads to the endless loop. This
just adds a kludge to exit the loop while fuzzing.
2024-10-12 09:28:29 -04:00
nhmall 0eb7f109e0 follow-up, program_state 2024-07-13 16:31:35 -04:00
nhmall 6c0ae092c6 distinguish global variables that get written to savefile
The g? structs had a mix of variables that were written to
the savefile, and those that were not.

For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.

This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.

Details:

    gb.bases            -> svb.bases
    gb.bbubbles         -> svb.bbubbles
    gb.branches         -> svb.branches
    gc.context          -> svc.context
    gd.disco            -> svd.disco
    gd.dndest           -> svd.dndest
    gd.doors            -> svd.doors
    gd.doors_alloc      -> svd.doors_alloc
    gd.dungeon_topology -> svd.dungeon_topology
    gd.dungeons         -> svd.dungeons
    ge.exclusion_zones  -> sve.exclusion_zones
    gh.hackpid          -> svh.hackpid
    gi.inv_pos          -> svi.inv_pos
    gk.killer           -> svk.killer
    gl.lastseentyp      -> svl.lastseentyp
    gl.level            -> svl.level
    gl.level_info       -> svl.level_info
    gm.mapseenchn       -> svm.mapseenchn
    gm.moves            -> svm.moves
    gm.mvitals          -> svm.mvitals
    gn.n_dgns           -> svn.n_dgns
    gn.n_regions        -> svn.n_regions
    gn.nroom            -> svn.nroom
    go.oracle_cnt       -> svo.oracle_cnt
    gp.pl_character     -> svp.pl_character
    gp.pl_fruit         -> svp.pl_fruit
    gp.plname           -> svp.plname
    gp.program_state    -> svp.program_state
    gq.quest_status     -> svq.quest_status
    gr.rooms            -> svr.rooms
    gs.sp_levchn        -> svs.sp_levchn
    gs.spl_book         -> svs.spl_book
    gt.timer_id         -> svt.timer_id
    gt.tune             -> svt.tune
    gu.updest           -> svu.updest
    gx.xmax             -> svx.xmax
    gx.xmin             -> svx.xmin
    gy.ymax             -> svy.ymax
    gy.ymin             -> svy.ymin

Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
          gf.ftrap, gl.light_base, gt.timer_base
2024-07-13 14:57:50 -04:00
PatR 05cbbc7181 fix PR #1254 - avoid signed integer overflow
Pull request from mkuoppal:  avoid integer overflow when user types
digits and they're combined into a number by successively multiplying
intermediate value by 10 and adding new digit.  Needed to avoid
triggering undefined behavior if the value overflows the largest
signed integer (actually long int).

This is a much more general fix than the code in the pull request,
which imposed an arbitrary limit for one aspect of tty input.

I'm not convinced that integer.h was the right place to add the new
AppendLongDigit() macro.  I may not have caught all the places where
it is needed.  files.c accumulates a value from digits but uses
unsigned int, so overflow won't trigger undefined behavior (although
it presumably ends up with a different value than what was intended).
options.c and coloratt.c accumulate smaller integers and have a limit
on the number of digits they'll use, so can't overflow.

Fixes #1254
2024-06-09 14:17:14 -07:00
RainRat e7aaf8dc1c fix typos 2024-04-26 08:10:10 -04:00
nhmall e20774e16f updated workaround for vs conflict 2024-04-15 12:52:08 -04:00
nhmall 7e6dab38c5 work around a conflict with visual studio build 2024-04-15 12:45:49 -04:00
nhmall 453eacdcb6 include the manifest in NetHackW res 2024-04-15 12:09:23 -04:00
nhmall 15db874f71 CHANGE_COLOR palette option adjustments
It was too early to call the windowport change_color() routine
while processing the config file. The windowport was not yet
fully operational.

Now the palette option processing will just place the rgb
value into the appropriate ga.altpalette[CLR_MAX] entry.

init_sound_disp_gamewindows(void) [allmain.c] calls
change_palette() [coloratt.c] and it will call the windowport
change_color() function for each ga.altpalette[] entry that
has been set.

Notes:
The rgb values stored in ga.altpalette[] have the NH_ALTPALETTE bit set
so that the rgb value of 0 can be stored and be distinguishable from
a "not set" entry.

The NH_ALTPALETTE bit is cleared from the rgb value in change_palette()
prior to calling the windowport change_color() function.

The syntax for palette is colorname/r-g-b.
For example: palette:black/12-12-12

colorname must be one of the NH_BASIC_COLOR names or a suitable
alias for one of those 16 entries.

Some of the windowport CHANGE_COLOR functions had the wrong parameters,
perhaps due to bitrot. Those have been corrected to match the prototype.
2024-04-12 21:57:27 -04:00
nhmall 750cf7f619 rename glyphmap nhcolor field to customcolor 2024-03-24 11:04:31 -04:00
nhmall 71c78449e5 Windows mswin follow-up 2024-03-23 17:21:18 -04:00
nhmall ba00dc9066 sever extracolors from utf8map and ENHANCED_SYMBOLS
move the custom color data into its own field in the glyphmap
and disassociate it from the unicode/utf8 stuff.

move the glyphcache stuff during options processing and parsing
into new file glyphs.c and out of utf8map.c, and make it
general, and not part of ENHANCED_SYMBOLS.

Do the groundwork for allowing glyph color customizations to
work when any symset is loaded and not restrict it only to
the enhanced1 H_UTF8 symsets.

The customizations in effect are still affiliated with a particular
symset.

Also closes #1224, but the PR itself references a data structure
made obsolete by this commit. The curses comment from the PR was
added into the code.

The PR also made several suggestions, but only the first
one has been included in this commit (and no longer based on
the handler), that being:
"allow defining colors if other symbol handling modes are used
(possibly limited to the standard 16 colors)."

FredrIQ also wrote the following suggestions in PR#1224:

Something I was also contemplating, unrelated to implementation of this
support in curses, would be the ability for the following:

allow defining colors if other symbol handling modes are used (possibly limited to the standard 16 colors)
allow defining attributes (for example: glyph:G_pet_female_kitten:U+0066/red/underline)
allow specifying glyphs as wildcards for defining global color/attribute changes

Something I also want to see are keywords for "don't change the current defined data". If this
were to be added, you could for example do this:
OPTIONS=glyph:G_*_fox:U+0064/blue
OPTIONS=glyph:G_statue_*:basechar/gray/underline
for "make all foxes use a blue color, make all statues gray with underline" without needing
to specify the relevant character for every statue. This ("basechar", "basefg", etc)
should perhaps also be added for MENUCOLORS and statushilites, so that you can, for
example, underline all items being worn without needing to specify a bunch of
near-duplicate rules for combining BUC colors + underline worn items
as per #1064
2024-03-23 15:36:22 -04:00
nhmall b6b9bb0f27 follow-up to curses windowcolors
Make sure the windowcolors option can be specified more than
once without a config file warning.

Make the struct holding the details a little more extendable.
2024-03-17 14:18:14 -04:00
nhmall 6619d10d90 ENHANCED_SYMBOLS: store all CLR_ colors specially
The 0x1000000 bit (NH_BASIC_COLOR bit) was used to mark
CLR_BLACK when storing it in u->ucolor. Now, all of the basic CLR_*
colors are stored that way.

The NH_BASIC_COLOR bit indicates that the value in u->ucolor is
not an rgb value, rather it is one of the 0-15 basic NetHack colors.
The window-ports need to strip the NH_BASIC_COLOR bit off before using
it for color changes.
2024-03-03 18:31:11 -05:00
Pasi Kallinen 53778ee507 Use single define for max message history
... instead of having every windowport define their own variant.
Affects tty, curses, X11, and Windows GUI.
2024-03-03 11:34:59 +02:00