BlaZ wrote:
> Yes, getting "the other project" working as an internal emulator
> would be great. Since their project has the source code available, perhaps
> it wouldn't require their cooperation. I don't know how they've released
> it.
>
> At present, it's very unstable whenever I have tried it, and it seems they
> have decided to focus almost solely on support for running the 6.25
> versions of MajorMUD.
>
> BlaZ
ugh WHY! the 6.25 ver of major mud is ok but such a resource hog when i began rewriting
majormud one of the things i did was setup systems running the originals to be used
as references. the major bbs ver even under WG2 the HDD light never even blinks it is damned near solid.
the v3 one cleaned that up a bit but still has too much going on.
16bit Modules on 64bit Windows
-
daniel_spain
- Posts: 428
- Joined: Sun Aug 09, 2020 2:39 am
Re: 16bit Modules on 64bit Windows
Questman wrote:
> BlaZ wrote:
> > Yes, getting "the other project" working as an internal emulator
> > would be great. Since their project has the source code available, perhaps
> > it wouldn't require their cooperation. I don't know how they've released
> > it.
> >
> > At present, it's very unstable whenever I have tried it, and it seems they
> > have decided to focus almost solely on support for running the 6.25
> > versions of MajorMUD.
> >
> > BlaZ
>
> A lot of what they focus on -- and this is my observation, not a fact -- is running
> modules without their activation codes even if the module is generally available.
> MajorMUD probably isn't in that category any longer, though.
>
> I'd prefer their cooperation.
not even sure anyone from the bbs-era is even at metro anymore. i wrote them countless times when i was going to begin my own "majormud 2.0" as a fun project
not anything meant to be disrespectful and even if they wanted some form of compensation just let me know and no one ever writes back.
at least for the years i was writing Vircomm someone would respond and straight up say nobody there dealt with the major bbs stuff any longer, with metro
its just dead silence.
so out of respect yeah would love for them just to at least say go ahead, but i am sure they are long gone.
> BlaZ wrote:
> > Yes, getting "the other project" working as an internal emulator
> > would be great. Since their project has the source code available, perhaps
> > it wouldn't require their cooperation. I don't know how they've released
> > it.
> >
> > At present, it's very unstable whenever I have tried it, and it seems they
> > have decided to focus almost solely on support for running the 6.25
> > versions of MajorMUD.
> >
> > BlaZ
>
> A lot of what they focus on -- and this is my observation, not a fact -- is running
> modules without their activation codes even if the module is generally available.
> MajorMUD probably isn't in that category any longer, though.
>
> I'd prefer their cooperation.
not even sure anyone from the bbs-era is even at metro anymore. i wrote them countless times when i was going to begin my own "majormud 2.0" as a fun project
not anything meant to be disrespectful and even if they wanted some form of compensation just let me know and no one ever writes back.
at least for the years i was writing Vircomm someone would respond and straight up say nobody there dealt with the major bbs stuff any longer, with metro
its just dead silence.
so out of respect yeah would love for them just to at least say go ahead, but i am sure they are long gone.
-
daniel_spain
- Posts: 428
- Joined: Sun Aug 09, 2020 2:39 am
Re: 16bit Modules on 64bit Windows
enusbaum wrote:
> Hey Folks!
>
> MBBSEmu is open sourced under the permissive MIT license, so feel free to
> submit a PR or fork and do with what you please! :)
>
> As Duckula said, we've been in discussion on ways we could integrate the
> emulator more closely with the v10 (and beyond) package then the currently
> available Rlogin functionality. It's not an insignificant effort as
> events+memory would need to be shared between the two processes, but I
> think the end result could be a new framework in which modules could be
> developed. A more modern SDK if you will, designed for a cross-platform
> compatible IPC.
>
> Our goal with the emulation project is to allow easy access to the older,
> 16-bit modules. I never viewed MBBSEmu as any form of competition with v10.
> If anything I think they complement each other and together give sysops
> access to run essentially *EVERY* module released for MBBS/WG, not just
> those ported to WG3NT.
first off i am noone to throw stones what you are doing is well beyond my comprehension.
im a video game developer, give me unity or unreal and watch me work im a scriptologist
i can do some pretty nifty stuff. that being said i do the bbs stuff as nostalgia and fun
my tele-arena platinum is practically a 3d mmo in text form with all this said i think
your program would integrate fairly well using my v3 rlogin client.
only problem is wg will not rlogin to another system on the same ip as the wg server.
it could be fixed i just never tinkered with it. i did work with synchronet bbs community
to fully integrate door servers seemlessly you never even know you left the system
with the issue that you could not be paged ot page back. with that said using v10 and
mbbsemu if you incorporated something on the rlogin end like synchronet did where it would
detect an internal code "in your case a module page name id" my client replaces the
string "vt100/9600" with "xtrn=(text name of internal code id)" ie "xtrn=LORD"
and when synchronet detects that it auto connects and drops you in the door game with the internal
code after xtrn= so in your case "module=TA56" would drop me right in the tele-arena 5.6
module and when i hit x to leave it disconnects me and im right back there at the v10
menu. this way you could directly enter mbbsemu games from a v10 system seemlessly.
and i am sure between Rick and Duck they could fix that old nt bug with rlogin but until
then the above will work. it works very well with synchronet bbs as a door server i even
used it to offer message servers as well to offer FTN networks.
> Hey Folks!
>
> MBBSEmu is open sourced under the permissive MIT license, so feel free to
> submit a PR or fork and do with what you please! :)
>
> As Duckula said, we've been in discussion on ways we could integrate the
> emulator more closely with the v10 (and beyond) package then the currently
> available Rlogin functionality. It's not an insignificant effort as
> events+memory would need to be shared between the two processes, but I
> think the end result could be a new framework in which modules could be
> developed. A more modern SDK if you will, designed for a cross-platform
> compatible IPC.
>
> Our goal with the emulation project is to allow easy access to the older,
> 16-bit modules. I never viewed MBBSEmu as any form of competition with v10.
> If anything I think they complement each other and together give sysops
> access to run essentially *EVERY* module released for MBBS/WG, not just
> those ported to WG3NT.
first off i am noone to throw stones what you are doing is well beyond my comprehension.
im a video game developer, give me unity or unreal and watch me work im a scriptologist
i can do some pretty nifty stuff. that being said i do the bbs stuff as nostalgia and fun
my tele-arena platinum is practically a 3d mmo in text form with all this said i think
your program would integrate fairly well using my v3 rlogin client.
only problem is wg will not rlogin to another system on the same ip as the wg server.
it could be fixed i just never tinkered with it. i did work with synchronet bbs community
to fully integrate door servers seemlessly you never even know you left the system
with the issue that you could not be paged ot page back. with that said using v10 and
mbbsemu if you incorporated something on the rlogin end like synchronet did where it would
detect an internal code "in your case a module page name id" my client replaces the
string "vt100/9600" with "xtrn=(text name of internal code id)" ie "xtrn=LORD"
and when synchronet detects that it auto connects and drops you in the door game with the internal
code after xtrn= so in your case "module=TA56" would drop me right in the tele-arena 5.6
module and when i hit x to leave it disconnects me and im right back there at the v10
menu. this way you could directly enter mbbsemu games from a v10 system seemlessly.
and i am sure between Rick and Duck they could fix that old nt bug with rlogin but until
then the above will work. it works very well with synchronet bbs as a door server i even
used it to offer message servers as well to offer FTN networks.
Re: 16bit Modules on 64bit Windows
daniel_spain wrote:
> your program would integrate fairly well using my v3 rlogin client.
> only problem is wg will not rlogin to another system on the same ip as the wg server.
> it could be fixed i just never tinkered with it. i did work with synchronet bbs
> community
> to fully integrate door servers seemlessly you never even know you left the system
> with the issue that you could not be paged ot page back. with that said using v10 and
> mbbsemu if you incorporated something on the rlogin end like synchronet did where it
> would
> detect an internal code "in your case a module page name id" my client
> replaces the
> string "vt100/9600" with "xtrn=(text name of internal code id)"
> ie "xtrn=LORD"
> and when synchronet detects that it auto connects and drops you in the door game with
> the internal
> code after xtrn= so in your case "module=TA56" would drop me right in the
> tele-arena 5.6
> module and when i hit x to leave it disconnects me and im right back there at the v10
> menu. this way you could directly enter mbbsemu games from a v10 system seemlessly.
> and i am sure between Rick and Duck they could fix that old nt bug with rlogin but
> until
> then the above will work. it works very well with synchronet bbs as a door server i
> even
> used it to offer message servers as well to offer FTN networks.
The last time I looked at mbbsemu, it solved the direct-to-module thing by simply assigning a separate rlogin port to each module you loaded. It was pretty seamless.
> your program would integrate fairly well using my v3 rlogin client.
> only problem is wg will not rlogin to another system on the same ip as the wg server.
> it could be fixed i just never tinkered with it. i did work with synchronet bbs
> community
> to fully integrate door servers seemlessly you never even know you left the system
> with the issue that you could not be paged ot page back. with that said using v10 and
> mbbsemu if you incorporated something on the rlogin end like synchronet did where it
> would
> detect an internal code "in your case a module page name id" my client
> replaces the
> string "vt100/9600" with "xtrn=(text name of internal code id)"
> ie "xtrn=LORD"
> and when synchronet detects that it auto connects and drops you in the door game with
> the internal
> code after xtrn= so in your case "module=TA56" would drop me right in the
> tele-arena 5.6
> module and when i hit x to leave it disconnects me and im right back there at the v10
> menu. this way you could directly enter mbbsemu games from a v10 system seemlessly.
> and i am sure between Rick and Duck they could fix that old nt bug with rlogin but
> until
> then the above will work. it works very well with synchronet bbs as a door server i
> even
> used it to offer message servers as well to offer FTN networks.
The last time I looked at mbbsemu, it solved the direct-to-module thing by simply assigning a separate rlogin port to each module you loaded. It was pretty seamless.
Re: 16bit Modules on 64bit Windows
BlaZ wrote:
> The last time I looked at mbbsemu, it solved the direct-to-module thing by simply
> assigning a separate rlogin port to each module you loaded. It was pretty seamless.
Totally agree with you and Dan re:Rlogin as a potential solution.
Honestly, Rlogin checks a lot of boxes but still leaves some issues outstanding depending on the module. Our current implementation of the Rlogin daemon constructs "fake" USER and USRACC structs in memory for that channel based on essentially only the data available via the Rlogin spec, which right now is basically just username and baud (depending on implementation). Some modules, for various reasons, make use of other fields on these structs (address, gender, etc.) -- so following the Rlogin spec would result in these modules acting a little weird.
In talking with Duckula, I'm thinking a common API using something like protobuf could be easy to implement and powerful in that it'd allow a shared .proto definition file for new modules to be coded against in any language versus the current C++ API. This could allow bi-directional updates of these objects in memory, and if we wanted to get fancy even events around VDA updates on a channel if a module makes use of that.
A couple huge benefits from this would be:
- Language Agnostic "SDK" (just generate your interface using the shared .proto)
- Versioning the API, allowing for easy updates to v10 without the hand wringing over backwards compatibility (protobuf handles API versioning)
- Supporting Cross-platform modules and interaction
The long game here is that it the core v10 platform handles all BBS functionality it currently does, new modules can be easily written in any language for any platform, and MBBSEmu can handle the abstraction and execution of 16-bit (and potentially the 32-bit WG3NT) modules on any platform (essentially becoming a module wrapper).
> The last time I looked at mbbsemu, it solved the direct-to-module thing by simply
> assigning a separate rlogin port to each module you loaded. It was pretty seamless.
Totally agree with you and Dan re:Rlogin as a potential solution.
Honestly, Rlogin checks a lot of boxes but still leaves some issues outstanding depending on the module. Our current implementation of the Rlogin daemon constructs "fake" USER and USRACC structs in memory for that channel based on essentially only the data available via the Rlogin spec, which right now is basically just username and baud (depending on implementation). Some modules, for various reasons, make use of other fields on these structs (address, gender, etc.) -- so following the Rlogin spec would result in these modules acting a little weird.
In talking with Duckula, I'm thinking a common API using something like protobuf could be easy to implement and powerful in that it'd allow a shared .proto definition file for new modules to be coded against in any language versus the current C++ API. This could allow bi-directional updates of these objects in memory, and if we wanted to get fancy even events around VDA updates on a channel if a module makes use of that.
A couple huge benefits from this would be:
- Language Agnostic "SDK" (just generate your interface using the shared .proto)
- Versioning the API, allowing for easy updates to v10 without the hand wringing over backwards compatibility (protobuf handles API versioning)
- Supporting Cross-platform modules and interaction
The long game here is that it the core v10 platform handles all BBS functionality it currently does, new modules can be easily written in any language for any platform, and MBBSEmu can handle the abstraction and execution of 16-bit (and potentially the 32-bit WG3NT) modules on any platform (essentially becoming a module wrapper).
Developer, Reverse Engineer, MBBS/WG Enthusiast
Maintainer of The MajorBBS Emulation Project (MBBSEmu)
Maintainer of The MajorBBS Emulation Project (MBBSEmu)
-
daniel_spain
- Posts: 428
- Joined: Sun Aug 09, 2020 2:39 am
Re: 16bit Modules on 64bit Windows
BlaZ wrote:
> daniel_spain wrote:
>
> > your program would integrate fairly well using my v3 rlogin client.
> > only problem is wg will not rlogin to another system on the same ip as the wg
> server.
> > it could be fixed i just never tinkered with it. i did work with synchronet bbs
> > community
> > to fully integrate door servers seemlessly you never even know you left the
> system
> > with the issue that you could not be paged ot page back. with that said using
> v10 and
> > mbbsemu if you incorporated something on the rlogin end like synchronet did
> where it
> > would
> > detect an internal code "in your case a module page name id" my client
> > replaces the
> > string "vt100/9600" with "xtrn=(text name of internal code
> id)"
> > ie "xtrn=LORD"
> > and when synchronet detects that it auto connects and drops you in the door game
> with
> > the internal
> > code after xtrn= so in your case "module=TA56" would drop me right in
> the
> > tele-arena 5.6
> > module and when i hit x to leave it disconnects me and im right back there at
> the v10
> > menu. this way you could directly enter mbbsemu games from a v10 system
> seemlessly.
> > and i am sure between Rick and Duck they could fix that old nt bug with rlogin
> but
> > until
> > then the above will work. it works very well with synchronet bbs as a door
> server i
> > even
> > used it to offer message servers as well to offer FTN networks.
>
>
> The last time I looked at mbbsemu, it solved the direct-to-module thing by simply
> assigning a separate rlogin port to each module you loaded. It was pretty seamless.
aaah and using my -p command you could do just that.... nice.
> daniel_spain wrote:
>
> > your program would integrate fairly well using my v3 rlogin client.
> > only problem is wg will not rlogin to another system on the same ip as the wg
> server.
> > it could be fixed i just never tinkered with it. i did work with synchronet bbs
> > community
> > to fully integrate door servers seemlessly you never even know you left the
> system
> > with the issue that you could not be paged ot page back. with that said using
> v10 and
> > mbbsemu if you incorporated something on the rlogin end like synchronet did
> where it
> > would
> > detect an internal code "in your case a module page name id" my client
> > replaces the
> > string "vt100/9600" with "xtrn=(text name of internal code
> id)"
> > ie "xtrn=LORD"
> > and when synchronet detects that it auto connects and drops you in the door game
> with
> > the internal
> > code after xtrn= so in your case "module=TA56" would drop me right in
> the
> > tele-arena 5.6
> > module and when i hit x to leave it disconnects me and im right back there at
> the v10
> > menu. this way you could directly enter mbbsemu games from a v10 system
> seemlessly.
> > and i am sure between Rick and Duck they could fix that old nt bug with rlogin
> but
> > until
> > then the above will work. it works very well with synchronet bbs as a door
> server i
> > even
> > used it to offer message servers as well to offer FTN networks.
>
>
> The last time I looked at mbbsemu, it solved the direct-to-module thing by simply
> assigning a separate rlogin port to each module you loaded. It was pretty seamless.
aaah and using my -p command you could do just that.... nice.
-
daniel_spain
- Posts: 428
- Joined: Sun Aug 09, 2020 2:39 am
Re: 16bit Modules on 64bit Windows
enusbaum wrote:
> BlaZ wrote:
> > The last time I looked at mbbsemu, it solved the direct-to-module thing by
> simply
> > assigning a separate rlogin port to each module you loaded. It was pretty
> seamless.
>
> Totally agree with you and Dan re:Rlogin as a potential solution.
>
> Honestly, Rlogin checks a lot of boxes but still leaves some issues outstanding
> depending on the module. Our current implementation of the Rlogin daemon constructs
> "fake" USER and USRACC structs in memory for that channel based on
> essentially only the data available via the Rlogin spec, which right now is basically
> just username and baud (depending on implementation). Some modules, for various
> reasons, make use of other fields on these structs (address, gender, etc.) -- so
> following the Rlogin spec would result in these modules acting a little weird.
>
> In talking with Duckula, I'm thinking a common API using something like protobuf
> could be easy to implement and powerful in that it'd allow a shared .proto definition
> file for new modules to be coded against in any language versus the current C++ API.
> This could allow bi-directional updates of these objects in memory, and if we wanted
> to get fancy even events around VDA updates on a channel if a module makes use of
> that.
>
> A couple huge benefits from this would be:
> - Language Agnostic "SDK" (just generate your interface using the shared
> .proto)
> - Versioning the API, allowing for easy updates to v10 without the hand wringing over
> backwards compatibility (protobuf handles API versioning)
> - Supporting Cross-platform modules and interaction
>
> The long game here is that it the core v10 platform handles all BBS functionality it
> currently does, new modules can be easily written in any language for any platform,
> and MBBSEmu can handle the abstraction and execution of 16-bit (and potentially the
> 32-bit WG3NT) modules on any platform (essentially becoming a module wrapper).
essentially using your mbbsemu rick parrish's doorsrv and my galrlgn you could put up a nifty entertainment system offering the new addon modules, the classic door games, and the classic major bbs modules.
and of course if you're into ftn networks you could use synchronet and my command shell WGV3 and offer fidonet, and whatever else all seemless. nifty.
> BlaZ wrote:
> > The last time I looked at mbbsemu, it solved the direct-to-module thing by
> simply
> > assigning a separate rlogin port to each module you loaded. It was pretty
> seamless.
>
> Totally agree with you and Dan re:Rlogin as a potential solution.
>
> Honestly, Rlogin checks a lot of boxes but still leaves some issues outstanding
> depending on the module. Our current implementation of the Rlogin daemon constructs
> "fake" USER and USRACC structs in memory for that channel based on
> essentially only the data available via the Rlogin spec, which right now is basically
> just username and baud (depending on implementation). Some modules, for various
> reasons, make use of other fields on these structs (address, gender, etc.) -- so
> following the Rlogin spec would result in these modules acting a little weird.
>
> In talking with Duckula, I'm thinking a common API using something like protobuf
> could be easy to implement and powerful in that it'd allow a shared .proto definition
> file for new modules to be coded against in any language versus the current C++ API.
> This could allow bi-directional updates of these objects in memory, and if we wanted
> to get fancy even events around VDA updates on a channel if a module makes use of
> that.
>
> A couple huge benefits from this would be:
> - Language Agnostic "SDK" (just generate your interface using the shared
> .proto)
> - Versioning the API, allowing for easy updates to v10 without the hand wringing over
> backwards compatibility (protobuf handles API versioning)
> - Supporting Cross-platform modules and interaction
>
> The long game here is that it the core v10 platform handles all BBS functionality it
> currently does, new modules can be easily written in any language for any platform,
> and MBBSEmu can handle the abstraction and execution of 16-bit (and potentially the
> 32-bit WG3NT) modules on any platform (essentially becoming a module wrapper).
essentially using your mbbsemu rick parrish's doorsrv and my galrlgn you could put up a nifty entertainment system offering the new addon modules, the classic door games, and the classic major bbs modules.
and of course if you're into ftn networks you could use synchronet and my command shell WGV3 and offer fidonet, and whatever else all seemless. nifty.