compiler.
In regards the your comment about the 32k DS problem, I didn't follow you.
What's the current problem and your proposed solution?
Greg
[EMAIL PROTECTED]
-Original Message-
From: Chad Page [EMAIL PROTECTED]
To: Greg Haerr [EMAIL PROTECTED]
Cc: '[EMAIL PROTECTED]' [EMAIL
then compile
make, ar86
Which could then be used to compile
libc, et al
I know we need a few other utils, like rm, mv, etc. The ELKS project is
supplying them.
Can you think of any other utils we need to be self-hosted?
Greg Haerr
[EMAIL PROTECTED]
I agree that the ELKS homepage needs updating. It lists quite
old versions of both the ELKS kernel and dev86 development environment.
In addition, some of the pointers to the most recent versions of the above
are not correct anymore.
gh
On Thursday, January 28, 1999 1:39 PM, Chipzz
The easiest way to do this is to compile up your C function
without the #asm and look at the assembly code that is generated. The
-S option is used for this.
Keep in mind that variables fall into two classes: function local
and global. In the code you submitted, the variables are all local.
Al -
I would be very interested in seeing your design for the dynamic linking
mechanism for 8086 code for ELKS. Being very interested in
compilers/linkers
and operating system codefile formats, I would be willing to work on the
linker
mods that might be necessary to keep the linkage
I have had some thoughts on the best way to support graphics. I think it
would be cleanest to implement an ioctl in the dircon driver telling that
an application requires graphics so it has to save the contents of the VCs,
and disable VC switching, and writes to VCs. This then leaves a user
I tried running MINIX on an old Toshiba, but the power-safe bios mode
always took over and the console went blank...
Greg
On Friday, May 07, 1999 1:04 PM, Leonardo Sampaio Cardoso [SMTP:[EMAIL PROTECTED]]
wrote:
Anyone got elks running on those toshiba XT machines like the T1000??
leosam.
Fellow NanoX interested parties:
I have today finished work on nanoX version 0.3, which includes the following features:
o completely seperate driver api and drivers for screen, mouse and keyboard.
All drivers are in a drivers/ subdirectory. It's really easy to write a driver set
for
The nanoX site is:
http://www.linuxhacker.org/pub/nanogui/nano-X/
It should be up there in a little bit.
Greg
On Tuesday, May 11, 1999 12:19 PM, Luke (boo) Farrar
[SMTP:[EMAIL PROTECTED]] wrote:
On Tue, 11 May 1999, Eric J. Korpela wrote:
o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes.
NanoX now runs on DOS! (OK, I did this only to see how portable
The point about ELKS being currently limited to 64k code is a very good one.
I think we're kind of nearing that limit, aren't we?
Greg
On Tuesday, May 11, 1999 4:18 PM, Shane Kerr [SMTP:[EMAIL PROTECTED]] wrote:
On Tue, 11 May 1999, Eric J. Korpela wrote:
Does anyone else agree with me
Louis - you have the right idea. Take a look at nanoX's server/drivers/scr_dos.c for
the int10 driver. The pixel drawing can be considerably optimized if we know that
the int10 framebuffer is at segment 0xa000 and we're running in 4 or 8 bpp mode...
FP_OFF(ScreenBuffer) = y*linesize +
Overall, I don't think its a good idea to bring graphics stuff into the ELKS
kernel, yet.
Especially since the plan is there'll be only one graphics server running per
ELKS system, ever.
Okay, we can rely on the ioctl made to initially request graphics access to
lock the graphics
It's all about finding time to re-write code that's already written in the bios, and
space tradeoffs in the 64k codeseg limit for the kernel... Not to mention
portability issues.
On Wednesday, May 12, 1999 7:27 AM, Ansel [SMTP:[EMAIL PROTECTED]] wrote:
easily handle. Personally I'm of the
Can you email me this .gif file? I will use it in a sample nanoX program,
so that when ELKS runs nanoX, it's display a logo.
Greg
On Saturday, May 15, 1999 11:48 AM, Luke (boo) Farrar
[SMTP:[EMAIL PROTECTED]] wrote:
On Wed, 12 May 1999, Curtis Weyant wrote:
Hello,
I'm new to this
Granted, one could add drivers for specific hardware, and have the
kernel routine detect and use it in preference to the BIOS driver if
the relevant driver is present, but I wouldnae see such as a first
choice for getting a working video subsystem...
Yes, get it working
1. IBM MDA.
no graphics support...
2. Hercules MDA.
you mean the HGCA?
3. CGA.
320x200 support doesn't really cut it.
4. EGA.
5. MCGA.
6. XGA.
7. VGA.
8. Assorted SVGA modes - how many are there now?
Some drivers for the ATI mach32 and mach64 chips
1. Does ELKS support select()? We need select() for the mouse_fd and
keyboard fd, (serial and console tty) -OR- we can write a polling driver entry
point...
The current version inCVS does, which will be released soon. The last
release does not.
Hopefully you have all
As you will see from the mailing list I have released the kernel which has
working select(2) so you can give it a try.
Make sure you are using termios. ELKS does not support older terminal
control interfaces like termio.
Great. Also, I have completed work on an EGA/VGA driver
If you really, really, really want one and can't find it, I might have one on
a mag tape somewhere, if I could just find a system that reads mag tape...
Are you sure it?s not a Small C Compiler ? It?s lack of structs, unsigned
and even doesn?t heard of void. And without this this, zcc is
: ...actually, now I come to think about it, isn't that what lpr and lpd do
: anyway? So why does my big-Linux box have an lpd running all the time?
:
Lpr is client side and not spawned by inetd. The way
that inetd works, it's pretty easy to write daemons that can run standalone,
or
: This sort of thing could also be applied to a RAM only system, for example
: the Psion 3a - which I'm doing some work on.
:
: As a side comment about Psion stuff-
: I've got a keyboard scanning working and some basic screen stuff, but I need
: to find a 'free' bit mapped font to use (probably
: Have you looked at the fonts that come with X11? They are nice and clean,
: and seem to work in a good range of sizes.
:
: Al
:
There's also a utility with nano-X that converts X11 bdf files to C format.
Greg
My port of nano-X to ELKS solves all these problems, and does it under 64k!
Greg
On Tuesday, June 01, 1999 10:55 AM, legacy [SMTP:[EMAIL PROTECTED]] wrote:
:
:
: [EMAIL PROTECTED] wrote:
:
: I glance at this mailing list from time to time to see if there have been any
: breakthroughs.
On Tuesday, June 01, 1999 2:07 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
: Ross Vandegrift writes:
:
: Tell me of another editor. :)
:
:
: You're not going to like your more reasonable options, but I'll be blunt: vi
: or ed should work nicely, when ported.
:
:
: Why would
On Tuesday, June 01, 1999 7:19 PM, Ross Vandegrift [SMTP:[EMAIL PROTECTED]] wrote:
: But seriously... I'm wanting to get my C skills back into shape. Can
: anyone
: think of a good program to port? Maybe "ed" wouldn't be such a bad
: start... or
: maybe some old games from Slackware's Y
: In the bath last night (as always) I thought about how I could modify ELKS
: so it would run without a filesystem, and came up with a way of storing
: binary images in an area of ROM. The ROM would simply contain all the
: binaries in minix format concatenated together, the header of each
: I am still trying to get hold of a vi clone that uses tmp files rather than
: keeping the file in RAM, and is GPL compatable. levee fails on both counts
: so is unable to deal with decent size files, and may cause license
: conflicts in elkscmd. Does your version fit these requirements?
:
:
: Bcc. I think that its one of the things that needs porting the most. Why?
: Here's why.
:
: ELKS is shaping up quite nicely. We have a useable unixish system. But I
: think that it needs certain things:
:
:
: A C compiler.
I have had as a top priority getting the dev86 kit
This list has been conspicuously quiet for the last while, so I thought
I'd try to wake it up a bit.
Following my last major work to nano-X version 0.6, which basically
got all the mini-x feature set running, along with device drivers for keyboard,
mouse and screen for linux framebuffer, linux
: How is the ELKS API accessed in assembly? I think I'll need that if I'm
: going to code one of those editors.
:
Look at the elks dev86 distribution. Basically it's an int 0x80
with the parms in registers ax, bx, cx, dx.
Greg
On Thursday, June 03, 1999 3:15 AM, Paul Roberts [SMTP:[EMAIL PROTECTED]] wrote:
: As windowing toolkits such as GTK+ and V now exist in some form on many
: unices and win32 wouldn't it be more useful to port one of those (i reckon
: GTK+) to nano-X ?
:
:
: Cheers
:
: Paul
:
Please go right
On Thursday, June 03, 1999 6:01 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote:
: In addition, the minix filesystem *must* support files 512k, something it
:doesn't do
: now. The libc.a file is 512k so you can't even link anything on ELKS. This
: requires supporting 7 indirect blocks.
:
:
On Thursday, June 03, 1999 10:07 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote:
: : You then need a 386. 64K is the limit. The original work I did was designed
: : to be easy to run in 286 protected mode once you got rid of any BIOS interfaces.
: :
: Remind me - what then is the benefit of
On Thursday, June 03, 1999 5:01 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote:
: in order to address the additional memory on a per-process basis we need
: large code or large data segments through the compiler (far pointers). In this
:
: There are no "large" segments. This is one of the
On Thursday, June 03, 1999 1:36 PM, Alex Holden [SMTP:[EMAIL PROTECTED]] wrote:
: On Thu, 3 Jun 1999, Alan Cox wrote:
: Keep networking mostly in user space. That btw is also the model things like
: the early networking work on V7 unix took.
:
: I was wondering if KA9Q NOS might be used as a
On Friday, June 04, 1999 5:28 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote:
: A reloc table in the binary (like DOS EXE files) could work for code at
: least (as long as the binaries are immutable while a process is using
: them, and the programs are careful about self-modifying code).
:
: No
On Thursday, June 03, 1999 7:27 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote:
: This brings up my wishlist again, that we should have bcc compiler
: support for medium and large models for x86. Al Ridoch doesn't want to
: move to supporting the _far keyword. I think that it would buy us
On Monday, June 07, 1999 8:43 AM, Thor Harald Johansen [SMTP:[EMAIL PROTECTED]] wrote:
: No without a special added hardware. The I8086, 8088, 80188, 80186
: have no memory protection implemented. First chip from Intel which
: has memory protection is 80286 as I know.
:
: If this is correct,
On Tuesday, June 08, 1999 11:13 AM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
wrote:
:
: Someone was doing a port of lcc to the 8086/8, weren't they? Could whoever it
: was get in touch with me? I'm looking for something similar and was wondering
: if I could have a look at the .md file.
:
On Tuesday, June 08, 1999 11:13 AM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
wrote:
:
: Someone was doing a port of lcc to the 8086/8, weren't they? Could whoever it
: was get in touch with me? I'm looking for something similar and was wondering
: if I could have a look at the .md file.
:
On Tuesday, June 08, 1999 12:02 PM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
wrote:
: Also, what object and executable file formats are currently supported?
:
: LCC doesn't support any object and executable file formats. LCC only supports
: assemby output formats. LCC-8086 currently has only
: lcc-win32 != LCC
:
: lcc-win32 == LCC + assembler + linker + editor + other stuff
:LCC ends here ^
:
: As far as I know, the authors of LCC don't consider lcc-win32 to be
: an LCC distribution, and AFAIK, they don't offer support for any of the
: non-LCC components. (Not that they offer
On Tuesday, June 08, 1999 2:22 PM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
wrote:
: : Spilled registers are not
: : necessarily reloaded to the same type of register they were spilled from.
: : For example if you have an address in bx, and it
On Friday, June 25, 1999 2:12 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
: Greg Haerr writes:
:
:
: : So form of stack check would be nice, every function call seems a little to
: : much for a lowly 8086. How about on task switch or even interrupt (or is
: : this too late
Al,
In using ELKS v0.77, it's apparent that ^C console signals work
about 50% of the time. I was going to get involved in tracking this down,
but have some questions first.
Does ELKS use interrupt driven keyboard input? You were saying something
about tty input chars being
On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Mon, 28 Jun 1999, Greg Haerr wrote:
:
: I can't get Micro-Windows to work with the serial mouse driver.
: It appears there's still possibly a bug in select(). Basically, the
: mouse works for about 1 second
On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Mon, 28 Jun 1999, Greg Haerr wrote:
:
: I can't get Micro-Windows to work with the serial mouse driver.
: It appears there's still possibly a bug in select(). Basically, the
: mouse works for about 1 second
On Tuesday, June 29, 1999 4:13 AM, Simon Wood [SMTP:[EMAIL PROTECTED]] wrote:
: see below...
:
: PS (Pre-script) does anyone know how to get MS outlook to append your reply
: to the END of the quoted message, rather than put it at the beginning?
:
"Tools-Options-Internet Email-Email
: Making the contents of images.zip is not fully automatic, but most of the
: work is done by the Makefiles. I change the Makefile a bit between buidlign
: comb and root (modify size etc.)
:
I would *really* like a makefile that automatically makes your
distribution. (its a quality
: I have seen something like this, but it has never frozen on me. In nano-X,
: whenever I stop moving the mouse, the cursor stops moving (as expected),
: but when I start moving it in the oposite direction, it moves a few pixels
: in the same direction as before, then changes to move in the new
I've created patches for elkscmd-0.77 and dev86-0.14.8 to compile
on my system, which is Caldera Linux 2.2.5.
These patches are small and fix the following problems:
elkscmd:
o make doesn't complete, gcc used instead of bcc
dev86:
o unknown struct timezone
o
I have released another version of Micro-Windows, which allows
much easier porting to ELKS through use of a single Makefile for ELKS
and Linux, as well as adding another improved window move algorithm
for cpu's that don't have much pixelpower. Visible region calculations
are now performed for
: I wasn't quite sure how this worked from reading the gettimeofday man page.
: There are some references made in the manpage to the kernel
: no longer using the tz structure, but when I included the second line
: of the code fragment below, it worked fine in the UK. (we are currently in
:
: Basically it compiled cleanly for me, and worked under both systems. The
: only problem was that there is a C++ style comment at line 432 of winuser.c.
:
I missed that. I'll correct it for the next version.
: I still can't move windows under microwindows, in XOR or opaque mode.
:
On Wednesday, July 07, 1999 3:43 PM, Blaz Antonic [SMTP:[EMAIL PROTECTED]] wrote:
: i had an idea a few weeks ago to toggle the a20 gate on a 286, and use the
: memory from : to : for a ramdisk. this way we could use
: 64k-1byte of memory, which would otherwise be wasted.
:
:
:
: I compiled microwin, copied the binary to my elks root disk and it worked.
: Except that the mouse does not work properly, when I move the mouse the
: pointer moves all over at ramdom.
:
: First thought is wrong protocol. But normally this means the mouse moves
: to one corner and
Al,
I spent a good portion of the weekend fixing quite a few ELKS
bugs, trying to get a good visual editor running. It seems I have succeeded.
Following is the list of fixes that I have performed. I will attach in the next
email the patches for elks 0.77 and elkscmd 0.77.
o
: You killed my baby?? Exactly how has it stopped working? It's not a very
: complete implementation, only half-a-dozen ANSI commands are supported.
Killed your baby? Why, it seems this one died from neglect ;-)
try typing ESC [ H on the console. Nothing happens.
:
: o added
On Tuesday, July 13, 1999 12:00 PM, Blaz Antonic [SMTP:[EMAIL PROTECTED]] wrote:
: protocol is set with environment variables (they don't work yet with ELKS, I have
: a patch coming) or a recompile of mwin/src/drivers/mou_ser.c.
:
: Of course they do. My mouse is attached to second serial port
email the patches for elks 0.77 and elkscmd 0.77.
:
: o Ported elvis to ELKS
:
: Is this based on the code that was in elkscmd?
Yep.
:
: o changed all elkscmd srcs to use tcsetattr/tcgetattr instead of ioctl
:
: I previously held back from doing this to make the
: Yep, it won't do anything. The only commands supported, are: m (color),
: s (save location), u (unsave location), A (up), B (down), C (right),
: D (left), K (clear EOL). Mainly because these functions were already
: existing in the dircon code so it was very easy to interface to them.
:
:
: I agree, but of late I've had little enthusiasm to try and trim the fat
: off the larger areas of the code. In particular, the inode hashing code
: in fs (or is it specific to minixfs) is basically redundant. Firstly, we
: can do without hashing for a slight speed decrease. Also, the
Al,
I have written a test program for the select() bug. This Makefile
replaces the one in MicroWindows 0.82, and builds a test program. Test.c
uses select exactly like microwindows does, and doesn't use a graphics
screen. All kbd and mouse events are printf'd to the screen. Type ESC
Al,
In regards to patch #2, are you trying to make almost all the mods I sent in,
including the elkscmd makefile stuff? I would like it if you could.
Also, I have rewritten dircon.c last night (except for the bell()) issue that you just
mentioned). I have attached it. It is better
On Tuesday, July 13, 1999 12:30 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: I still can't get the mouse to work in microwin,
: I have tryed editing the sorce file "mwin/src/drivers/mou_ser.c"
: changing the "#define MOUSE_TYPE "pc"" to pc,ms,logi
: it still does not work
: what can
On Tuesday, July 13, 1999 12:35 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: I think it is a good idea to look into herc support for microwin? How many
: 8086's do you know with a VGA card? OR is it a bad idea are 8086's too slow
: to run microwin?
:
Well - you've got a good
: Monochrome adapters probably wouldn't take too much CPU to support. The
: most used type of Hercules card was 720x348x2 (with lots of clones) --
: perhaps this was the most common type of video card for a few years --
: although there was also a Hercules Color Card (which doesn't seem to
On Wednesday, July 14, 1999 2:19 AM, Alex Holden [SMTP:[EMAIL PROTECTED]] wrote:
: On Tue, 13 Jul 1999, Greg Haerr wrote:
: Well - you've got a good point - an 8086 is probably *way* too slow
: to run graphics programs of any merit. However, I would like to add
:
: I had a friend who used
: Not quite. I didn't actually know about the 512k limit, but greg says
: it's there. libc is tiny, as all ELKS programs are statically linked, so
: libc+program must be less than 64k.
:
The issue here is that the size of the libc.a file itself is 512k, so
the filesystem won't let
On Wednesday, July 14, 1999 6:32 AM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Wed, 14 Jul 1999, Scott Lanning wrote:
:
: 3) Also FAQ Q2.5, it says 'mkfs -t minix -n14 /dev/fd0 1440', but
: my mkfs has no -n14 option. However, 'mkfs.minix -n14 /dev/fd0 1440'
: works okay. (Maybe it's
Al,
I've now fixed the select() bug in ELKS, and, since MicroWindows
now runs on my system, have also fixed the mouse down bug for window moves
in MicroWindows. In addition, other changes to the kernel are proposed,
for better debugging.
Last night I spent some time really
On Wednesday, July 14, 1999 10:41 AM, David Murn [SMTP:[EMAIL PROTECTED]]
wrote:
: On Wed, 14 Jul 1999, Greg Haerr wrote:
:
: The issue here is that the size of the libc.a file itself is 512k, so
: the filesystem won't let ld86 read it...
:
: It is? I dunno where you got your libc.a
Last night, I got bcc, as86 and ld86 running on ELKS.
However, bcc can't quite compile itself, because it doesn't support
the STDC ## operator, which is used in bcc.c. I worked around this.
So I started cross-compiling the ELKS kernel with my new tools,
initially using the elkemu emulator.
The
: I wouldn't mind looking into adding some kind of optimization capability
: to bcc so that we don't have to spend as much time optimizing code by
: hand.
:
Well, bcc -O uses copt, which is an ingenious, table driven solution. Perhaps
you can identify some bad code sequences that copt can
On Wednesday, July 14, 1999 1:17 PM, Thor Harald Johansen [SMTP:[EMAIL PROTECTED]]
wrote:
: GEM's the only thing that I can remember that pushed pixels in
: those early days on herc You know, GEM's src is available, but I've
: heard its **ugly**. That's why I went with the nano-X group.
: I am not realy up to writing the driver myself because I have never writen a
: driver before, but I will test it for you. I have 2 8086's with herc cards
: in.
Well, last night I took Jacob's hercules code samples and wrote
a complete hercules graphics driver for MicroWindows and
MicroWindows version 0.83 is released at
ftp://microwindows.censoft.com/pub/microwindows
This version of MicroWindows is released in tandem with Al Riddoch's ELKS v0.78,
which fixes a kernel select() bug with certain mice.
The ChangeLog for this version is:
Version 0.83 - 14th July
: I have examples on how to draw fast lines horizontal, vertical and
: (x1, y1) - (x2, y2) using Bresenham.
: These are in a book in asm. so I don't know about their copyright but
: I think they are intended to be used, ie public domain.
: Bresenham on Hercules is a little tricky.
No
: Do we need your bcc fixes to make it work?
No, I haven't published my ansi bcc or cross compilation stuff yet.
:
: I don't suppose there's any chance of a pre-built disk
: image, is there?
:
Sure - would you like the binaries for microwindows and nano-X?
I can't create them
: That is fine for normal cards, but since Hercules cards are so ... strange...
The VGA is *far* stranger, believe me, because of it's requiring more than
64k of video memory...
: the algo is very optimized for the Hercules.
: Example:
:
:
:
:
:
: Why not take the approach that Linux takes with the module:
:
: Create the driver structure, have the primitives referenced in the
: driver structure. If the driver doesn't implement a primitive, set
: the structure member to NULL, and the driver loader will take care
: to use the builtin
:
: If someone's really going to take that approach (I assumed something
: like this was already being done), then I recommend modifying it a
: little for speed. Instead of leaving NULL in the table and having to
: test it each time the function is being called, replace the NULL with
: a
: Obviously it would be smart to fill it in. However you must set it to NULL
: in the driver because of symbol resolution.
:
: As long as the device driver header file version matches with the one that
: the microwin server uses, the offsets are known.
:
: Locating the symbols inside the
: The place where nano-X and microwindows spend at *least* 95% of their
: pixel-pushing code is in drawing horizontal lines. All the demos but one
: *never* draw a diagonal line, the only case where bresenham is used. I had
: completed test cases to prove this...
:
: OK, granted.
: 3) The rest of the space is divided up into zones, each containing a maximum of
: 65536 blocks.
:
: 4) The first 8K of each zone is a bitmap of free blocks in the zone, 1 for
: used, 0 for free.
:
: 5) The rest of the zone is used for storing inodes/files.
:
This is basically the
: Actually, I have only studied the extent file systems, which are good for some
: things (like performace on really big files and smaller files). For small
: systems, these are not really suitable because they require too much caching,
: esp for really small files. Under an OS like elks, this
A good idea, almost. The BOGL library performs this for the packed pixel
:modes, but the VGA requires OUT instructions inbetween memory accesses,
:so it can't run on a generalized bit-depth algorithm in planes mode. (The VGA
:design has to be seen/studied to be believed,
On Sunday, July 18, 1999 4:21 AM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: How do you enable herc support in microwin? Greg?
:
Find the makefile lines that have scr_bios.o and scr_herc.o in them;
comment out the first one and uncomment the second...
Greg
: The code in devdraw.c is very naiive. It assumes pixel plotting is the underlyin
: op. On many cards line slices are the underlying operation, horizontal or
: vertical. What you probably want to do is generate a series of
:
: draw_horizontal(x,y,l)
:
: or
: draw_vertical(x,y,l)
:
:
:
: I tried to make a 0.0.78 kernel than and got this error:
:
: make[2]: Leaving directory `/usr/local/src/elks/arch/i86/drivers/block'
: bcc -D__KERNEL__ -O -i \
: 2 -nostdinc -Iinclude -c -o boot/crt1.o boot/crt1.c
: boot/crt1.c:5.25: error: cannot find include file arch/segment.h
On Sunday, July 18, 1999 1:13 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: I have got a mouse to work in mirowin at last! dont know if it was me or
: what, I could not for the life of me get any mouse to work. So in dispare I
: tryed my 10 year old genus mouse in 3-button mode in "pc"
: I got things a bit messed up in this release because I did things in the
: wrong order. The etc/issue file is automatically generated from the elks
: Makefile, but I had not updated it when I built the release. Releasing
: elkscmd and elks at the same time is becoming more work than is easy to
: the listing will show two "aa"s!!! Then the fresh
: "aa" will be recognized for the following 'cp', 'mv',
: or 'ln', but is tarnished by that operation again.. I have
: reason to believe the "No such file or directory" is returned by
: namei() which is called in
On Tuesday, July 20, 1999 2:39 AM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: I fired up my old beast last night, a v20 640k with a herc card, I ran my
: compiled copy of microwin with herc support, and it worked!
:
: WELL done to greg and whoever helped write that driver!
:
Al,
I just noticed you're cleaning up a bunch of fs code in ELKS.
I have been reviewing the original linux sources, and I think I've noticed an
error in the #ifdef BLOAT_FS stuff in ELKS.
The problem is in elks/fs/buffer.c, 22 lines into the function getblk().
There is a comment
: This is essentially what I have done. The only problem with doing this is
: that when fork() returns to the child, and the child calls exec(), the stack
: will be modified, so when the parent comes to return from fork(), it will
: crash, or at best do something odd.
Ok. When vfork()
:
: : The scheme I am using at the moment, that of copying the bottom 100 bytes
: : of the stack for the child to use, works, but does not really offer any
: : kind of safety net. Is it fair to just accept that if a process vfork()s,
: : and does not exec or exit, but instead carries on, it
On Thursday, July 29, 1999 11:16 AM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Thu, 29 Jul 1999, Perry Harrington wrote:
:
: I brought up a thread a long time ago on this, Borland wasn't interested
: then, but they just released Turbo C for free.
:
: Source, or just free binaries? If
On Thursday, July 29, 1999 12:47 PM, Matt [SMTP:[EMAIL PROTECTED]] wrote:
: I have an old 286 that's just collecting dust, but if I could use ELKS and
: minicom then I'd have a nice little terminal. Can ELKS run minicom? It
: says it has serial IO support.
:
: Matt
:
What's minicom?
1 - 100 of 184 matches
Mail list logo
