The Major BBS Forums

This document is based on the installation instructions written and hosted on elwynor.com which is a install guide aimed at 32-bit platforms. This document specifically is to tackle the few extra challenges when operating WorldGroup under a 64-bit Windows.

--[Installing WorldGroup 3.2 in Windows 64-bit]--
First step is to download the WorldGroup 3.2 Installer https://www.themajorbbs.com/download/worldgroup-3-2-installer/
Unzip the installer and run it. Eventually you will get to a prompt in the install wizard that will ask for the path which the default is “C:\Program Files\Galacticomm\Worldgroup Server”. DO NOT USE THIS! Instead change the path to “C:\WGSERV”. This will make future installs of addons and configuring a lot simpler.
I do not recommend auto starting the BBS on initial install. You can change this later in the services if you decide you want to run it at system start. Just remember this will start the BBS before login.

Once you get the BBS installed and the initial start, you can go ahead and shut it down to do some fine tuning. For WorldLink (Soon to be named MajorLink) we will want to increase the settings for the Btrieve data base engine.

For Windows 10 64-bit go to path
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Btrieve Technologies\Microkernel Workstation Engine\Version 6.15\Settings
and set the following values
- Max Files: hex 1000 (4096 decimal)
- Max Handles: hex 1000 (4096 decimal)
- Max Locks: hex FF (decimal 255)

Now let us make another change so WorldGroup gives us a much more informative console window instead of the Windows control panel which is not that helpful to be honest.

For Windows 10 64-bit go to path
Computer\HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Galacticomm\Worldgroup Server\CurrentVersion
and change value useConsoleWindow from 0 to 1

(FYI: The other registry configurations for WorldGroup is located here Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Galacticomm\Worldgroup Server\CurrentVersion)

Now when you restart WorldGroup it will display the console which allows you to do several extremely useful tasks. View and edit users. Monitor channels. Etc. If this is your first time running WorldGroup or Major BBS, I would highly recommend getting familiar with the console at this point.

When you are ready for the next step, I would recommend to setup WorldLink (MajorLink) which another document located here https://www.themajorbbs.com/forums/viewtopic.php?f=35&t=130 can get you started on that.


--[Installing addons into WorldGroup under Windows 64-bit]--
The two inevitable problems you are going to run into; DOS and Windows 16-bit installers do not run on the Windows 64-bit platform. Do not despair this is easily remedied.

DOS Installers
For WG addons that use DOS installers. You can usually tell an addon uses a DOS installer because it will usually have a program named “install.exe” in the archive. So, to use a DOS installer we need to download and install DOSBox. Extract the addon you want to install somewhere at the root of the same drive. For this document I am going to use the path “C:\temp”
Once it’s installed than go ahead and run it. Once you are at the DOS prompt, type “mount c C:\” assuming you installed WorldGroup to “C:\WGSERV”. If, for example, you installed WorldGroup to “D:\WGSERVER” than use “mount d D:\”
DOSBox will give you a warning. Take note that we are here on a single purpose and not to just fiddling around playing games.
So now that your C: drive is mounted to DOSBox as C: drive we can go to the C drive by typing “C:” and then type “CD temp” (the path we extracted the addon archive.) Now just type “install” and the installer should do its thing.

Windows 16-bit Installers
So, the other issue you can run into with addons is the ones using a 16-bit Install Shield. These are the older addons with a file “setup.exe” in the archive. While the installer is set to target 32-bit windows the installer itself is 16-bit. (It was an awkward time back then.) The solution for this comes from the folks over at ReactOS. First extract the archive in any place you want to install from. Windows installers are not picky, and you will not have to use a command line to get there. Now download the file http://toastytech.com/files/Is5Launcher.zip (Keep a copy of this file as you will need it for other installers down the road most likely.) Now copy the setup.exe over the top of the existing setup.exe in your extracted addon directory. This is replacing the 16-bit installer shell with a 32-bit installer shell that can read the same version of Install Shield script files. Run the setup.exe as normal.


--[Being able to read help (.hlp) files on Windows 10]--
There is a bunch of methods out there for getting around this. They are all a bit sketchy to be honest but the method I found the most trustworthy is https://www.winhelponline.com/blog/view-winhelp-hlp-files-windows-10-with-winhlp32-exe/
Use a search engine and your better judgement.

I have been running WorldGroup in Windows 10 64-bit for a while now and the performance and reliability has been solid. Another advantage to running in Windows 10 (32 or 64 bit) is that you can easily setup external door games as a GHost system using DOSBox. Which will be in a future write-up coming soon.


Thanks to community member BadOPCode for this write-up!

The installer appears to hang and not progress on Windows 10 20H2. I haven't found a work around on this yet, Compatibility doesn't resolve it either. Anyone else having issues or get it to work?

