RE: Elks progress
hi ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.83.tar.gz Greg Would it be a good idea to put a link to this on the main ELKS web site? Greg you must be getting board telling eveyone where it is? tom __ Get Your Private, Free Email at http://www.hotmail.com
Re: your mail
Thomas Stewart writes: hi This many be a stupid idea, As far as I know consoles on linux are seperate, ie each can run diffrent proceses independent of each other? Is this the same for ELKS? (using the f keys) In my elks machine I have a vga card and a herc card, how can I use both. (i.e. switch to ether card and start an app, then switch back to the other card)? Do I need to do a "mknod" to make a special tty? or is it something else? Or is there a better way to use the two cards together? DOS does not do this very well (appart from a few utills that switch the screen, and a few apps that support it (tcc).) There is no current support for this in the ELKS code, but it does appeal to me. Any idea how it can be done at a low level anyone? If there is source code available for the DOS software, then it could be ported. tom ps somehow I was taken off the mailing list does anyone know how this happened? (I have since checked the lists members, found out I was not on it, and re-subscribed.) Strange stuff happens with the list evry now and again. I have had to resubscribe several times. Al
Re: your mail
Ha! ive been trying to get OFF this list for eons and havent had any luck so far... Alistair Riddoch [EMAIL PROTECTED] on 09/28/99 02:22:00 PM To: [EMAIL PROTECTED] (Thomas Stewart) cc: [EMAIL PROTECTED] (bcc: Habib Ahmed/PK/ABNAMRO/NL) Subject: Re: your mail Or is there a better way to use the two cards together? DOS does not do this very well (appart from a few utills that switch the screen, and a few apps that support it (tcc).) There is no current support for this in the ELKS code, but it does appeal to me. Any idea how it can be done at a low level anyone? If there is source code available for the DOS software, then it could be ported. tom ps somehow I was taken off the mailing list does anyone know how this happened? (I have since checked the lists members, found out I was not on it, and re-subscribed.) Strange stuff happens with the list evry now and again. I have had to resubscribe several times. Al _ Disclaimer: "Any unauthorized form of reproduction of this message is strictly prohibited. The bank does not guarantee the security of any information electronically transmitted and is not liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt. THE USE OF EMAIL FOR ANY ILLEGAL PURPOSE OR FOR ANY PURPOSE OTHER THAN AS PERMITTED BY THE BANK IS STRICTLY PROHIBITED AND SUCH USE MAY RESULT IN DISCIPLINARY AND LEGAL ACTION."
RE: your mail
: Or is there a better way to use the two cards together? DOS does not do this : very well (appart from a few utills that switch the screen, and a few apps : that support it (tcc).) : : There is no current support for this in the ELKS code, but it does appeal : to me. Any idea how it can be done at a low level anyone? If there is : source code available for the DOS software, then it could be ported. : I think the answer to this is that each virtual console needs to have a pointer to it's screen driver code, where there's multiple screen drivers running. I don't know how you'd want to specify which VC gets VGA vs herc though... Greg
RE: Another ELKS idea for shared libraries
On Monday, September 27, 1999 7:40 PM, Michael G Hughes [SMTP:[EMAIL PROTECTED]] wrote: : Currently, the biggest : problem with shared libraries on 8086 and bcc is that the compiler can't : produce position-independent code (ala -fPIC) so that even the code segment : requires data relocations, and thus can't be shared. So each process has : it's : own copy. : : What about just using DS/CS as they were designed (as I believe is done : for task switching), can bcc handle that? Or create something like an : indirect jump and glue code in the library. The indirect jump and glue code is exactly what is needed out of bcc. currently, it doesn't generate any of that kind of code.
Re: Another ELKS idea for shared libraries
: for task switching), can bcc handle that? Or create something like an : indirect jump and glue code in the library. The indirect jump and glue code is exactly what is needed out of bcc. currently, it doesn't generate any of that kind of code. It also cant do that on an 8086 without ruining swapping/defrag
RE: Another ELKS idea for shared libraries
On Tuesday, September 28, 1999 11:56 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : : for task switching), can bcc handle that? Or create something like an : : indirect jump and glue code in the library. : : The indirect jump and glue code is exactly what is needed out of bcc. : currently, it doesn't generate any of that kind of code. : : It also cant do that on an 8086 without ruining swapping/defrag As I mentioned before, if this were performed with code segments only, then they could still be shared with the resulting memory decrease benefit. It gets increasingly hard to do everything with only 64k of code, especially when the cpu architecture allows for more (albeit in a crappy fashion). Another implementation would have far segment code jumps go through a local smaller table, and this table could be relocated easily on swapping. (That is when we implement swapping...) In fact, with a ridiculous increase in code size, all absolute locations could use a [bx] register offset to get to a small table of hard adresses, just like the ELF .got section is implemented. I'm not recommending this, though, since we're already short on cseg space. Greg
Re: Another ELKS idea for shared libraries
As I mentioned before, if this were performed with code segments only, then they could still be shared with the resulting memory decrease benefit. But is outweighed by the cost of no swapping or defragmentation In fact, with a ridiculous increase in code size, all absolute locations could use a [bx] register offset to get to a small table of hard adresses, just like the ELF .got section is implemented. I'm not recommending this, though, since we're already short on cseg space. You need to cover call/ret sequences. It is doable but hard
RE: your mail
On Tue, 28 Sep 1999, Greg Haerr wrote: : Or is there a better way to use the two cards together? DOS does not do this : very well (appart from a few utills that switch the screen, and a few apps : that support it (tcc).) : : There is no current support for this in the ELKS code, but it does appeal : to me. Any idea how it can be done at a low level anyone? If there is : source code available for the DOS software, then it could be ported. : I think the answer to this is that each virtual console needs to have a pointer to it's screen driver code, where there's multiple screen drivers running. I don't know how you'd want to specify which VC gets VGA vs herc though... Why not just have a /dev/2tty driver set for the new monitor and have init asign logins to /dev/tty and /dev/2tty? Luke(Boo) Farrar.
Re: your mail
On Tue, Sep 28, 1999 at 10:22:00AM +0100, Alistair Riddoch wrote: Thomas Stewart writes: Or is there a better way to use the two cards together? DOS does not do this very well (appart from a few utills that switch the screen, and a few apps that support it (tcc).) There is no current support for this in the ELKS code, but it does appeal to me. Any idea how it can be done at a low level anyone? If there is source code available for the DOS software, then it could be ported. There is no need for any trick - as far as I can recall, the only thing one has to is to address the vga's buffer at 0xb8000 and the herc's at 0xb. It can be done from any program. mov ax, 0b000h push ax pop es mov es:[0], 030h mov ax, 0b800h push ax pop es mov es:[0], 031h ret writes a '0' to the herc and a '1' to the vga. Sorry if this was obivious to everyone. -- Kovacs Kristof Systems Programmer mailto:[EMAIL PROTECTED] http://kkovacs.monortel.hu
RE: Another ELKS idea for shared libraries
On Tuesday, September 28, 1999 12:26 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : As I mentioned before, if this were performed with code segments : only, then they could still be shared with the resulting memory decrease benefit. : : But is outweighed by the cost of no swapping or defragmentation Yes, but it'd make sense to set a noswap bit for large executables, at least we could run them, which we can't AT ALL now. : : In fact, with a ridiculous increase in code size, all absolute : locations could use a [bx] register offset to get to a small table of hard : adresses, just like the ELF .got section is implemented. I'm not recommending : this, though, since we're already short on cseg space. : : You need to cover call/ret sequences. It is doable but hard I forgot about that, I concede this one to you, noone wants to trace stacks fixing up segments but maybe MS... : :
Anybody using this list?
Just thought I'd see if there was anybody here, since I'm brand new to this. I'm hoping to get ELKS on my Toshiba T1200 notebook (8086-10, 640K ram, dual 720K floppies) and use it as a serial console for all of my nifty serial devices (hubs, routers, sun boxen, etc.) Anybody tried anything similar yet? Greg
