The Major BBS Forums

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.


I'm having trouble with the Menu Tree Editor (WGSRUNMT.EXE) on Windows 10. I'm running the 32-bit version. The console window goes all screwy whenever I use the Menu Tree Editor. I've tried all kinds of changes in the console window settings (including checking "Use Legacy Console") but nothing seems to fix this issue. Have you had this problem? Have you found a solution?

BlaZ

> I'm having trouble with the Menu Tree Editor (WGSRUNMT.EXE) on Windows 10. I'm
> running the 32-bit version. The console window goes all screwy whenever I use the
> Menu Tree Editor. I've tried all kinds of changes in the console window settings
> (including checking "Use Legacy Console") but nothing seems to fix this
> issue. Have you had this problem? Have you found a solution?
>
> BlaZ

The most common screwy issue is when the console isn't locked to 80 columns. It has to be locked to 80 columns because these older applications are expecting the screen wrap at 80 columns.
So first thing, you have already done. You have to enable legacy mode. This takes the console out of unicode mode and puts it into CP437 8-bit. Next click the "Layout" tab and set the buffer and the window size to 80x25. The buffer will remove the scrollbars when it's set to the same as the window size. The window size... well like I was saying earlier the most important thing is 80 columns. The apps are all 25 lines so I go ahead and set it that way. I don't think anything uses any kind of scrolling for positioning.

The other screwy issue... buuuut I kind of like it is the colors with a few adjustments to the color palette. The current colors for black; blue; green; cyan; red; magenta; yellow are not even close to the old EGA standard. If your the methodical type... here is the original color palette
Black #000000 - R:0 G:0 B:0
Blue #0000AA - R:0 G:0 B:170
Green #00AA00 - R:0 G:170 B:0
Cyan #00AAAA - R:0 G:170 B:170
Red #AA0000 - R:170 G:0 B:0
Magenta #AA00AA - R:170 G:0 B:170
Brown #AA5500 - R:170 G:85 B:0
Light Gray #AAAAAA - R:170 G:170 B:170
Dark Gray #555555 - R:85 G:85 B:85
Light Blue #5555FF - R:85 G:85 B:255
Light Green #55FF55 - R:85 G:255 B:85
Light Cyan #55FFFF - R:85 G:255 B:255
Light Red #FF5555 - R:255 G:85 B:85
Light Magenta #FF55FF - R:255 G:85 B:255
Light Yellow #FFFF55 - R:255 G:255 B:85
White #FFFFFF - R:255 G:255 B:255

To edit the colors click the "colors" tab and than you have to select each color and than enter the above values in for that color. The order in the palette left to right is in order to the above from top to bottom.

So that will put the color palette back into boring old EGA colors. (I personally just like to tweak the default windows palette but it's all up to opinion.)

Thanks so much for your help with this! I've got another issue that has popped up now that I'm using Windows 10, but I'm not completely sure it's not just because of my current temporary setup while I'm getting my Linux server ready. So I'll wait and address it later if it persists.


***UPDATE: After moving my Win10 VM to the Linux server, my weird lockups have stopped. I believe it was related to running it on a WiFi connection. Anyway, please disregard the above, and thanks again for your help with the console.

BlaZ wrote:
> Thanks so much for your help with this! I've got another issue that has
> popped up now that I'm using Windows 10, but I'm not completely sure it's
> not just because of my current temporary setup while I'm getting my Linux
> server ready. So I'll wait and address it later if it persists.
>
>
> ***UPDATE: After moving my Win10 VM to the Linux server, my weird lockups
> have stopped. I believe it was related to running it on a WiFi connection.
> Anyway, please disregard the above, and thanks again for your help with
> the console.

occasionally it does lockup sometimes though i havent see it on my main bbs in a while but other times i can get 2 a day.
i isolated it to 3.30 and increasing the max files/handles/locks did help out but still happens very seldomly.

The console freeze bug was part of the 3.3 release I believe. That was a very rushed build. 3.2 is far more stable and as such is the basis for v10.

There is an installer hang on the latest win10 but it doesn't stop the install from working.

Questman wrote:
> The console freeze bug was part of the 3.3 release I believe. That was a
> very rushed build. 3.2 is far more stable and as such is the basis for
> v10.
>
> There is an installer hang on the latest win10 but it doesn't stop the
> install from working.

always felt that..... there are more issues too that felt overlooked. this is why I run my bbs on 3.12 and dev env on 3.2
the 3.12/3.20 seem to have an issue every 2 months or so where cleanup hangs but its a non issue really.

Totally agree. I think people will be pleased with v10. It will install clean, it will run clean. It will be 32-bit, so the existing 3.x modules will run fine.

Maybe we can convince the MBBSEMU people to stop competing with the project and join us instead, creating a module that can plug-in and execute the DOS modules... that way, when we build a 64-bit release we can keep backward compatibility of modules in a VDM rather than have to run separate systems or programs like the old DMA type concept.

I think that C# compatibility is something we're open to but I'll let Duckula opine on that. Certainly later capabilities leveraged C++ in Worldgroup 3. Poorly, so it's difficult to upgrade ActiveHTML.

But hey.

C# is definitely something I would like to see supported. There has even been a Proof of Concept done for this that was functional.

Questman wrote:
> Totally agree. I think people will be pleased with v10. It will install
> clean, it will run clean. It will be 32-bit, so the existing 3.x modules
> will run fine.
>
> Maybe we can convince the MBBSEMU people to stop competing with the project
> and join us instead, creating a module that can plug-in and execute the DOS
> modules... that way, when we build a 64-bit release we can keep backward
> compatibility of modules in a VDM rather than have to run separate systems
> or programs like the old DMA type concept.
>
> I think that C# compatibility is something we're open to but I'll let
> Duckula opine on that. Certainly later capabilities leveraged C++ in
> Worldgroup 3. Poorly, so it's difficult to upgrade ActiveHTML.
>
> But hey.

Isn't the project going to be 64bit and cross platform? I'm confused on why you would build something "new" in 32bit at all that only runs on Windows?

The long term goal is 64bit but given all the modules for worldgroup including those from 3rd parties were 32bit we can't simply dump 32bit.

A lot of the source code for those modules are no longer available so they can't be updated.