Ramius1701 wrote:
> The installer appears to hang and not progress on Windows 10 20H2. I
> haven't found a work around on this yet, Compatibility doesn't resolve it
> either. Anyone else having issues or get it to work?

No I have never had that happen to me. The version I'm running is 20H2 as well and just recently did a install. What part of the installer is hanging? If it's the file copying part you might want to try making a directory C:\WGSERV and set the permissions to full with your account.

BadOPCode wrote:
> Ramius1701 wrote:
> > The installer appears to hang and not progress on Windows 10 20H2. I
> > haven't found a work around on this yet, Compatibility doesn't resolve it
> > either. Anyone else having issues or get it to work?
>
> No I have never had that happen to me. The version I'm running is 20H2 as well and
> just recently did a install. What part of the installer is hanging? If it's the
> file copying part you might want to try making a directory C:\WGSERV and set the
> permissions to full with your account.

At launch, I double click the installer and agree to run as administrator, get the hourglass, and then nothing. I even let it sit for an hour and eventually have to end the task on it. I have even disabled UAC still the same. I have tried 3.2 and 3.3.

Ramius1701 wrote:
> BadOPCode wrote:
> > Ramius1701 wrote:
> > > The installer appears to hang and not progress on Windows 10 20H2. I
> > > haven't found a work around on this yet, Compatibility doesn't resolve it
> > > either. Anyone else having issues or get it to work?
> >
> > No I have never had that happen to me. The version I'm running is 20H2 as well
> and
> > just recently did a install. What part of the installer is hanging? If it's
> the
> > file copying part you might want to try making a directory C:\WGSERV and set the
> > permissions to full with your account.
>
> At launch, I double click the installer and agree to run as administrator, get the
> hourglass, and then nothing. I even let it sit for an hour and eventually have to end
> the task on it. I have even disabled UAC still the same. I have tried 3.2 and 3.3.

