• Build instructions for Windows

    From Nightfox@DIGDIST to Digital Man on Friday, July 23, 2021 14:00:32
    Hi DM,

    Recently I've tried building the Synchronet binaries for Windows using Visual Studio (for debugging purposes), and I imagine some things may have changed since the last time I built the binaries, a while ago. I had to do a couple things to get things to build (and still, a few of the projects are still failing to build), and I didn't see information on these steps on the wiki (though they may be there and I didn't see them). I wanted to share in case anyone might find this information useful.

    I was following a page on the wiki for debugging Synchronet with Visual Studio: https://wiki.synchro.net/howto:msvc
    One thing is that the wiki mentions using Visual Studio 2019. I found that I was getting errors saying the v141_xp toolkit was missing. It seems the v141 build tools are available through the Visual Studio 2019 Community installer, but it seems specifically the v141 XP tools have been deprecated and removed. In order to install the v141_xp tools, I had to also install Visual Studio 2017 Community and enable the XP build tools during the install.

    Also, while building, Visual Studio reported gitinfo.bat was returning with error code 255. I found gitinfo.bat was trying to run tr (the GNU translate tool), and I didn't have that installed for Windows. I downloaded the GNU Core utils for Windows here & installed that, which solved that issue:
    http://gnuwin32.sourceforge.net/packages/coreutils.htm

    After that, still just 3 of the projects failed to build. VS reports build errors for sbbs, textgen, delfiles, and upgrade_to_v319. The errors are all from text.h regarding a missing #endif, and when I checked text.h, it's incomplete - The last line is "enum :":

    /* text.h */

    /* Synchronet static text string constants */

    /****************************************************************************/ /* Macros for elements of the array of pointers (text[]) to static text*/
    /* Auto-generated from CTRL\TEXT.DAT*/ /****************************************************************************/

    #ifndef _TEXT_H
    #define _TEXT_H

    enum {


    I seem to remember seeing something a while ago that generates text.h, but I don't remember what it was now.


    What I'd like to do is to build the debug binaries for Windows and attach the VS debugger to the sbbsctrl process, because I'm still finding that Synchronet tends to crash every so often on my setup (requiring a program to perodically check to see whether sbbsctrl.exe is running, and re-start it if it's not).

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man to Nightfox on Friday, July 23, 2021 15:24:36
    Re: Build instructions for Windows
    By: Nightfox to Digital Man on Fri Jul 23 2021 02:00 pm

    One thing is that the wiki mentions using Visual Studio 2019. I found that I was getting errors saying the v141_xp toolkit was missing. It seems the v141 build tools are available through the Visual Studio 2019 Community installer, but it seems specifically the v141 XP tools have been deprecated and removed. In order to install the v141_xp tools, I had to also install Visual Studio 2017 Community and enable the XP build tools during the install.

    Strange. I've install MSVC2019 on multiple stock Windows 10 systems and was able to build sbbs. I guess I'll have to try that again someday to insure that still works. <shrug>

    Also, while building, Visual Studio reported gitinfo.bat was returning with error code 255. I found gitinfo.bat was trying to run tr (the GNU translate tool), and I didn't have that installed for Windows. I downloaded the GNU Core utils for Windows here & installed that, which solved that issue: http://gnuwin32.sourceforge.net/packages/coreutils.htm

    Yup, the 'tr' utility is now a requirement. That dependency will likely go away someday (e.g. when I switch to CMake).

    After that, still just 3 of the projects failed to build. VS reports build errors for sbbs, textgen, delfiles, and upgrade_to_v319. The errors are all from text.h regarding a missing #endif, and when I checked text.h, it's incomplete - The last line is "enum :":

    /* text.h */

    /* Synchronet static text string constants */

    /*************************************************************************** */ /* Macros for elements of the array of pointers (text[]) to static text*/ /* Auto-generated from CTRL\TEXT.DAT*/ /************************************ ****************************************/

    #ifndef _TEXT_H
    #define _TEXT_H

    enum {

    That looks like textgen failed (crashed?) when trying to generate the files (text.h, text.js).

    I seem to remember seeing something a while ago that generates text.h, but I don't remember what it was now.

    It's textgen. You'll need to build that (which also runs it and should generate the output files).

    What I'd like to do is to build the debug binaries for Windows and attach the VS debugger to the sbbsctrl process, because I'm still finding that Synchronet tends to crash every so often on my setup (requiring a program to perodically check to see whether sbbsctrl.exe is running, and re-start it if it's not).

    Great, would love to get the root-cause of any crashing bugs. :-)
    --
    digital man

    Synchronet "Real Fact" #82:
    Flapuebarg unf vagreany ebg13 fhccbeg sbe fhcresvpvnyyl rapelcgvat grkg.
    Norco, CA WX: 86.9°F, 50.0% humidity, 11 mph NE wind, 0.00 inches rain/24hrs
  • From Nightfox@DIGDIST to Digital Man on Friday, July 23, 2021 21:38:50
    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Fri Jul 23 2021 03:24 pm

    That looks like textgen failed (crashed?) when trying to generate the files (text.h, text.js).

    I've found that when tryign to build textgen, text.h is incomplete so textgen fails to build. I tried copying the full text.h from the git repository and pasting it into my text.h and textgen was able to build. I also found that the SBBSEXEC environment variable has to be set (pointing to the sbbs\exec directory). Now when I try to build Synchronet in Visual Studio, it's complaining about unidentified identifiers in sbbs:

    file.cpp: FChecksum, FTags, FAuthor, FGroup, FUploadedTo, TagFilePrompt, EditExtDescriptionQ

    netmail.cpp: FidoNetMailSent, QWKNetMailSent, InternetMailSent

    upload.cpp: TagFileQ, TagFilePrompt

    useredit.cpp: HowManyColumns, FileInfoEditPrompt

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man to Nightfox on Friday, July 23, 2021 22:30:52
    Re: Build instructions for Windows
    By: Nightfox to Digital Man on Fri Jul 23 2021 09:38 pm

    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Fri Jul 23 2021 03:24 pm

    That looks like textgen failed (crashed?) when trying to generate the files (text.h, text.js).

    I've found that when tryign to build textgen, text.h is incomplete so textgen fails to build. I tried copying the full text.h from the git repository and pasting it into my text.h and textgen was able to build. I also found that the SBBSEXEC environment variable has to be set (pointing to the sbbs\exec directory). Now when I try to build Synchronet in Visual Studio, it's complaining about unidentified identifiers in sbbs:

    file.cpp: FChecksum, FTags, FAuthor, FGroup, FUploadedTo, TagFilePrompt, EditExtDescriptionQ

    I think you mean FiChecksum, etc.

    netmail.cpp: FidoNetMailSent, QWKNetMailSent, InternetMailSent

    upload.cpp: TagFileQ, TagFilePrompt

    useredit.cpp: HowManyColumns, FileInfoEditPrompt

    textgen *creates* the text.h file (from your text.dat file). Looks like you're trying to use an *older* text.h file. Those enums are in the current text.h in Git. Perhaps your text.dat file is just old?
    --
    digital man

    Synchronet/BBS Terminology Definition #82:
    Telix = Commercial MS-DOS and Windows communications/terminal program
    Norco, CA WX: 67.4°F, 85.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs
  • From Nightfox@DIGDIST to Digital Man on Saturday, July 24, 2021 11:43:00
    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Fri Jul 23 2021 10:30 pm

    textgen *creates* the text.h file (from your text.dat file). Looks like you're trying to use an *older* text.h file. Those enums are in the current text.h in Git. Perhaps your text.dat file is just old?

    I did a "git pull", and it says I'm already up to date.
    I tried deleting my text.h and rebuilding the solution, and VS said 20 succeeded and 20 failed. All the errors now are due to text.h being missing.

    Then I wondered if I need to just build textgen and run that first. But even textgen fails to build because text.h is missing (apparently the textgen project includes sbbs.h which tries to include text.h).

    I'm at a bit of a loss right now about what I can do to get the sbbs solution to build.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man to Nightfox on Saturday, July 24, 2021 20:13:12
    Re: Build instructions for Windows
    By: Nightfox to Digital Man on Sat Jul 24 2021 11:43 am

    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Fri Jul 23 2021 10:30 pm

    textgen *creates* the text.h file (from your text.dat file). Looks like you're trying to use an *older* text.h file. Those enums are in the current text.h in Git. Perhaps your text.dat file is just old?

    I did a "git pull", and it says I'm already up to date.
    I tried deleting my text.h and rebuilding the solution, and VS said 20 succeeded and 20 failed. All the errors now are due to text.h being missing.

    Then I wondered if I need to just build textgen and run that first. But even textgen fails to build because text.h is missing (apparently the textgen project includes sbbs.h which tries to include text.h).

    I'm at a bit of a loss right now about what I can do to get the sbbs solution to build.

    Just get the current text.h from git via "git pull". You can remove or disable the textgen project from your solution since its causing you such problems. The text.h from Git is all you need.
    --
    digital man

    Synchronet "Real Fact" #77:
    Rob Swindell still has dozens of BBS-related magazines in his possession. Norco, CA WX: 69.9°F, 77.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
  • From Nightfox@DIGDIST to Digital Man on Sunday, July 25, 2021 12:33:08
    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Sat Jul 24 2021 08:13 pm

    Just get the current text.h from git via "git pull". You can remove or disable the textgen project from your solution since its causing you such problems. The text.h from Git is all you need.

    I even went a step further and made a fresh clone of the Synchronet git repository. I unloaded the tetgen project and built it, and it all successfully built.

    I copied the debug binaries to my sbbs\exec directory and I'm running it with the VS debugger attached now so that next time it crashes, hopefully I can get some useful information.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Nightfox@DIGDIST to Digital Man on Saturday, July 31, 2021 14:19:52
    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Fri Jul 23 2021 03:24 pm

    Great, would love to get the root-cause of any crashing bugs. :-)

    Interesting thing, I've been running my debug build of Synchronet with Visual Studio's debugger monitoring it now for 6 days and it hasn't crashed yet.. Before this, it seemed it was randomly crashing after anywhere between several hours to a couple days or so. So I'm still not sure what's triggering the crash. I'm wodnering if there's anything different about the debug build where the crash might not be triggered with this build..

    I am running my BBS in a virtual machine, and I increased the VM specs a little bit to allow it to run Visual Studio's debugger more easily without the VM getting slow. I increased the VM CPU core count from 1 to 2, and increased the RAM from 2GB to about 3.5GB. I'm not sure if that would make a difference with the particular crash I was seeing.

    They say the watched pot never boils.. But who knows, maybe it will crash right after I send this message.. :P

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man to Nightfox on Saturday, July 31, 2021 16:57:23
    Re: Build instructions for Windows
    By: Nightfox to Digital Man on Sat Jul 31 2021 02:19 pm

    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Fri Jul 23 2021 03:24 pm

    Great, would love to get the root-cause of any crashing bugs. :-)

    Interesting thing, I've been running my debug build of Synchronet with Visual Studio's debugger monitoring it now for 6 days and it hasn't crashed yet.. Before this, it seemed it was randomly crashing after anywhere between several hours to a couple days or so. So I'm still not sure what's triggering the crash. I'm wodnering if there's anything different about the debug build where the crash might not be triggered with this build..

    Debug builds run slower than non-debug builds and that can sometimes prevent crash-causing race conditions from occurring. But those bugs are fairly rare. There are other differences in debug builds (e.g. optimizations disabled), so you could try running a release (non-debug) build instead and see if the problem seems to happen more often.

    I am running my BBS in a virtual machine, and I increased the VM specs a little bit to allow it to run Visual Studio's debugger more easily without the VM getting slow. I increased the VM CPU core count from 1 to 2, and increased the RAM from 2GB to about 3.5GB. I'm not sure if that would make a difference with the particular crash I was seeing.

    Increasing RAM can also impact performance of applications, impacting the timing which may cause or prevent crash-causing race conditions from happening. I don't *think* it would impact the JavaScript heap (that's a configurable value in sbbs) - but JS crashes related to the heap and garbage collection are *not* rare, so sometimes chaing the JS heap ("MaxBytes") can change the occurrence of some bugs.

    They say the watched pot never boils.. But who knows, maybe it will crash right after I send this message.. :P

    Good luck!
    --
    digital man

    Rush quote #5:
    Some are born to rule the world, to live their fantasies
    Norco, CA WX: 88.5°F, 38.0% humidity, 12 mph ENE wind, 0.00 inches rain/24hrs
  • From Nightfox@DIGDIST to Digital Man on Monday, August 02, 2021 08:54:04
    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Sat Jul 31 2021 04:57 pm

    Debug builds run slower than non-debug builds and that can sometimes prevent crash-causing race conditions from occurring. But those bugs are fairly rare. There are other differences in debug builds (e.g. optimizations disabled), so you could try running a release (non-debug) build instead and see if the problem seems to happen more often.

    That may be what's going on. I was hoping that by using the debug build, I could have Visual Studio show what point in the code is causing the crash. Visual Studio can still debug release builds, but I'm not sure it would have enough information with a release build to identify the line of code causing a crash.

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man to Nightfox on Monday, August 02, 2021 12:13:23
    Re: Build instructions for Windows
    By: Nightfox to Digital Man on Mon Aug 02 2021 08:54 am

    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Sat Jul 31 2021 04:57 pm

    Debug builds run slower than non-debug builds and that can sometimes prevent crash-causing race conditions from occurring. But those bugs are fairly rare. There are other differences in debug builds (e.g. optimizations disabled), so you could try running a release (non-debug) build instead and see if the problem seems to happen more often.

    That may be what's going on. I was hoping that by using the debug build, I could have Visual Studio show what point in the code is causing the crash. Visual Studio can still debug release builds, but I'm not sure it would have enough information with a release build to identify the line of code causing a crash.

    It will. A debug build is not required to find the line of code where an exception/crash occurs.
    --
    digital man

    This Is Spinal Tap quote #1:
    Nigel Tufnel: These go to eleven.
    Norco, CA WX: 93.5°F, 22.0% humidity, 2 mph ENE wind, 0.00 inches rain/24hrs
  • From Nightfox@DIGDIST to Digital Man on Monday, August 02, 2021 14:16:35
    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Mon Aug 02 2021 12:13 pm

    I'm not sure it would have enough information with a release build to
    identify the line of code causing a crash.

    It will. A debug build is not required to find the line of code where an exception/crash occurs.

    I always thought a debug build was the only way to generate debug information for that kind of thing. But after thinking about it, I think Visual Studio can build .pdb files with source code information for a release build as well?

    Nightfox

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man to Nightfox on Monday, August 02, 2021 20:28:18
    Re: Build instructions for Windows
    By: Nightfox to Digital Man on Mon Aug 02 2021 02:16 pm

    Re: Build instructions for Windows
    By: Digital Man to Nightfox on Mon Aug 02 2021 12:13 pm

    I'm not sure it would have enough information with a release build to
    identify the line of code causing a crash.

    It will. A debug build is not required to find the line of code where an exception/crash occurs.

    I always thought a debug build was the only way to generate debug information for that kind of thing. But after thinking about it, I think Visual Studio can build .pdb files with source code information for a release build as well?

    Yes. There will be some information lost (like parameter values?) and optimization may do some strange things when stepping through the code, but you can still use the debugger with a release build.
    --
    digital man

    Rush quote #66:
    He's old enough to know what's right, but young enough not to choose it
    Norco, CA WX: 82.6°F, 29.0% humidity, 5 mph ENE wind, 0.00 inches rain/24hrs