I have read a few sysops who claim that setting up a DOS door with Synchronet is easy because you don't need to set up a fossil driver. However, I am reading the how-to on the wiki and one point it hits upon pretty strongly is that (1) you need a BAT file called emusetup.bat, and (2) the one thing it is required to do is to load a fossil. It does not sound so easy. :)
OK, so who is right? Also, the fossil driver I have used in the past requires that the COM port and baud rate be included on the command line. For Synchronet, if the fossil driver is required, what should those values be?
I have read a few sysops who claim that setting up a DOS door with Synchronet is easy because you don't need to set up a fossil driver. However, I am reading the how-to on the wiki and one point it hits upon pretty strongly is that (1) you need a BAT file called emusetup.bat, and (2) the one thing it is required to do is to load a fossil. It does not sound so easy. :)
OK, so who is right? Also, the fossil driver I have used in the past requires that the COM port and baud rate be included on the command line. For Synchronet, if the fossil driver is required, what should those values be?
Also, it mentions the default drive letter specs. I assumed that meant that emusetup.bat (or something else SBBS does) replaces your own autoexec.bat. However, later it mentions that the autoexec.bat must be included in any help requests. I am a frequent DOSemu user (probably use it as much as the native cli) and have several drives mapped which I am pretty sure are going to contradict with the SBBS mappings. So, do the SBBS mappings override those, or am I courting potential headaches there?
I have read a few sysops who claim that setting up a DOS door with Synchronet is easy because you don't need to set up a fossil driver. However, I am reading the how-to on the wiki and one point it hits upon pretty strongly is that (1) you need a BAT file called emusetup.bat, and
(2) the one thing it is required to do is to load a fossil. It does not sound so easy. :)
OK, so who is right?
Also, the fossil driver I have used in the past
requires that the COM port and baud rate be included on the command line. For Synchronet, if the fossil driver is required, what should those values be?
Also, it mentions the default drive letter specs. I assumed that meant
that emusetup.bat (or something else SBBS does) replaces your own autoexec.bat. However, later it mentions that the autoexec.bat must be included in any help requests. I am a frequent DOSemu user (probably use
it as much as the native cli) and have several drives mapped which I am pretty sure are going to contradict with the SBBS mappings. So, do the
SBBS mappings override those, or am I courting potential headaches there?
Re: DOS Doors?
By: Dumas Walker to ALL on Wed Sep 18 2019 04:46 pm
I have read a few sysops who claim that setting up a DOS door with Synchronet is easy because you don't need to set up a fossil driver. However, I am reading the how-to on the wiki and one point it hits upon pretty strongly is that (1) you need a BAT file called emusetup.bat, and (2) the one thing it is required to do is to load a fossil. It does not sound so easy. :)
OK, so who is right? Also, the fossil driver I have used in the past requires that the COM port and baud rate be included on the command line. For Synchronet, if the fossil driver is required, what should those values be?
That's not quite right.. You don't actually need to specify any FOSSIL driver in the command line for the door - Synchronet loads a FOSSIL driver automatically. And in most cases, you don't even need a batch file - In the door configuration in SCFG, you can put in the door's .EXE file and command line directly.
Just a note here, most dos doors, if written correctly, will work with Synchronet. It's the odd ones that will cause a snag for you.
*the more you know*
I have read a few sysops who claim that setting up a DOS door with Synchronet is easy because you don't need to set up a fossil driver. However, I am reading the how-to on the wiki and one point it hits upon pretty strongly is that (1) you need a BAT file called emusetup.bat, and (2) the one thing it is required to do is to load a fossil. It does not sound so easy. :)
OK, so who is right? Also, the fossil driver I have used in the past requires that the COM port and baud rate be included on the command line. For Synchronet, if the fossil driver is required, what should those values be?
Also, it mentions the default drive letter specs. I assumed that
meant that emusetup.bat (or something else SBBS does) replaces your
own autoexec.bat.
However, later it mentions that the autoexec.bat must be included in
any help requests. I am a frequent DOSemu user (probably use it as
much as the native cli) and have several drives mapped which I am
pretty sure are going to contradict with the SBBS mappings. So, do
the SBBS mappings override those, or am I courting potential headaches there?
Just a note here, most dos doors, if written correctly, will work with Synchronet. It’s the odd ones that will cause a snag for you.
While that is true for Windows, I suspect the OP is running Linux (though he didn't clarify) - DOSemu kind of implies that.
Just a note here, most dos doors, if written correctly, will work with Synchronet. It's the odd ones that will cause a snag for you.
Re: DOS Doors?
By: The Millionaire to Digital Man on Wed Sep 18 2019 08:09 pm
This is a random fact out of nowhere. And I imagine Digital Man is well aware of that..
Nightfox
---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
This is a random fact out of nowhere. And I imagine Digital Man is well
A random fact? Try it's more like a fact, period. I've only had problems
the time otherwise all the other doors worked smoothly. So I think my case in
point here is well taken and it speaks for itself well documented and backed up
thoroughly and truthfully.
This is a random fact out of nowhere. And I imagine Digital Man is
well aware of that..
A random fact? Try it's more like a fact, period. I've only had problems setting up one door for my bbs before and that was Nuke Wars because it
I think it is exceedingly probable that should I prepare a statement containing a generous quantity of superfluous words and, dare I say, amateurish attempts at lawyerly phrasing, that my case in point here should therefore indubitably be t aken with much greater seriousness
than had I shat out a sequence of words which actually communicated a coherent point of some sort - however if perhaps I cons truct a
paragraph of sufficient length the reader will become convinced of my in telligence and simply capitulate and concede the point to me forthwith.
I just use the built in fossil.com with no parameters. I never had to modify ything else that I can think of, it just worked "right out of the box".
- what door you're trying to run (e.g. native doors never use a FOSSIL)
- what operating system your BBS is running on (i.e. the Windows versions of S
chronet include a "built-in" FOSSIL/virtual-UART device driver)
Again, it depends, but likely COM1, 38400 should work just fine.
I am not a DOSemu user. Perhaps you should mention DOSemu in the subject of yo
help request to attract the attention of DOSemu users/sysops. The information
have on using Linux-DOSEMU with Synchronet is here: http://wiki.synchro.net/howto:dosemu
If you have a specific problem, please post the complete details of the proble
you're having and likely someone with the relevant experience can help.
That's not quite right.. You don't actually need to specify any FOSSIL driver
n the command line for the door - Synchronet loads a FOSSIL driver automatical
. And in most cases, you don't even need a batch file - In the door configurat
n in SCFG, you can put in the door's .EXE file and command line directly.
mark lewis wrote to Dumas Walker <=-
Nightfox wrote to The Millionaire <=-
Re: DOS Doors?
By: The Millionaire to Digital Man on Wed Sep 18 2019 08:09 pm
Just a note here, most dos doors, if written correctly, will work with Synchronet. It's the odd ones that will cause a snag for you.
This is a random fact out of nowhere. And I imagine Digital Man
is well aware of that..
The Millionaire wrote to Nightfox <=-
Re: DOS Doors?
By: The Millionaire to Digital Man on Wed Sep 18 2019 08:09 pm
This is a random fact out of nowhere. And I imagine Digital Man is well aware of that..
A random fact? Try it's more like a fact, period. I've only had
problems setting up one door for my bbs before and that was Nuke
Wars because it was always asking for com 3 and I didn't know how
to troubleshoot the problem at the time otherwise all the other
doors worked smoothly. So I think my case in point here is well
taken and it speaks for itself well documented and backed up
thoroughly and truthfully.
Is that with linux or windows? I may not have been specific enough.
That's not quite right.. You don't actually need to specify any
FOSSIL driver n the command line for the door - Synchronet loads a
FOSSIL driver automatical . And in most cases, you don't even need a
batch file - In the door configurat n in SCFG, you can put in the
door's .EXE file and command line directly.
Is that with linux or windows? I may not have been specific enough.
Did you ever set up doors under Linux or Win64?
He's not saying you're wrong. He's saying that your factoid was posted "random
y" - out of nowhere, with no context, and to no apparent purpose.
You started a thread and told DM that "most games are easy to set up except for
the ones that aren't". You didn't ask a question. You didn't name a particular
game. You didn't tell DM anything he doesn't already know. This is harmless, >ut NF's criticism is valid.
Nightfox wrote to Gamgee <=-
Re: Re: DOS Doors?
By: Gamgee to The Millionaire on Thu Sep 19 2019 05:08 pm
Did you ever set up doors under Linux or Win64?
I wonder how easy it is to set up DOS doors in Win64, or if it's
even possible.. There have been discussions about that on
Dove-Net, and I seem to remember reading that even if you try to
use DOSBox or similar in Win64, there's still something missing
where DOS doors don't fully work correctly in Win64. I don't
remember what it was, maybe the COM port or FOSSIL driver doesn't communicate correctly with the DOS emulator, or something? Or
maybe I'm remembering wrong..
On 09-20-19 11:57, Dan Clough wrote to Nightfox <=-
Yes, I think you're right. I believe it's something in the Win64
"kernel" that doesn't support DOS-type stuff at all (NTVDM is
lacking, whatever that is). Not super familiar with Windows
stuff, myself.
apps. Back when the AMD64 instruction set first appeared, AMD didn't implement virtual 8086 mode, when the proceddor was running in 64 bit mode. This meant that DOS apps couldn't be run natively when the processor was running a 64 bit OS, like they could when in 32 bit mode (because virtual 8086 mode has been around since the 80386). However, the hardware has evolved and since the advent of hardware virtualisation, virtual 8086 mode is essentially now available when in 64 bit mode.
Yes, I think you're right. I believe it's something in the Win64
"kernel" that doesn't support DOS-type stuff at all (NTVDM is
lacking, whatever that is). Not super familiar with Windows
stuff, myself.
I have read a few sysops who claim that setting up a DOS door with DW>Synchronet is easy because you don't need to set up a fossil driver. DW>However, I am reading the how-to on the wiki and one point it hits upon DW>pretty strongly is that (1) you need a BAT file called emusetup.bat, and DW>(2) the one thing it is required to do is to load a fossil. It does not DW>sound so easy. :)
NTVDM - "NT Virtual DOS Machine", which is the part of Win32 that runs DOS apps
Back in the Windows 2000 days, there was an OS2VDM that let Windows run OS/2 console apps. I loved being able to run Qedit and OS/2 versions of my BBS utlities on the BBS. They dropped support for OS/2 apps in Windows XP, although there were unsubstantiated rumors you could add it back in somehow.
Thanks, now I have some interesting reading to do. :)
That's not quite right.. You don't actually need to specify any
FOSSIL driver n the command line for the door - Synchronet loads a
FOSSIL driver automatical . And in most cases, you don't even need a
batch file - In the door configurat n in SCFG, you can put in the
door's .EXE file and command line directly.
Is that with linux or windows? I may not have been specific enough.
Windows. If you specified Linux, I probably missed that, and I
apologize. I'm not as familiar with setting up DOS doors with
Synchronet in Linux.
On 09-20-19 12:11, Digital Man wrote to Tony Langdon <=-
Re: Re: DOS Doors?
By: Tony Langdon to Dan Clough on Sat Sep 21 2019 04:35 am
apps. Back when the AMD64 instruction set first appeared, AMD didn't implement virtual 8086 mode, when the proceddor was running in 64 bit mode. This meant that DOS apps couldn't be run natively when the processor was running a 64 bit OS, like they could when in 32 bit mode (because virtual 8086 mode has been around since the 80386). However, the hardware has evolved and since the advent of hardware virtualisation, virtual 8086 mode is essentially now available when in 64 bit mode.
Not according to https://en.wikipedia.org/wiki/X86-64#AMD64
On 09-20-19 16:37, poindexter FORTRAN wrote to Tony Langdon <=-
Re: Re: DOS Doors?
By: Tony Langdon to Dan Clough on Sat Sep 21 2019 04:35 am
NTVDM - "NT Virtual DOS Machine", which is the part of Win32 that runs DOS apps
Back in the Windows 2000 days, there was an OS2VDM that let Windows run OS/2 console apps. I loved being able to run Qedit and OS/2 versions of
my BBS utlities on the BBS. They dropped support for OS/2 apps in
Windows XP, although there were unsubstantiated rumors you could add it back in somehow.
On 09-20-19 12:11, Digital Man wrote to Tony Langdon <=-
Re: Re: DOS Doors?
By: Tony Langdon to Dan Clough on Sat Sep 21 2019 04:35 am
apps. Back when the AMD64 instruction set first appeared, AMD didn't implement virtual 8086 mode, when the proceddor was running in 64 bit mode. This meant that DOS apps couldn't be run natively when the processor was running a 64 bit OS, like they could when in 32 bit mode (because virtual 8086 mode has been around since the 80386). However, the hardware has evolved and since the advent of hardware virtualisation, virtual 8086 mode is essentially now available when in 64 bit mode.
Not according to https://en.wikipedia.org/wiki/X86-64#AMD64
Multiple points raised. To which were you referring to?
While that is true for Windows, I suspect the OP is running Linux (though he didn't clarify) - DOSemu kind of implies that.On linux with dosemu, i use x00.exe in emusetup.bat and all doors run fine.
digital man
On 09-21-19 02:00, Digital Man wrote to Tony Langdon <=-
You said "the hardware has evolved ... virtual 8086 mode is ... now available ... in 64 bit mode". I've see no evidence that is true.
On 09-21-19 02:00, Digital Man wrote to Tony Langdon <=-
You said "the hardware has evolved ... virtual 8086 mode is ... now available ... in 64 bit mode". I've see no evidence that is true.
In the way it was implemented in 32 bit mode, you are correct, but the hardware virtualisation of modern 64 bit CPUs can be used to spin up a virtual processor as needed.
From https://en.wikipedia.org/wiki/X86-64#OPMODES
Long mode
Main article: Long mode
Long mode is the architecture's intended primary mode of operation; it is a combination of the processor's native 64-bit mode and a combined 32-bit and 16-bit compatibility mode. It is used by 64-bit operating systems. Under a 64-bit operating system, 64-bit programs run under 64-bit mode, and 32-bit and 16-bit protected mode applications (that do not need to use either real mode or virtual 8086 mode in order to execute at any time) run under compatibility mode. Real-mode programs and programs that use virtual 8086 mode at any time cannot be run in long mode unless those modes are emulated in software.[11]:11 However, such programs may be started from an operating system running in long mode on processors supporting VT-x or AMD-V by creating a virtual processor running in the desired mode.
See also:
https://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_VMX_support
So to run DOS programs under a 64 bit OS, you have to make use of the processor's hardware virtualisation.
On 09-21-19 20:41, Digital Man wrote to Tony Langdon <=-
Right, but you could software-emulate just about any CPU, that doesn't make the actual CPU support virtual 8086 mode (in 64-bit/long mode).
DOSemu is only for linux, AFAIK... i don't think it even runs on *BSD... or at least not yet if there's been any work done on that front... i haven't seen anyone running *BSD mention it in the last six months or so...
DOSemu is only for linux, AFAIK... i don't think it even runs on *BSD... or at least not yet if there's been any work done on that front... i haven't seen anyone running *BSD mention it in the last six months or so...
I've seen DOSEmu or similar for Windows.
Its main use is running old 16-bit DOS programs on 64-bit editions of Windows (which would normally be unable to run DOS software). I've seen old 16-bit DOS games from Steam
I've seen DOSEmu or similar for Windows.
or similar is not the same thing ;)
| Sysop: | BrokenMind |
|---|---|
| Location: | Central Pennsylvania United States |
| Users: | 60 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 58:31:41 |
| Calls: | 177 |
| Files: | 2,017 |
| Messages: | 20,571 |