So your not even getting a window from the installer wizard? OUCH!
In my doc I was going to great lengths on how to get around installers in 64 bit Windows but failed to explain how they actually work. Bare with me, I want to quickly fill in some details here to help people diagnosis "when things don't go to plan" with installers. (Skip the steps if it's TL;DR) I'll address your issue bellow.


Step 1 - is the archive of the program. This is most commonly done using PKZip. This is the final file the developer distributes. There is 3 versions this gets distributed. A raw archive of the setup directory, a self extracting archive, or a MSI file. There are a couple of self-extracting archive types out there but by a long shot PKWare's is the most popular. But there are others like RAR and go back far enough at one point I used UC's which is a total unknown by most people. It really depends on if the developer invested into a archiver at one point. Today thanks to Microsoft doing the investing for all Windows users for us the format is ZIP.
The process of EXE is not much different than the steps a user goes through when dealing with a zip. The self-extractor has the regular old ZIP file linked to the end of the program. It extracts the archive to a temp directory. Usually following the %temp% system variable token. In a CMD shell you can type 'cd %temp%' to look at the path. The self-extractor has to have write permission for this step to work, so usually you will see it going to your home directory. C:\users\username\AppData\Local\Temp is typical in Windows 10.

Step 2 - If this was a ZIP file you extracted in your own temp directory you made, it's at this point you run the setup.exe. In the self-extractor version, after it extracts the files in the temp directory it than runs the setup.exe in the temp directory it extracted to.

Step 3 - Setup.exe is probably not what you think it is. It's actually just a script shell that runs what is called a installer script. This script will contain information that needs to be obtained by the wizard and the basic defaults. It will contain the internal path of where to put files (the user is just specifying the root directory) and registry entries that need to be made. It can also contain of special things that need to be done when upgrading as well. So just to recap. setup.exe is the script shell and there is a script that it runs to do the rest. In InstallShield this is a INS file. So in the module portion where I'm talking about replacing setup.exe with a newer version. What is going on is InstallShield makes their installer shells for the lowest dominator, at the time of most of the WG Addon's Windows 16 bit was still pretty predominate. So the setup.exe is actually a Windows 16-bit application... which WILL NOT WORK in Windows 64 bit as that 16 bit API is gone. Not that it couldn't work and there are people out there that are working on making a Win16 API for Windows 64-bit but not necessary for that install process. Just replacing the 16 bit with a 32 bit shell that can read that versions script is all that is needed.

Step 4 - after setup.exe gathers it extracts files from archives (usually CAB files) to their specified locations and than writes registry entries. This is the part where you usually get the status bar telling you the percent done. After it finishes that's when you see the finish button in the Wizard.


This is a quick explanation of how installers work and hopefully helps people be able to fix them when they go amuck. In your case with WorldGroup installation you have a rolled up archive ZIP file and inside the zip file there is a INSTALL directory with the setup.exe. But when you run the setup.exe nothing happens. But you can see the icon in the taskbar and can see it in the task manager. If I had to guess it was being blocked by something. Maybe an anti-virus. I hate the AV answer when it's given to me for things, so I will keep going. :)
One cool thing, or at least I think so, is in Windows 10 is the preview application when you hover over the running application's icon in the task bar. If you hover over the installer icon there might be an error window being shown that is being blocked by the desktop. You will see in Windows sometimes especially when a UAC is involved that the application won't issue the window handle correctly to the visible desktop... but the preview can still let you glimpse the application. If still no-go the setup shell maybe struggling to find the location of the INS script or some sort of permission issue with reading. Which shouldn't happen when you run elevated, but for the sake of experimentation try extracting the files to a path off of the root directory. Don't use long file names. So like C:\WGINST. See if that works. Definitely do not attempt to run setup.exe from an archive that has not been extracted and your just browsing the archive. I know this can work sometimes but on large archives Windows will flush the temp almost immediately. It can cache the FAT into RAM and doesn't need the physical files anymore. If you go into the temp directory you can actually watch 7zip or MS's zip dump a temp directory and a second later deletes it. On any case it sounds like the installer is choking trying to read the INS script file.
After reading (and initial process) of the INS it should show the first page of the Wizard. Most of the time with corrupted INS it would return an error. Incompatible or corrupted executables, Windows would have thrown up a error dialog like it does for Win16 apps. So something is making it impossible for the setup.exe to read it's script file is my best guess. Either being blocked so file exists check but is abruptly denied when trying to read. OR the file exists using one check but when trying to open the long file path has something that the file read function doesn't like. OR the temp issue where it was there when you double clicked setup.exe but Windows being clever deleted it all in mid-operation because it assumed you were done by tasking away. This last one would be from not extracting the zip file before trying to run setup.exe.

couple things and i may be wrong..... check the compatibility of all the offline utils. i recall having to recompile wgsdraw, wgsmsx, and 1 other for someone YEARS ago
they may have been using 3.0 though so i may be wrong. i know fo a fact (again old-age mind might be setting in) but wgsmsx in the wgdev/bin folder does need to be recompiled.

Ramius1701 wrote:
> BadOPCode wrote:
> > Ramius1701 wrote:
> > > The installer appears to hang and not progress on Windows 10 20H2. I
> > > haven't found a work around on this yet, Compatibility doesn't resolve it
> > > either. Anyone else having issues or get it to work?
> >
> > No I have never had that happen to me. The version I'm running is 20H2 as well
> and
> > just recently did a install. What part of the installer is hanging? If it's
> the
> > file copying part you might want to try making a directory C:\WGSERV and set the
> > permissions to full with your account.
>
> At launch, I double click the installer and agree to run as administrator, get the
> hourglass, and then nothing. I even let it sit for an hour and eventually have to end
> the task on it. I have even disabled UAC still the same. I have tried 3.2 and 3.3.

http://arcticzone-hosting.net/worldgroup/distro/

grab 3.2 from there, run setup.exe this works i know because i have a 3rd test server running on windows 10 64 right now i use to test my sqlite stuff to make sure there is no conflicts or system hangups in newer systems.

in regards to running it in auto-mode......

if you do this you can get rid of the nasty console hangup that happens sometimes, and just use your java remote sysop control panel to manage the system.


ipaddress/remote or bbsdomain/remote

it is an older applet compiled in java 1.1.3 but it works.

daniel_spain wrote:
> couple things and i may be wrong..... check the compatibility of all the
> offline utils. i recall having to recompile wgsdraw, wgsmsx, and 1 other
> for someone YEARS ago
> they may have been using 3.0 though so i may be wrong. i know fo a fact
> (again old-age mind might be setting in) but wgsmsx in the wgdev/bin folder
> does need to be recompiled.

So far I haven't ran into any incompatibility issues. But but to be honest, on a fresh Windows 10 install on my BBS system I always install other software first that could be installing old 32 bit API's. Just went through a bunch of the installers and don't see any smoking gun of something installing missing API's. Closest I can say was in a MSI there was some MFC v9 (VC++ 2008) dll's being installed. Could always try the vcredist for 2005. Maybe the defacto MFC's on a Windows 10 install have compatibility issues with older software referencing the older versions of foundation classes. Like deprecation stubs in the new classes. That would explain no wizard window on the installer. Also why after I install this other software that contains older flavors of MFC it's working without a hitch. <shrug> Only way to find out for certain would be to drudge through the event logs. :( When I get a chance I will do a fresh install on my Windows 10 and try a WG 3.2 install on a clean Windows 10 64 bit install. Maybe I'm inadvertently missing a step of installing VCRedist before running the WG installer.

After doing some testing, I checked a few things in the task manager. After analyzing the chain on the details tab I found the installer is trying to run ntvdm (This would be the 64bit version). Once I end the task on ntvdm only the installer worked but presented a few errors. So it appears the installer is a 16bit installer masking as a 32bit for the install I have. I downloaded an updated installer which sorta resolves the issues but presents the error although it will install.