Colin I'm not sure the approach you describe will work - the /dev/ttyqx stuff is quite outdated and represents actions of the login/telnet process. I'd be interested to hear if it does work, however !
What I understand you have is this : You have software on a server which can be telnetted, however the application which executes has hard-coded sequences for a DG-210 or 460 terminal, hence it does not display properly. You have a DOS based emulator which meets your purposes for the terminal emulation and this even runs in a DOSEMU window without problems. However, this program only talks to serial ports (since it is emulating a serial terminal). What you want to achieve is a method of this terminal emulation program "telnet"-ing to the server with the program. The simplest approach I can see for this would be based upon a small patch to DOSEMU - after all you have the source code and this is what the "Free" in Free Software actually means - the patch would be to alter the behaviour in the opening of the serial port. Talking to a network port is very similar to opening any disk file or a device file. Presently the code opens a device file (for the serial port) and you just need to alter this to open a socket connection to port 23 (telnet) on the server - you will have a file descriptor returned in the same manner as opening any other file. Provided the application does not try any fancy manipulation of the serial port, things should go smoothly from here [look for ioctl calls]. If you need any negotiation with the server, such as a login and password, you would [initially] hard code these to your patch - before implementing a more robust approach, of course. [which would see some alteration to the config file to allow this behaviour to be specified - you might even get your name in DOSEMU's credits for your bother !] Regards Jim >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 09/10/01, 13:24:46, Colin McKinnon <[EMAIL PROTECTED]> wrote regarding Re: [scottish] How daft is this?: > At 10:24 08/10/01 +0100, Colin McKinnon wrote: > >I thot about using a FIFO in place of the terminal device....but can that > >discriminate the polarity of bidirectional communication (if one process > >writes to the FIFO which gets to read the data)? Running two copies of > >minicom on a fifo suggests that its a bit more complicated. Anybody any ideas? > I suspected that pseudo TTY's might have something to do with what I was > trying to achieve.......only finding any information about them proved > quite difficult - I eventually found what I was looking for in the AX25-HOWTO: > >Pseudo-TTY devices create a kind of pipe through > > which programs designed to talk to tty devices can talk to other > > programs designed to talk to tty devices. Each pipe has a master and a > > slave end. The master end is generally called `/dev/ptyq*' and the > > slave ends are called `/dev/ttyq*'. There is a one to one relationship > > between masters and slaves, so /dev/ptyq0 is the master end of a pipe > > with /dev/ttyq0 as its slave. > It SHOULD work. Wahoo. I love *nix. > ......so all I need to do is run a getty on one end, sort out the right > stty stuff to ignore the DG control codes (thanks Kevin - getting a list of > the codes wasn't a problem but it does use some nasty stuff - ctrl-C for > F11, ctrl-Z for dnarrow) and I should be laughing. Is there an easy way to > start a getty without modifying inittab? > I suppose I also need to think about how to run multiple sessions since the > serial port file is explicitly configured in the dosemu config file. > Colin > -------------------------------------------------------------------- > http://www.lug.org.uk http://www.linuxportal.co.uk > http://www.linuxjob.co.uk http://www.linuxshop.co.uk > -------------------------------------------------------------------- -------------------------------------------------------------------- http://www.lug.org.uk http://www.linuxportal.co.uk http://www.linuxjob.co.uk http://www.linuxshop.co.uk --------------------------------------------------------------------
