Re: ELKS 0.0.81 slower than the 0.0.76
the older versions are faster : > than the newer. The starting is the same but the shell is slower. : Mods to tty stuff shouldn't give any sort of noticeable difference, or fs : stuff. There is mention of changes to timer code, but I don't see why any : stuff like that should make any noticable difference. What do you mean, "the shell is slower"? You mean the tty output is slower? The prompt is displayed after some delay when no input is typed? Or applications are read from disk and are slower to start?
Re: A question
: For ELKS it isnt worth it. For real Linux it would be (and in fact it does : it all with lists) Although these suggestions about making extendable sleep structs are laudable, I, for one, agree with Alan. I think ELKS is a great learning tool, and should function simply. I've found that in many cases even ELKS code is too complicated. Alan has pointed this out with the #ifdef madness and other very little used options. The ELKS project should function as simple as possible, IMHO; various extended features (which few use) can then be easily added on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. Regards, Greg
Re: Definitive tree
I had implemented reading in the larger : header version of the minix format executable, and using one of the : fields in the extended header as the size of the stack below the datasegment. : I think this code had been developed to point where it worked, but : building binaries that it would load required extra compiler flags, and : hacking the header with a binary editor. I've gotten pretty familiar with the linker, let me know if you need a hack. Otherwise, my memory says that we've got enough info in the current header to put the stack below the data, providing the linker will change the beginning data offset to the max stack size. Regards, Greg
Re: Definitive tree
: I think I've figured how to : sort some of the stack handling stuff out and get some of our data space : back. You're not thinking of backtracing stack addresses, are you?
RE: Toshiba T1x00
:Hacking. I have a Swedish/Finnish keymap if you're interested. I've :been meaning to share for a while, but it's on a machine I can't get :to at the moment. I haven't verified that it works on anything but my :T1200 though. FWIW, I'm still looking for technical data on how the T1200 power manangement gets disabled. I tried booting ELKS on my trusty old T1200 and it worked until the "power manangement" kicked in - and turned off the power! Greg
Re: microchannel for ELKS update
: 1) I'm not going to get any code written any time : soon unless I quit school and quit my job and devote : all my time to "fun" coding like this. Well?? Which is it going to be??
Corrected download address for Microwindows
Ooops! The correct download url for Microwindows 0.87 is: ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.87.tar.gz Regards, Greg
Microwindows 0.87 released
Microwindows version 0.87 is (finally) released. Source code is available at: ftp://microwindows.censoft.com/pub/microwindows-0.87.tar.gz Version 0.87 is fairly stable and seems to work well. It's been a long time in coming since the 0.86 release at the end of October, 1999. The 0.87 release now runs on Linux framebuffer, Linux SVGAlib, X11, Solaris, RTEMS, ELKS, MSDOS 32 bit with DJGPP, and MSDOS 16 bit with MSC and PACIFIC C (free). The X11 screen driver supports emulating a target screen driver in 1, 2, 4, 8, 16, 24, and 32bpp, without having to cross-compile and run the application on the target device. The framebuffer screen drivers have been tested well, and now offer support for 1 through 32 bits per pixel, as well as high speed (software) blitting, and alpha blending. 1 though 8 bpp palettized modes, as well as 16, 24 and 32bpp truecolor modes are supported. The framebuffer drivers have been tuned for speed, although more enhancements are planned. The new make system is completed, and a config file now controls all options for specifying target architecture and features options. Cross- compilation support for x86, MIPS, ARM Linux, Solaris, ELKS, DJGPP and RTEMS is included. All demos and libraries are built at once, so it's much easier to link Microwindows when developing an application. A C++ object frameworks has been added. Support for displaying JPEG and BMP file types has been added. Thanks to everyone for the contributions - it was getting overwhelming for a bit there, but almost all contributions have been added to this release. I will now start work on getting the tree into CVS, as well as merging contributions for Truetype font support, as well as some cleanups with the screen device structure for speed. In addition, as a result of the press we've been getting, a number of folks are interested getting Microwindows running with their hardware and software. Following is the detailed ChangeLog: Version 0.87 - 13th February 2000 - [EMAIL PROTECTED] * added VTSWITCH in config to include virtual terminal switch code * added support for 24bpp, wrote 24bpp fb driver * fixed 8/8/8 color macros: RGB2PIXEL888, COLOR2PIXEL888, PIXEL888RED * fixed 32bpp fb bug with psd->ncolors, 32bpp alpha blit bugs * added fb driver support for FB_VISUAL_DIRECTCOLOR cards (ATI) * sped up 16, 32bpp blitters by using memcpy * added large font patches from Kyle * added PACIFIC C compiler support from Victor * default UPDATEREGIONS=N in config file for alpha blend demo * removed XORMOVE from config, requires only ERASEMOVE=N * wrote alpha blending demo (requires UPDATEREGIONS=N) * rewrote void *pixels in devdraw.c, won't compile on ansi compilers * fixed PF_TRUECOLOR0888 bug in GdArea * added DJGPP as config ARCH option, Victor's patches for DJGPP * finalized alpha blending blit routines for 8, 16, and 32bpp * added SetTimer/KillTimer api (single timer only) * added Chris' SetSysColor api, C++ object frameworks patch to mwin/ * added Rosimildo's make patches for RTEMS * added Martin's make/configure patches Greg
Re: Dos Binary Compatibility WAS Re: elksfs status
: Basically, its simply a binary format handler, which simply processes the : exe header from a file, and claims that its valid or not. It was more an : excercise for me learning how to parse exe headers. Yes. I'm quite familiar with MSDOS EXE format and the current code doesn't do anything near what's required. And even if it did, there's the problem of having linking with a Linux8086 libc but producing .exe files... Greg
Re: MCA documentation -- was "lots of questions..."
: Is there a way to run bcc on a file or set of files to see where the : problems will lie with regards to moving from 32-bit instructions to : 16-bit instructions? bcc -I/usr/src/elks/include *.c Having only been learning C for 3 weeks now, I'm : still not quite able to pick out problems with changes in system : architecture :) You've got your work cut out for you. There's little chance that what your attempting will work without alot of coding ;-) Greg
RE: Fw: cvs commit: elks/arch/i86/kernel process.c
: I think you may be mis-remembering the bug. IIRC the 32K bug was in
sys_brk()
: and was related to the type of the argument being signed instead of
unsigned.
I think you're right. The original bug can be reproduced by having
a small ELKS program that malloc's memory. We should be able
to malloc almost 64k. The previous version would fail whenever
the DS offset > 32k.
Greg
:
: Thanks for keeping a look out. I am glad someone reads the cvs commit
messages.
:
: Al
:
: int sys_brk(len)
: __pptr len;
: {
: register __ptask currentp = current;
:
: if (len < currentp->t_enddata ||
: (len > (currentp->t_endseg - HEAP_LIMIT))) {
: return -ENOMEM;
: }
:
: currentp->t_endbrk = len;
: return 0;
: }
:
:
: >
: > Regards,
: >
: > Greg
: >
: > : +/*
: > : + * We only need to do this as long as we support old format
binaries
: > : + * that grow stack and heap towards each other
: > : + */
: > :void stack_check()
: > :{
: > :register __ptask currentp = current;
: > : - if (currentp->t_regs.sp < currentp->t_endbrk)
: > : - {
: > : + if ((currentp->t_begstack > currentp->t_enddata) &&
: > : + (currentp->t_regs.sp < currentp->t_endbrk)) {
: > :printk("STACK (%d) ENTERED BSS (%ld) - PROCESS TERMINATING\n",
: > currentp->t_regs.sp, currentp->t_endbrk);
: > :do_exit(SIGSEGV);
: > :}
: > :
: > :
: > :
Fw: cvs commit: elks/arch/i86/kernel process.c
Al,
I happended to see this bug come across the CVS, and just wanted
to make sure that you've double checked it. This was the exact area that
had to be changed relating to ELK's sys_brk() bug that disallowed
data segments > 32k... I can't quite remember the original code.
Regards,
Greg
: +/*
: + * We only need to do this as long as we support old format binaries
: + * that grow stack and heap towards each other
: + */
:void stack_check()
:{
:register __ptask currentp = current;
: - if (currentp->t_regs.sp < currentp->t_endbrk)
: - {
: + if ((currentp->t_begstack > currentp->t_enddata) &&
: + (currentp->t_regs.sp < currentp->t_endbrk)) {
:printk("STACK (%d) ENTERED BSS (%ld) - PROCESS TERMINATING\n",
currentp->t_regs.sp, currentp->t_endbrk);
:do_exit(SIGSEGV);
:}
:
:
:
RE: Lots of questions from someone.
: > I have spent considerable effort trying to make sure that the Microwindows : > system will run on 16 bit systems, and it should continue to do so, : > although currently the application must be bound with the server : > since we lack UNIX sockets. This limits the application size. : > : : Could you please explain what you mean by the above statement? (bound?...UNIX sockets?) Thank you. In the current implementation, we allow Nano-X clients (otherwise known as graphics applications) to run as separate, normal UNIX/ELKS programs. They perform a network connection to another program, known as the graphics server (X server, Nano-X server, etc). When the connection is on a local machine, a fast limited form known as UNIX sockets can be used for the network connection. If the operating system doesn't support networking (like ELKS), then we also allow the graphics application to be linked with the server directly, and execute a single program. Regards, Greg
RE: KA9Q
> that might be useable as a user-mode ELKS implmentation : > of IP, UDP and TCP. And it supports alot of different cards : : Not directly tho True. However, it supports the original Packet Driver spec. This has a pretty well defined interface, and all the drivers run in 16 bit real mode. There are source drivers available for almost every original card, most as antiquated as the systems ELKS is running on... : KA9Q net was the earlier package, it ran on CP/M once so may fit The KA9Q package is modular, and many items can be dropped initially, in order to make it fit. Perhaps even just IP and ICMP on top of SLIP first, and try to get ELKS to respond to a ping! ;-) Greg
KA9Q
: while trying to get KA9Q NOS to run under elks (*) i stumbled accross the KA9Q NOS... Now there's a neat little [>64k..., sorry] package that might be useable as a user-mode ELKS implmentation of IP, UDP and TCP. And it supports alot of different cards as well as serial. Let me know if you need some help. Regards, Greg
Re: Lots of questions from someone.
: > >3) Is any one working on a GUI for ELKS, If so what is it called : : Yes, the microwindows/nanogui project ran on ELKS in its early stages, : and may still do. I have not tested it for a while. We could really do with : someone to keep track of its development, and make sure it can still run on : ELKS. It is currently moving quite fast so it is hard for me to keep up with : it and get any real work done. Yes, Microwindows still runs on ELKS. I have tested the v0.86 release. There has been alot of work, including major Makefile changes in the 0.87 prereleases, and I haven't tested ELKS with that yet. I have spent considerable effort trying to make sure that the Microwindows system will run on 16 bit systems, and it should continue to do so, although currently the application must be bound with the server since we lack UNIX sockets. This limits the application size. Regards, Greg
RE: Call for a README
: If you have any suggestions for this readme send your comments to : [EMAIL PROTECTED] : or : [EMAIL PROTECTED] : : --Phillip J Rhoades Fantastic job! You're definitely hired for a writing position!! Greg
Re: Call for a README file
: So I decided I need to put a README and an INSTALL file with the distribution : in future releases, but that I am not really qualified to write them. Al, Not to disagree with you, but I think that it's important that the actually useful Real Technical Information (tm) be included in an INSTALL. This information should state exactly what a user should do to get from images.zip to a running ELKS installation. Brief technical descriptions of what root, comb etc are are necessary, IMHO, and you're the perfect person to write that. Having said that, then, someone less technical might massage the message to help users less technical... My $.02 Greg
RE: X-Server
: Hi! : : I just heard about the elks project; : : Does anybody know about an X-Window R11 Server running : on 16 bit systems ? : I want to transform my old 286 to an X-terminal. : Is it possible ? : If you want to run a terminal program, we have that running with ELKS' graphical applications development system, known as Microwindows. It's fairly easy to write new graphics applications, but of course we've got the 128k code/data limitations... If, OTOH, you're looking to run unmodifed X applications on 286's in real mode, I would say that, unless you've got a lot of time on your hands, it's not available. Greg
RE: May be mistake?
: >if (irq < 8) {
: > cache_21 |= 1 << irq;
: > outb(0x21,cache_21); <--- outb(cache_21,0x21);
: > } else {
: > cache_A1 |= 1 << (irq-8);
: > outb(0xA1,cache_A1); <--- outb(cache_A1,0xA1);
:
: Linux outb() macros are data, port
:
Yep, that code is definitely buggy. Good thing the
whole proc is #if 0'd out ;-)
Greg
why asserts are failing
: assert ( "drivers/vgaplan4.c", line=173, :msg=0x129403 "y2 >= 0 && y2 < psd->yres") Rosimildo - The reason that asserts aren't working is because the vga driver has only been tested on the ELKS system, which lacks an assert() macro. Thus, the assert()'s have never been compiled in ;-) I've never been able to get my system running vga16 framebuffer, so I can't test the damn driver without running ELKS. Greg
Microwindows 0.87pre3 released
A hopefully last prerelease to Microwindows 0.87 is available at: ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.87pre3.tar.gz This prelease covers most all issues discussed on this list in the last couple weeks. Following are some major items: o Directory reorganization started. The microwindows and nanox specific source code, as well as the common engine routines are now in their own directories. Include files are placed in a common directory, etc. Although the source file rearrangement is nearly complete, I still haven't added Martin's new Makefile system (that will be coming, next cut). Thus, there still aren't separate bin and lib directories, but the source organization should make learning easier. o GrArea() modified to allow different types of pixel data to be displayed. Most of this is discussed in previous email lists. It all works and should be enough for Morten to use as a base for his work. This involved quite a bit of work, but is worth it since Nano-X now supports drawing in device dependent and device-independent manners. o Quite a few bug fixes, including the Nano-X 64k request packet fix, the GrMoveWindow fix for Nano-X allowing windows to be moved and clipped properly, fixing portrait mode in Microwindows offscreen blitting, and the assert() fix that caused Microwindows to exit sometimes. For the next cut I plan on adding Martin's make system, which allows for much better configurability, as well as all demos and libraries to be made at once. In addition, I'm probably going to take a swipe at creating a window manager base for Nano-X, so that it's windows can look as cool as Microwindows API, if desired. (No, this won't add much code) Let me know if there are any issues found, I want to make sure that 0.87 is a bug-free as 0.86 is. Following is the detailed ChangeLog: Version 0.87pre3 - 19th December 1999 - [EMAIL PROTECTED] * started directory reorganization * changed LINUX meaning in Makefile, added UNIX for SOLARIS * fix negative blit index bug found under X11 by Piotr * set rootwp->parent = NULL for nano-X, fixes GrMoveWindow clip bug * added COLORVAL<->PIXELVAL conversion macros * modified GrArea to take packed pixel values of 8, 16 and 24 bits * modified GrArea to take RGB COLORVALs as well as PIXELVALs * renamed PF_TRUECOLOR24 to PF_TRUECOLOR888 * added tunable MAXREQUESTSZ to limit max request length * modified Nano-X demo.c to GrArea() > 64k pixelvals for testing * fix client/server 64k length bug (request can be 24 bits in length) * fixed portrait mode in CreateCompatibleBitmap Regards, Greg
Pseudo terminal access for Microwindows terminal
: [Microwindows patch for getting pseudo-terminal access] : My sincere apologies for my previous message, which contained a patch : that wouldn't apply correctly. Somehow, in preparing the message, the : whitespace in the patch got garbled up. Mea culpa. : : Here it is again. Hopefully more correct this time. : : (Alert readers are warned that Greg's message may include a simpler : solution that I haven't tried yet..) Dan - I have applied my simple solution to the Microwindows mtern.c program. (Checking for 10 rather than 3 pty's, and using undocumented EIO error return) This allows programs to run while root under X11. I haven't heard from you whether a call to grantpt() is required for running when not root. I will leave my patch in, and yours unapplied (since we can still then at least share the code with ELKS) unless I hear from you. If your patch is required to run non-root, then we should add it, with an #ifdef ELKS so that the code to gain access to pty's remains (somewhat) portable. Of course, another option would be to add the getpt, grantpt, unlockpt and ptsname functions to the ELKS libc. Regards, Greg
RE: a.out -> memory hex dump??
: Preferably I would like the hex dump to be in the form below, but I am : flexible on that.. : 00a500:a9f20854c...90 : 00a510:2c51234..ff If you're going to build a hex format, you should use the well-known Intel hex format. It's similar to yours, but has a checksum associated with it. As well, many tools support this format. It's described at: http://www.wotsit.org/cgi-bin/search.cgi?binary Look for HEX or Intel HEX on that page. Regards, Greg
Re: self-compile bcc?
: -rw-r--r-- 1 root root 131 Sep 27 17:29 crt0.o : -rw-r--r-- 1 root root 5924 Sep 27 17:29 libbsd.a : -rw-r--r-- 1 root root83740 Sep 27 17:29 libc.a : -rw-r--r-- 1 root root83232 Apr 14 1999 libc_f.a : -rw-r--r-- 1 root root50544 Apr 14 1999 libc_s.a : -rw-r--r-- 1 root root51200 Apr 14 1999 libdos.a : # : : The library is only 84K at most, and none of the source files are any size : at all according to a find I ran over it. Why is the 512K limit a problem : at the moment? My mind isn't what it used to be. I guess I found the 512k problem when I was compiling up MINIX 2.0's libc.a, when I was screwing around with getting bcc self-hosting. Because certain sources required -ansi, I decided that bcc needed to compile ansi directly since unproto was a porting problem, etc etc. So, 512k _isn't_ a problem now. (But we should still fix it ;-) Greg
Re: ELKSibo - "Return to Witch Mountain"
: 2). Loader. Currently the psion stuff builds the whole kernel into an a.out, : which is then converted to psion '.img' and copied across. This is run as an : application, it then hi-jacks the processor, relocates and voila you're : running Elks. This means the 'loader' part of the code is always resident : and occupying space within the kernel code segment. I've been thinking : around how to remove it and loader the minimum. Again any suggestions? : The as86/ld86 combo supports multiple text and data segments, but they're all combined into one during ld86 load phase. However, just like libc.a does, you can use place code into higher segments to control it's loader order within the CS or DS segment. Segments 0, 1, 2 are text, and 3-14 are data, IIRC. The libc startup code uses segment 1 for some special initializer processing, but if you put the loader portion in segment 2, using: #asm .seg2 #endasm in the loader files, they'll end up last in CS. Of course, the special loader generated symbol _etext will be wrong if you plan on using it... but that shouldn't be a problem. The details of the above might be slightly off, check libc.a sources for sure. I figured all this out when writing my as86 .o file loader... : 3). The fonts are also currently located in the kernel (data I think). I : would like to remove them but need something to load them onto the : machine..Does 'a.out' or Psion '.img' support extra segments? See above... Regards, Greg
RE: self-compile bcc?
On Monday, December 06, 1999 7:28 AM, Scott Dudley wrote: : : Has anyone attempted to compile bcc with itself (8086 target)? I did so but : attempts to execute the binary on ELKS cause lock-ups. Stumbled across a psion : page some time back where author indicated that he had compiled bcc with an : 8086 compiler and it worked(?). I've been working on this and have bcc, as86, ld86 and ar86 running cross-compiled. But there's a bunch of memory limitation problems. bcc needs to be compiled with a special model, which I forget. It also has some built-in asm language stuff that needs hacking out. Would very much like to have a native : development environment on ELKS to avoid sneaker net. I fully support that idea. I've also got versions of libc-8086 and the minix libraries cross compiled, but the libc.a is too large for the ELKS file system, since ELKS has a filesystem implementation problem for any file > 512k Greg
Re: I can't compile this
: You had to be the wiseguy .. Cca. half of things you tried to compile in : do not work, do not exist, do not work in that particular combination or : are not tested enough. : : Next time be nice and go with default settings. Isn't Vladimir the guy who wants the bios console though? That still works doesn't it? Greg
RE: Some q's - Driving LCD Display within ELKS.
On Wednesday, November 24, 1999 6:36 AM, Simon Wood wrote: : Unless your hardware provides BIOS for driving it like a vga/svga you will : probably need to write (get some else to write) a display driver : specifically for it. No - first we can assume MDA as the lowest common denominator, not VGA. Currently, the most-used ELKS console drivers assumes a memory- mapped text screen at B800 or B000 (this is read from the BIOS at startup). There is, however, a BIOS console (which needs updating) that uses BIOS calls for character display. We could very easily enhance this BIOS console driver even to the point that the VT100 escape sequences emitted by the upper level console driver (that I rewrote to run a cooler vi) would work. In order to do this, we need the following low level calls (all provided by the BIOS, but could also be provided by a programmer for ELKS on non-BIOS systems:) o move cursor o put character o put character and attribute o scroll screen o clear screen (if none, for loop putting spaces) : : For the Psion stuff the screen is just memory mapped and I wrote a simple : driver to render text (all 8bit wide) directly onto it. This unfortunately : requires a font to be held somewhere in the memory (in the kernel code : segment for the psion though I'm thinking of moving this). Ideally, the Psion specific stuff could just have the above entry points and run under the standard console driver. In fact, it may be that way already. Thus, the Psion console port is just an implemention of the above interface only, not another console driver. : : I was thinking that it would be better to abstract a little from this and : try and get a 'framebuffer' style interface going. This would help : development on various platforms that don't have a vga/svga plug in card. Certain previous discussions on nanogui suggested strongly that the kernel not take on responsibility for any graphics operations. The only system call that Microwindows makes, for instance, is two ioctl()'s to tell ELKS that the VC is going into/out of graphics mode, but Microwindows handles the graphics mode conversions. ELKS on receiveing the ioctl's just prohibits a VT switch, since there aren't any mechanisms to tell Microwindows to redraw the window on switch yet, and not much memory. : Presumably all our frame buffer would need to do is simple text (console 8*8 : ??) and dots & lines (micro-windows). The problem with the framebuffer abstraction is that all that it really provides is an mmap()'d linear address for the physical video memory. Mmap() is not supported and never will be under ELKS, so really all you'd get from this would be that ELKS would return the address of the physical display, and all the graphics drivers would still have to be present in MIcrowindows, just like they are now for regular Linux and X11. Greg
RE: Compile help
: Do you think I should goto Dev86_0_14_3 : : ? You should _definitely_ move to Dev86_0_14_9. There are many patches and enhancements. 0.14.9 is also required when compiling with the new libc 6 unless you download my ar86 replacement. Greg
RE: Some q's
: Yes,I have questions about this as well. I wish to someday run ELKS on my : Tandy HD 1000 : laptop (8086 based) and its screen is LCD. Is anyone working on this, or : does anyone have any knowledge about it? The Tandy HD 1000 undoubtably has the bios wired up to use int 10h to draw characters on the LCD display. I suggest hacking the ELKS console driver to use int 10h. (there may already be a version of this completed, I think, called the bios console driver) Greg
RE: Palm Pilot & ELKS.
: > Personally I would like to see ELKS branch out over many processors (just : > like it's big brother), and hopefully conquer the 16bit world. Could someone give a paragraph describing the Palm Pilot's CPU/memory architecture? I thought it was a 32 bit processor, not 16 bit... Greg
Microwindows runs on X11
A big thanks to Tony Rogvall for writing Microwindows mouse, screen and keyboard drivers for X11. This means that X11 users can now develop Microwindows applications from within the X environment, running them as another X Window. Currently the size of the Microwindows application window is compile-time fixed, but it might be nice to allow it to be dynamically sized. Also big thanks to Martin Jolicoeur for contributing Makefile and build enhancements including a ./configure program and graphical make xconfig, as well as changes for StrongARM cross-compilation. I will be including these additions in the next cut, as well as getting a CVS repository up. Thanks for the contributions, this project seems to be gaining momentum... Greg
Web browser ported to Microwindows
I'm happy to announce that I've just heard that Opera Software has just ported their fully functional web browser to Microwindows! They have sent me a screen shot, which I will post. The port uses the Nano-X API, and runs in client/server mode. Full color support, palette mapping, jpeg and gif image and font support is working, as well as transparent images. It actually works! I will be rearchitecting the client/server networking code shortly, as the browser is running a bit slower than it should. I'm sure this is because of the extreme handshaking occuring for each parameter, which causes excessive context switches for any i/o. The total size of the browser codefile is 667k, much, much smaller than most web browsers. This means that it's possible that Opera could port the software to any of the newer palmtop or LinuxCE [MIPS, StrongARM or SH3] devices for browser access, since Microwindows now runs on these processors. For more information on Opera Software, see www.opera.com. Greg
RE: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
On Wednesday, November 10, 1999 10:45 AM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote: : ELKS 0.0.81 has been released and is available from:- Al, Does the 0.81 release have the /dev/pty's created on the root and comb images automatically so that the microwindows graphical terminal emulator will run? Greg
RE: elksemu and Red Hat 6.0
: No error on echo and I don't have a binfmt.o module, just binfmt_aout.o, : binfmt_java.o, and binfmt_misc.o. I insmod'ed binfmt_misc.o. elksemu is : located in /lib. ??? I;ve got it to work on 2.2.6. IIRC I forgot to insmod binfmt_misc. Make sure you're trying to run a small hello world executable, and test it with the file command. Also, remake the elksemu and personally check that it's copied to /lib. Look at the source, it's pretty basic. You may even overwrite the elksemu with a usermode echo program to make sure that it's even getting executed. Greg
RE: elksemu and Red Hat 6.0
On Wednesday, November 03, 1999 9:12 AM, Scott Dudley [SMTP:[EMAIL PROTECTED]] wrote: : : I tried setting up elksemu last night on my Red Hat 6.0 PC to no avail. It's : running the "canned" 2.2.5-15 kernel. I insmod'ed binfmt_misc and did the echo : to proc filesystem per the README in the source tree. When I try to run an : elks binary, I get the error: cannot execute binary file. : : What have I missed? Make sure that the "echo" doesn't return an error when executed. You might need to "insmod binfmt" before it will work. Also make sure that the /lib/elksemu or /usr/lib/elksemu (see source, I forget) is installed. Greg
Nano-X now documented
Ok, Halloween's over, I tried to scare all the kids with my Jason mask, but I don't think it worked. Anyway, I've finished the full documentation on Microwindows's engine, API, and the Nano-X API. It's available off the main Microwindows' web site at http://microwindows.censoft.com/ or directly at http://microwindows.censoft.com/microwindows_architecture.html Have fun and let me know anything else that needs to be added. Greg
Microwindows architecture explained
I have finished writing my first draft of extensive internal documentation on how Microwindows is designed and implemented. I've tried to be very complete and have covered all the device drivers and engine functions, and completed the Microwindows API as well. I've got it posted at http://microwindows.censoft.com/microwindows_architecture.html It is halloween over here, and it's getting late, so I don't have the Nano-X stuff documented, but I intend on having that completely documented as well. Take a look, hopefully this will help everyone using or porting Microwindows. Greg
Microwindows now has a web site
I've finally got down and created a web site for Microwindows, complete with FAQ. Thanks to Brad LaRonde for getting me going on this. Anyway, I've got the site up and running at: http://microwindows.censoft.com I am currently writing an architecture document to help explain how the whole thing is designed and implemented, to be used for general knowledge, as well as porting purposes. Give it a look and please send me any comments, good or bad! I'm also especially interested in links to other projects that people may find interesting. Greg
RE: Compiling Dev86 on Red Hat 6.0
On Thursday, October 28, 1999 10:33 PM, Scott Dudley [SMTP:[EMAIL PROTECTED]] wrote: : : I was unable to build Dev86 on Red Hat 6.0 and saw reference to same in the : ELKS FAQ. Good news! If you install the following RPM's, you can set : CC=i386-glibc20-linux-gcc and all is well. : : compat-binutils-5.2-2.9.1.0.23.1.i386.rpm : compat-egcs-5.2-1.0.3a.1.i386.rpm : compat-egcs-c++-5.2-1.0.3a.1.i386.rpm : compat-glibc-5.2-2.0.7.1.i386.rpm : compat-libs-5.2-1.i386.rpm It's my understanding that the only problem with compiling Dev86 with the newer libc6 is that the /usr/bin/ar program core dumps and that the FILE * = stdin; statement in one of the directories break. Is that what you've found? Rob has replaced the /usr/bin/ar with my ar86 in the latest dev86, I'm not sure about the FILE * bug. We shouldn't have to install all sorts of rpm's to get the dev86 package running. Greg
RE: some problems with ELKS 079
On Friday, October 29, 1999 1:39 AM, [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] wrote: : I'm sorry for having caused this confusion: the correct version of my (7) is: : : 7) (this is specific to xdos (dosemu)) the cursor keeps blinking at one : position on the screen, around (0,19). I can do whatever I want, everything : works but the cursor stays there. [the console version of dosemu does better]. : this problem is not present if I boot MSDOS. : : the first parenthesized sentence was included in the original message, but it : was not clearly linked to problem (7). : : so: ELKS does quite good under the PPC640, this problem comest to light if I : test it (ELKS) under the X version of dosemu (xdos). Perhaps you're running the gpm mouse driver, for X in another virtual console. Kill gpm by typing "gpm -k". It will run a text mode cursor in text mode, and a graphics one in graphics mode. gh
Re: some problems with ELKS 079
> > > 5) I compiled elvis and it does run. well, this is a bit of an exaggeration: > > undo doesn't work and sometimes I have to kill the process from my root > > session. after this, I get no more echo to the console where I was running > > elvis. I can do exit and login again. > > elvis is stalled mid port. I got it to the stage where it kind of ran, then > released it. The problems could be because elvis is not yet fully ported, > or it could be bugs in ELKS. In my last elkscmds submission, makefile changes were made so that the visual editors could be run under elksemu, as well as compiled directly on Linux. In certain cases, the editor's didn't run on Linux either. I ported a couple more visual editors in elkscmd, try them out as well. > + seg cs > mov ax, stashed_irq > or ax,ax > jz irq0_bios Al - so this was the floppy disk drive bug? I can see why it changed whenever a few bytes more or less were added to ELKS... Glad you found it! Greg
Microwindows v0.86
I have posted an update v0.86 to Microwindows/nano-X at ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.86.tar.gz This version completes a major effort, that of implementing off-screen drawing, as well as screen-to-screen blitting. The screen driver interface had to change to accomodate this, and I had to rewrite all the screen drivers. In addition, the blitting routines were written for 1, 2, 4, 8, 16 and 32bpp linear framebuffer devices, as well as the 16 color 4 planes vga (this was a royal pain...) The blitting uses a clipping region traversal algorithm so that blitting is always high speed, even when the destination window is partly obscured. This release also auto-detects most Linux framebuffer implementations, and should have a compiled in driver for it. In addition I have posted Linux, ELKS and MSDOS binaries, as well as screenshots for those that don't have the time: ftp://microwindows.censoft.com/pub/microwindows/SreenShots ftp://microwindows.censoft.com/pub/microwindows/LinuxExamples ftp://microwindows.censoft.com/pub/microwindows/ElksExamples ftp://microwindows.censoft.com/pub/microwindows/DosExamples The standard Microwindows demo is now a graphical terminal emulator, mterm. (No, it doesn't run vi yet, and it doesn't repaint it's screen contents, but it will ;-) This demo requires screen-to-screen blitting for scrolling. The 3d graphics demo now uses offscreen blitting to enhance (read no flicker) the display. Check it out. There is also some experimental full-blown region handling code included, which uses X11's y-x banding region algorithms. (This stuff is truly for those with extra time and brains). It is currently not compiled in, but can be included by replacing devclip.c with devclip2.c. In the next release, arbitrary multi-rectangle clipping regions will be available. I also plan on implementing separate clip regions from update regions for windows, with the system computing the update region as a subset of the clip region. Anyway, this sophisticated region handling is required for smart window painting as well as higher end graphics primitives. Eventually, this will also allow separate source and destination clipping for bitblit operations. Only destination clipping is working now. The next release will have a reorganized directory structure, allowing separate development of nano-X, widgets, core engine, and microwindows. I plan on moving the whole thing to a CVS soon. BTW, Microwindows now supports three processor families, according to reports emailed me. We've got i386, 8086, MIPS Vr41xx, and ARM families running ;-) Following is a summary of the ChangeLog: Version 0.86 - 28th October 1999 - [EMAIL PROTECTED] * merged framebuffer, elks and msdos vga 16 color 4 planes drivers * wrote vga bitbit routines (a herculean effort) * optimized bitblit by traversing window clip region * added experimental multi-rectangle dynamically allocated regions * wrote scrolling terminal emulator demo for microwindows * added WM_FDINPUT msg, WndRegisterFdInput call for terminal emulator * changed SCREENINFO struct, removed black/white, added bpp, planes * added offscreen (memory DC) drawing to microwindows * added BitBlt, CreateCompatibleBitmap, CreateCompatibleDC, DeleteDC * retired BOGL library, must use new interface for blitting * converted framebuffer, svgalib, elks and msdos screen drivers * (we need blit routines for herc and svgalib still) * major screen driver interface change, old drivers not compatible Greg
Re: ELKS 0.0.80
> I have checked through this, and added the full Linux features to kill(2), > and the call to getpgid(3) in killpg(3) is not necessary, as calling > kill(0, SIGNAL) automatically kill the current processes pgrp. > > Any thoughts on where the best place to put this is? Well, this stuff is supposed to be in Rob's libc code, for kill(2). But you may put up a patch for libc in a root ELKS subdirectory, until Rob patches the devkit. This is what I did for putenv(), which fixed some nasty shell behaviour. Greg
killpg
: > Also, on another note, in catching signals in Linux from the terminal : > emulator, I attempt to send them to the process group with killpg(). : > This routine under ELKS causes an undefined symbol getgpid() when : > linking. It appears there's an error in linux-8086 libc. : : That should be getpgrp() I think Whoops I meant getpgid(), finally.
ELKS 0.0.80
Al, Good to hear you've got another version of ELKS coming. I've completed the first round of getting an actual graphical scrolling terminal emulator running under ELKS. It's done. Except that the code to open the /dev/ptypX and /dev/ttypX fails. My version of ELKS (0.77) doesn't have these /dev/ entries. I need to know the magic numbers. Also, does version 0.77 support pseudo ttys? I wanted to make sure this support is complete in the 0.0.80 version, as Microwindows now supports a terminal emulator. (No it won't quite yet run vi, that's coming) Also, on another note, in catching signals in Linux from the terminal emulator, I attempt to send them to the process group with killpg(). This routine under ELKS causes an undefined symbol getgpid() when linking. It appears there's an error in linux-8086 libc. Greg
Re: CVS is back!
: Excellent! So, how are we getting on on the stability front? Can you actually : do anything with it yet? When do you reckon 1.0's coming out? I'm happy to report that my girlfriend's son (8 years old) came over and played landmine on ELKS (the only spare computer I wasn't using) for quite some time last night. So ELKS can compete with Sony Playstation at least for a while ;-)
RE: Dev86
: Ah. I have a problem building Dev86 where ar is crashing, and was : going to wait until I had more info (e.g. ar seems to be working : until the build gets to a certain point, then refuses to work with : the archive any more). How can I find out more about the problem : with ar that Greg reported? The /usr/bin/ar is broken with the latest linux releases when used to archive .o files for the dev86 kit. Download my replacement /usr/bin/ar from ftp://microwindows.censoft.com/pub/microwindows/ar I have submitted a new ar86 that Rob uses in his latest cut, 0.14.9, so that /usr/bin/ar is no longer needed... Greg
Microwindows plans
Now that I've got a palm PC booting Linux, I've had a chance to understand alot more about what's happening with the hardware/software on these devices. I think the first step for the graphics engine, MicroWindows, is twofold: support for the win32 platform needs to be based around the Win32 CE subset, which is no problem, and adding Xlib support so that the GTK+/Gdk tools can run on top of it.     There's quite a bit of work no matter which way we go, but MicroWindows is alot farther on the win32 CE front. CE drops quite a bit of win32 functionality and we could allow winCE programs to be compiled for the microwindows/linuxCE system and run without too much modification. There are quite a few custom controls to write, however.     On the Xlib front, I'm going to start studying the GTK+/Gdk implementation and see how much work would be required to get that to run on top of MicroWindows. Perhaps that should be called MicroX, unless we want to change the nano-X api.  I'd be interested in hearing which API's are more interesting, and whether many people have programs already written that would like to be ported.  Greg
RE: Dev86
On Friday, October 08, 1999 4:18 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : >: I believe there may be some glibc issues with it, but can't remember : >what. : > : > The potential glibc 6 issue is that no static initializations of FILE * xx : >= stdin : >work, these must be moved to main() : > : : YES that is the prob, on the line that it complained about it had a similar : line. How do I fix it? Has anyone got dev86 running on a RH 6.0 Box? : Like I said above, Tom. Read the message carefully. move the line like FILE *xx = stdin; from the global declarations of your program to the first executable statement of the main() function. : And yes I did look at the FAQ first, about 10 times, and did exactaly what : it said! : : tom : : __ : Get Your Private, Free Email at http://www.hotmail.com
RE: Dev86
: Can't really help much unless you can include a copy of the error output in : you mail. I remember Greg reporting a problem caused by a recent version : of ar no longer being able to cope with minix format .o files, A working /usr/bin/ar can be downloaded from my microwindows site This will be fixed in the next release of dev86, as I've ported a special ar86 that will be used with the *86 tools, and ultimately run on the target machine, and given all this to Rob. and : I believe there may be some glibc issues with it, but can't remember what. The potential glibc 6 issue is that no static initializations of FILE * xx = stdin work, these must be moved to main() Greg
RE: Dev86
: This is where things got bad, It just would not fininsh compiling dev86. It : stopped while it was compiling ld/objdump86.c, giving some error around : about line 17 (I think, can't remember the exact line). : : Its been so long since I compiled dev86 and I can't remember if it happened : the last time. Can anyone help? Al - Perhaps it's time we put the instructions for compiling dev86 in the FAQ. Or is it already? Greg
RE: Embedded and Real-time systems
I'm no expert here, but following are my $.02: : What sort of features are required for this type of system? It seems to me : that a filesystem is not all that important with no storage. Are device : drivers, interrupt handling and memory management the types of features : required? Having a kernel that can be shared with the std source would of course be nice. So I think we need device drivers. The filesystem stuff should be linkable just like the device drivers are. In regards to interrupt handling, most of that should reside in it's own arch-dependent file (much like it is now). If the interrupt controller changes, we don't want to hack much more than one file. : What type of API is the application code going to use? Is the UNIX system : API any use at all? : Of course we'll want to be able to use the same development tools, I would think. So it's quite convenient to have the libc code and the sys vectors that are already built in the dev86 stuff. That also allows the applications programmer to test stuff on linux as well as on the SBC board. : Are embedded applications run as stand-alone binaries, or do they get : linked into the kernel and run as kernel threads? With no filesystem, it's hard to "run" programs without writing a "null" driver (kinda like the one you hacked a while back) but seeing kernel threads would be nice. Then the std ELKS system could also use them Greg
RE: new version of nano-X/microwindows (not silly licence thing)
* wrote asm version of VGA driver for ELKS : : How much faster is this thing? Useable? It's definitely faster, and it works. I use it for the ELKS port, which runs on _slow_ systems. Greg
RE: Licensing summary
: That's the reason I thought we'd have to move David's code into seperate : files- because his code wants to go into files with his Public Domain : license on them, and the new code wants to go into files with the MPL on : them. No - this is specifically what we _dont_ want to do. David's license allows us to create derivative works and do what we want with it, providing that we leave his copyright notice intact. If we have to rewrite _any_ of Dave's code, I need to know now. This will greatly affect the Xlib project. It doesn't affect MicroWindows so much. : : > What are the semantics of a "conversion", anyway? : : You just redistribute everything under the new license. It would have to : be a total conversion though, because the GPL wouldn't allow some GPL : parts and some MPL parts, and I don't think it, or any improvements made : to the GPLed version could be converted back to MPL without explicit : permission of the author of the changes. Does this mean that the tree would split at this point? I plan on remaining the maintainer of the project, and don't want two trees. Greg
Licensing summary
On Tuesday, October 05, 1999 12:50 PM, Alex Holden [SMTP:[EMAIL PROTECTED]] wrote: : On Tue, 5 Oct 1999, Alan Cox wrote: : > This is going on far too long and round in circles. Greg and Alex - pick : > something, stick a license on it all , say so publically and be done. It : > does more harm now than whichever is picked : : Right, I vote for MPL with a "convert to GPL/LGPL" option, with David's : original code retaining it's current Public Domain license. Vidar has : already said he's happy with that. Greg? Yes. I think I agree. But I want to be completely clear on David's code. His original code retains his original PDL license. The code that's included in nano-X and/or MicroWindows is a derivative work, and is not subject to any terms other than his original terms: leave the copyright notice intact. In addition, the "convert to" would be strictly GPL, not LGPL. What are the semantics of a "conversion", anyway? Greg
RE: new version of nano-X/microwindows
: Speaking of projects .. I have few questions regarding 0.84 release of : mwin. : : 1: nano-x won't compile here with -O switch. It has to be some sort of : copt error (it does compile actually but doesn't assemble/link). This : can be solved by calling bcc without -O for nanox/srvfunc.c to be : compiled. I'll look into this. It works on my system... ;-) : : 2: where is Al's "terminal emulator" ? nterm ? did you manage to get it : woring ? : It's in there, but you must unset the client/server switch, and link in nterm.o. See the Makefile and INSTALL files. : 3: does world.c and/or nclock.c actually work on any ELKS system ? All the demos run on ELKS, including the nterm. If running world, you must supply the .dat file in the current directory. See world.c for details. Greg
At last - Microwindows/Nano-X Screenshots!!!
OK, Thank you everyone for the licensing input, I learned alot. Sitting in frustration at home last night, I finally wrote a little program that reads the framebuffer and generates bitmap files. So, I ran through all the cool demos that I've got going, and we now have screenshot gif files for microwindows, as well as nano-X landmine, world, and widget sets running... There still on ftp, but have fun! ftp://microwindows.censoft.com/pub/microwindows/ScreenShots Note: the next release will include the makebmp conversion program, as well as support for screen dumping... Greg
Licensing summary
Let me try to summarize what we need in a graphics system license: 1. We _must_ have: a. The ability to have private, proprietary drivers to be used (NDA's, and other commercial non-control issues) b. The ability to work with, communicate with, and be linked with, private, proprietary applications. (commercial software shops use our engine with their application; they'll never go open source, but still want/choose our engine) 2. We _would_like_to_have: a. All modifications to original files, whether they're enhancements or bug fixes. It'd be nice to have them back, but not required. b. A community desiring to better the project as a whole, by sending contributions to be included in the whole, whether they're original work, new drivers, or whatever. 3. We _must_not_have: a. The ability to use the graphics engine, lock stock and barrel, for whatever purposes are desired [It is this 3a that I can't quite come to grips with] please debate Greg
RE: Request for comments - Microwindows
On Monday, October 04, 1999 4:55 PM, Louis P. Santillan [SMTP:[EMAIL PROTECTED]] wrote: : Maybe those who have evil : commercial purposes should be punished, but they should not be completely : prejudiced against. I think the intent is to make the Nano/Micro series : a standard for small systems. nano/micro will never be a standard with an attitude against commercial interests. I'm certainly not against commercial interests. I'm very much into commercial interests. However, I'm not necessarily doing microwindows for money. I'm doing it for fun, to give back what I've taken from the community over the past 20 years, and I want to build a graphics system! Greg
RE: Stupid licensing thread (Was: Request for comments - Microwindows)
On Monday, October 04, 1999 4:51 PM, Vidar Hokstad [SMTP:[EMAIL PROTECTED]] wrote: : the near future I and another developer will be working : nearly full time on it, and we also sponsor another company to port a major : software product to NanoGUI. : : This is code that we contribute back. Correct me if I'm wrong: If we license LGPL _or_ MPL, it is not required to contribute any code back. If the _contributors_ to NanoGUI : regards prefer a restrictive licensing scheme over those contributions, : then fine. In that case we'll spend our time and money improving : another product instead, or license a closed source product instead of : spending or time and money on supporting an open source project. So we need a license that: 1) must or 2) should cause contributors to contribute code back. Which?
RE: Request for comments - Microwindows
: > We'd have to seperate the code which requires David's public domain : > license into seperate files to the code which is under MPL though. : : That is good practice. David wanted his original code to be totally : free. Lets make it easy for people to use it that way Alan, I thought you said that nano-X/microwindows was a derivative work, and thus another license can be put upon it. David's code has no restrictions on derivative works, as long as his copyright remains intact. Alex, your and my revisions are completely new work. We are debating a [L][GM]PL license for the derivative work. So - we don't _have_ to separate any code. David's original code is available on Alex's and my ftp server. Correct?
as86 .o file runtime loader completed
Al, I've completed the runtime dynamic linking loader produced by the 8086-based bcc, as86 and ld86 tools. This code allows the relocatable images produced by as86 to be loaded as shared libraries if desired. All export and import symbols are matched, and offsets relocated. Currently, it also allows for libc.a and other archive files to be searched, and modules loaded as well. The relocating loader also works for 32-bit object modules produced with the bcc -3 option. However, there remains a very serious problem relating to getting this to work in 16-bit mode. (I finally realized this damn near after completing the whole thing) Although I have it working for both 16 and 32 bit files now, I can't actually execute the code loaded for 16 bit modules. This is because I malloc() the data space for the code segment, but the code has to actually execute relative to the CS segment. Thus, we would need an additional system call, or the ability to write into a new process space in order to allocate code segment space and have it relative to the CS register. So, I'm not sure what's next. (It's been a very informative project, however... I can still run .o files created from bcc -3 in my native linux elf programs...) If we wanted to add some very _new_ design to the ELKS kernel, we could add the abililty for ELKS to load/unload modules, and the same loader code could be used for user processes as well. The reason we'd use the current .o file format is because we'd not have to write new tools. The ELKS kernel could load/unload drivers using the same mechanism that user programs use, which is cooler than the Linux kernel's implementation. Unloading modules is easy if there's a single import, but with multiple imports, it gets harder. Greg
RE: Request for comments - Microwindows
: Can you say what it is in *GPL that would make it unworkable for Screen : Media? : :: This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why : would someone choose to use it under GPL when they can use it under MPL? : I think it's clear that we can't go with just GPL. So the issue now is whether we should go with MPL or LGPL. Both permit proprietary code to be linked with the project. Is there a significant benefit to MPL that LGPL doesn't have?
RE: Request for comments - Microwindows
: I support having a partial Xlib implementation, but *not* if it affects : size and efficiency. : I completely agree. For instance, none of the Xrm* stuff would come in. OTOH, why not just call XOpenDisplay and XDrawString, rather than GrOpen and GrText? It would involve one more (usually NULL) parameter, the Display *. But most of the api would port easily. : I suspect it would be hard to implement a full featured API and maintain : a small size without deviating quite a bit from the Xlib API. It might : be worth a try to add at least partial compatibility. I think it's a good try. Just like when I reimplemented win32, I'm only going for the graphics stuff, not the whole damned world. Heaven's knows we don't want to create Gate's whole idiotic pig-big system all over again. On a more rational note, yes, the Xlib api may differ on certain items. Like color. We could use a much simpler color model than X. So the api isn't exactly Xlib, but it's as close. We try to keep the parameters the same, but don't have to match the internal Xlib data structures for the parameters. This is a trick I used in microwindows, if anyone's noticed. Greg
RE: new version of nano-X/microwindows
On Monday, October 04, 1999 1:32 PM, Araujo, Isaque G. [SMTP:[EMAIL PROTECTED]] wrote: : Would be nice if you had some screenshots of nano-X/microwindows running ! : Yes, it would be. Sometime ago this was discussed on this list, and IIRC, all that had to be done was that /dev/fb0 was read to get the bits, and then they need to be written out in some bitmap format... Perhaps that should be tonight's project... Or are there any volunteers? Greg
RE: Request for comments - Microwindows
: However, it does appear to kill the static model, but ONLY FOR NON-FREE : ROGRAMS. Free programs could still use the static model just fine, and : non-free programs could still use the client/server model, since the client : side is LGPL. : Well, we could always have LGPL for static model, otherwise GPL for server and LGPL for applications. If someone wants to develop a non-free program, and link it statically, we still let them
RE: Request for comments - Microwindows
On Monday, October 04, 1999 12:13 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : > which includes all of microwindows and all the enhancements : > to mini-X, can be easily licensed this way. But the nano-X : > project has a large core of GrXXX routines that were originally : > written by David Bell, and his license is completely unrestrictive, : > except that his copyright notice must still be included. So : : His license doesnt clash with the LGPL. The LGPL doesnt allow you to : remove other peoples copyright notices either : So even though David Bell said "Permission is granted to use, distribute, or modify this source, provided that this copyright notice remain intact" we can say that now his code is subject to another agreement, the LGPL? Doesn't the LGPL restrict more than the above? Also, can we have a GPL license on the server and an LGPL license on the applications? Can we have both even if we allow linked-in apps and client/server apps?
Request for comments - Microwindows
I am considering some bigger changes to the graphics engine project I've been working on the last six months. I'd like to get your comments before I go headlong into this. Following are some of the changes being considered: Move to Xlib reimplementation. I've been thinking that the proper way to go with the microwindows project is to build a close resemblance to Xlib, much like I've done with the win32 api portion. This would allow, for instance, with little effort, the graphics applications that currently use Gtk on top of Gdk on top of Xlib to be ported to all the systems that microwindows supports with very little effort. Also, the Xlib reference manual could be used for most instances to learn about the micro-X api. License under LGPL. All of the code I've written, which includes all of microwindows and all the enhancements to mini-X, can be easily licensed this way. But the nano-X project has a large core of GrXXX routines that were originally written by David Bell, and his license is completely unrestrictive, except that his copyright notice must still be included. So we can't downgrade his license to LGPL. This means that his code can't be used if this project goes strictly MPL or LGPL. One idea is to contact David, another is to rewrite it as Xlib. Reorganize source code so that micro-Win32 and micro-X can both be worked on simultaneously. Currently, the source is organized with win32 getting the "upper hand". The win32 reimplementation would be placed in a subdirectory from the engine code. The Xlib reimplementation would be placed in a subdirectory under the engine code. Thus, Xlib development could proceed much more quickly, without having to know anything about win32. In this way, the MicroWindows project goal could become "A micro-reimplementation of the Xlib and Win32 api's, catering to small size and speed of porting, on Linux[CE,86] platforms." Comments? Greg
new version of nano-X/microwindows
I've completed another version of nano-X/microwindows that takes care of most of the last two week's concerns on this list. Version 0.84 is now available at ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.84.tar.gz Thanks to Brad LaRonde and Vidar Hokstad for input and changes for this release. The major changes in this release are: o completely support client/server model for nano-X programs. o integration of truecolor support (thanks Brad) o integration of nanoWidgets (thanks Vidar) o support cross-compilation for MIPS linuxCE project (thanks Brad) o integrated bug fixes from nano-X-0.5pre3 For those with truecolor systems, it would be nice to check this version out, since I still can't run with truecolor. This version also compiles and runs the complete nanoWidget set from Vidar with a single toplevel make, so you all can check out what's new there. There are quite a few bug fixes with the client/server networking code, many calls didn't previously work. The make defaults to client/server builds now, although the linked application model can be built with a switch for debugging. Attached is the ChangeLog for this release Version 0.84 - 3rd October 1999 - [EMAIL PROTECTED] * integrated Vidar's nanoWidgets 0.1, changed color constants * integrated Brad LaRonde's MIPS LinuxCE port cross-compile changes * integrated Alex's nano-X-0.5pre3 changes except dir/filename changes * added support for 8 to 32 bit truecolor systems * reorganized Makefile for nanoX and linked/non-linked nano-X servers * reorganized Makefiles for gcc, bcc and other compilers * reorganized nano-X.h header file for client programs * fixed GrSetGCFont,GrGetGCTextSize,ReadArea,Area client/server bugs * fix bug in nanoX network select code for client attach * workaround for GrGetNextEvent in nanoX client lib * wrote asm version of VGA driver for ELKS * added optimized herc hline routine from [EMAIL PROTECTED] * added contributed terminal emulator demo for nano-X, (from Alistair Riddoch, requires linked server) Greg
RE: Anybody using this list?
: As this is an exe file, a windows based disassembler may be the best way to : work on it. If you would rather work on it under Linux, try ndisasm which : comes as part of the NASM package. It is a very powerful disassembler, but : some knowledge of the format of the file you are trying to disassemble. I : am not sure what the format of a .exe file is. Any pointers anyone? : The format of setup1.exe for the toshiba 1200 is an MZ header DOS executable. This is the original DOS format for .exe files, the other being .com files, raw binary images. Any DOS disassembler will work for MZ header files. The 16 bit windows file format is known as NE (new executable). This format uses a real-mode MZ header with a special value at offset 18h to indicate the location of the new header. Meanwhile, the windows 32 bit exe file is known as PE format, which is a modified COFF file. Following is the format of an MZ header .exe file: MZ EXE Format Intel byte order The old EXE files are the EXE files executed directly by MS-DOS. They were a major improvement over the old 64K COM files, since EXE files can span multiple segments. An EXE file consists of three different parts, the header, the relocation table and the binary code. The header is expanded by a lot of programs to store their copyright information in the executable, some extensions are documented below. The format of the header is as follows : OFFSET Count TYPE Description h 2 char ID='MZ' ID='ZM' 0002h 1 word Number of bytes in last 512-byte page of executable 0004h 1 word Total number of 512-byte pages in executable (including the last page) 0006h 1 word Number of relocation entries 0008h 1 word Header size in paragraphs 000Ah 1 word Minimum paragraphs of memory allocated in addition to the code size 000Ch 1 word Maximum number of paragraphs allocated in addition to the code size 000Eh 1 word Initial SS relative to start of executable 0010h 1 word Initial SP 0012h 1 word Checksum (or 0) of executable 0014h 1 dword CS:IP relative to start of executable (entry point) 0018h 1 word Offset of relocation table; 40h for new-(NE,LE,LX,W3,PE etc.) executable 001Ah 1 word Overlay number (0h = main program) Greg
RE: Anybody using this list?
On Wednesday, September 29, 1999 3:25 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : hi : : I've got one of those T1200's, prity old, now if I remember right, when I : got it it had a, (deep breath) ms-dos programm that changed the settings : that one would usually change in the bois. God knows where the prog came : from, but if anyone is interested, give me a shout. : I tried it. That program (named test.com) allowed the bios setting to change, but it was only active when MSDOS was running, so it didn't work.
RE: Anybody using this list?
> : > We need to turn off the T1200 auto-power-off mechanism, but I don't have : > a HW manual for the unit. : > : > Greg : : I have the original manuals that came with it here, if anybody wants : anything from them. Find the hardware I/O port to disable auto-power off.
RE: your mail
: Is it as simple as having a VGA card and a herc, and just writing to them : both separatly? I would have thought there would be problems with : initialising the hardware, and detecting which was present. I think it's this easy. the bios in some location states whether there are one or two monitors... : : If it is this simple, then adding dual monitor as an option to the dircon.c : driver should be quite easy. The only sticking point is that I don't have a : herc card, or a mono monitor. : Hmm.. I think a mono card costs about $7 now... Greg
RE: your mail
: That part of the process is now problem. The difficulty comes in writing a : driver which can talk to both cards at the same time. : what about using what someone suggested just changing 0xB800 to 0xB000 on the switch and leaving it at that, using exactly the same driver? Greg
RE: Anybody using this list?
On Tuesday, September 28, 1999 6:25 PM, Gregory Leblanc [SMTP:[EMAIL PROTECTED]] wrote: : 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? Ah, the T1200. I have one, and booted minix on it a while back, I think I tried ELKS as well. It booted and ran for awhile, until the damned Toshiba auto-power-off mechanism kicked in. then the screen went blank, and I couldn't get anything to happen until a full system reset followed by a reboot, then it repeated. We need to turn off the T1200 auto-power-off mechanism, but I don't have a HW manual for the unit. Greg
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... : :
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
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: 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: Elks progress
On Monday, September 27, 1999 11:38 AM, Louis P. Santillan [SMTP:[EMAIL PROTECTED]] wrote: : Where can we find the current version of NanoGUI/MicroWin? : ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.83.tar.gz Greg
RE: Another ELKS idea for shared libraries
: I am very interested by the : possibility of loading .o files as modules, both into the kernel and into : user applications. As a means of loading drivers in nanoGUI and microwin : this sounds great. I have very nearly completed the .o loader this weekend. It reads in any number of .o and .a files, and builds import/export symbol tables, and then loads any text/data segments that are needed, and relocates all the bits using segment or symbol relative offsets. I am currently working on some severe memory usage issues, relating to reading in libc.a. This is going to be cool! : : I am not sure this could be made to work usefully as a means to build : shared libs. It would still mean that the address space of the process : has to contain all the code and data of the library which eliminates the : possibility of sharing memory between processes, so the only advantage is : the size of binary files on disk, which is not much of a concern. : I've thought this through to some degree, and yeah, I kinda came up with the same thoughts, that we might only get binary file sizes down, which isn't much of a benefit, considering the work. There are several issues, though that need more discussion, because a dynamic loading technology could still considerably enhance the approach to applications development, in a good way. 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. Well, thats still not all that bad, because it means that ELKS could have different modules (including kernel modules) execute as .dlls rather than having everything always linked together. Portions of the kernel or other programs could be replaced by merely replacing the .dll (.o), rather than recompiling everything. I think this is one of the most basic features of newer, more advanced operating systems. What I'm working toward is adding developmental technologies, so that more advanced programming methodologies could be used in building applications for both linux, windows, and ELKS. This requires shared libs. For instance, the Microwindows goal of loading application code and data works nicely under linux, and it'd be nice to have it under ELKS. It is, however, alot of work rewriting all the tools for each platform. That's why I'm currently designing around bcc and as86, rather than rewriting them. Another big issue is that, in order to load modules, it would be nice to be able to load data and tell ELKS that we want that data to be thought of as a text segment. In addition, there is quite a bit of "temp" data (symbol tables, etc) that would be nice to free and have the image look like a normal text+data+bss. Also, there are issues with _end, etc for the C library. I think I have most of this sorted out, but it still will use alot of process memory. I think the development advantage is still there, however. Greg
RE: Elks progress
On Sunday, September 26, 1999 1:02 AM, Paul Khoury [SMTP:[EMAIL PROTECTED]] wrote: : I haven't really kept up too much on the list, just still recieveing mail for my : archive. I've seen some posts regarding microwin - is this sorta like a GUI for :ELKS? Yes, microwin runs both a Win32 api and an X-like API on ELKS. Both run in quite a bit under 64k. Currently, microwindows runs in about 40k and supports window frames, title bars, buttons, etc and client coordinate drawing areas. : Is there any network support? : I have a 3COM EtherLink (original 8-bit, RJ-45) that I'd like to use to hook up to :my existing : NT/OS/2/Solaris network. : No network support. Al's got a very basic unix sockets built but that's about it. Greg : Paul : :
RE: Another ELKS idea for shared libraries
: Errm, what's "Introl object file format"? You mean "Intel"? Well as86/ld86 : don't understand that. They use their very own format for *.o files. The Introl object file format is a format from an older hardware development system, named Introl. The name is documented in Bruce Evan's source code to as86 and ld86. I have decoded this format, and it of course has complete information for imported and exported symbols, as well as all code with relocation information. : : > How does this fit with your ideas of DLL's on ELKS? : This is all well and good but it doesn't appear to address the real problem : with 16bit DLLs. The fact that you're limited to 64k of text/data. Well, yes, all ELKS binaries are limited to 64k code and data. The cool part about the design I'm proposing is that only the linked-to symbols and their associated code gets loaded. This must still fit into 64k * 2, just like a statically linked version of the same. : : ELF DLLs are very good, and work very well indeed. They even have : facilities for hiding exported global symbols within the DLL so that : they don't interfere with your program (eg you can have an int called : "time" or define your own "tcgetattr" without problems) the ELKS "Introl" DLL will allow this also BUT you need : enough space in your memory map to load the entire library; the current : elks libc.a file is 80k. :-/ The difference between Introl and ELF format is that the latter was developed for modern operating systems that use mmap() mechanisms to map the binary into memory, and then page-fault in the code as required. In the ELKS format, all run-time required DLLs are searched for import symbols needed, and only the code segments with those symbols exported are read into process space memory. No mmap() mechanism is used, the down side is that the entire library may need to be read, but with code file sizes max'ing 64k and the library 80k, this is no big deal... The other difference between ELF and Introl is that the relocation info in ELF is in a separate section, which allows pure code sections to be mmap()ed in without any reads, whereas Introl format encodes code, data and relocatable info in the same section, and it must be read to decode it. The COOL thing about what I'm proposing is that we COULD have full-blown DLL's if we want, with complete automatic symbol resolution and minimal overhead. Dlopen()/dlsym/dlclose could also be implmented, if desired, although it poses a few more problems. We are still limited to the basic 64k segment limititations, and no ELKS kernel mods are required. Greg
Another ELKS idea for shared libraries
Al, I've been doing some serious research in the area of shared libraries and dynamically linked code/data segments. About a week ago I presented an idea for MicroWindows/NanoGui applications that would allow "applications" to be written for these graphical systems that could be linked and distributed separately and call the server without requiring the overhead of local unix sockets etc when making api calls. The cross-elf package is an ingenious piece of code that quickly allows linux, DOS and windows applications to load 32-bit relocatable ELF modules into the application's memory space, and allow dynamic linking to the mother application, as well as any other system shared libraries. I have finished a design that would allow identical codefiles for linux, windows and DOS (protected mode) and run identical binary nanoGUI and/or microwindows applications, all created one time using the gcc compiler on linux. The problem that I've been dealing with lately, is that of course, we must have ELKS support for this new scheme, and ELKS doesn't support 32-bit binaries. So, I've been investigating the ELKS 16 bit relocatable formats, and have come up with the following idea, which would allow user mode linking (the same as the ELF format is implemented - they're not actually loaded by the kernel) of dynamic libraries. In fact, properly done, ELKS could have loadable kernel modules and loadable user mode shared libraries that have the same format. Basically, the idea is that we use the Introl object file format as the relocatable format for shared libraries. This format is output directly by as86, and read by ld86. It handles 16 and 32 bit relocations, and completely specifies import and export symbols, required for dynamic linking. Data imports/exports are also handled. I will be writing an ELKS .o file loader that will be part of the microwindows subsystem loader, and I was thinking that this could be used to implement full blown shared libraries for any ELKS executables. An a.out with shared libraries would just link in a piece of libc code that calls this loader I will write and dynamically links the symbols that are required. The libc code would execute on startup and could be dragged in with a single symbol, specified by a new linker switch. I won't bore everyone with additional details, but I've thought this through in quite some detail, and have tested various portions of this concept on Linux and windows. How does this fit with your ideas of DLL's on ELKS? Greg
RE: Herc in Microwin
: 1. I have finished the optimised HERC_drawhline and . it works, its a : mirical! Great! : : 2. On a 386 16Mhz it takes 60 seconds to load on the original microwin on : the same pc with the optimized hercwin it takes 20 seconds. Both these times : include the reading the disk at the beginning. *much better* : : 3. Do I need a #ifndef statment do control the compliation of the optimized : and non optimized version? No - let's use your code : : 4. Once this is done how do I put the code in the microwin source? Greg? Send it to me and I'll include it in the distribution. Thanks. Greg
RE: Two Questions: minix_add_entry & man
: I have frequently experienced very bizare behavoir whenever the commandline : for a program gets very long, including hung processes, a hung system, and : some really messy crashes. I think this is the problem you are having with : wildcards. Somewhere the length of the commandline is not being checked, : and is overwriting some vital data. I have an entry for this problem in the : BUGS file in the source distribution, and on the website. : This problem is very related to the 64k-2 bug that I fixed in ELKS exec. All commandline argc/argv/envp stuff is copied above the initial SP, initial work by the Rob's libc code, and then by the kernel exec code. I looked through this stuff fairly carefully during that bugfix, and although complicated, it looked ok. I would suggest checking the glob generation code next at this point. Greg : Al :
RE: Linux on TI?
On Thursday, September 16, 1999 2:45 PM, Louis P. Santillan [SMTP:[EMAIL PROTECTED]] wrote: : I thought the Z80s were near 8088s or 188s...am I on Dr Pepper again??? : You've been drinking *way* too much Dr Pepper. <8bitprocessors>: 8080 -> 8085 -> z80 <16bitprocessors>: 8088 -> 8086 -> 80186 -> etc each processor added a few instructions, with the exception of 8085, which I think just had onboard cpu support. gh
RE: Herc in Microwin
: Bjorn Eriksson's code : void vert_line(US x1, US x2, US y, const BYTE color) : : This confuses me, why does a vert_line func have 2 "x" vals??? Or is a : general typo, wouldnt that be a horizontal line, like you say?? : As discussed last week on this list, vert_line is mislabeled, it should be horz_line (exactly how *did* that happen, Bjorn?? ;-) : I have not started the vertline func yet, but as I say the hline is nearly : ready. No need for an optimized vertline, there's nothing that can be done to the existing code to speed it up... : : This may seem like a silly question, please dont get mad, but, what do you : mean "the code you're running now is based on Jacob's code", baring in mind : I have never done a programming task in a group. Is it that I use the : #defines and stuff he has? : No - scr_herc.c was written by me based on Jacob's code. (thanks Jacob) I assume you're starting with scr_herc.c, the working hercules screen driver. Greg
RE: Herc in Microwin
: 2. How do I write to bytes to memory correctly. The origanal drawpixel uses : a pixel value c as well as the x and y cords. And therefor the hline uses : this c as well. : : It does:- : if(c) : ORBYTE_FP(dst, mask); : else ANDBYTE_FP(dst, ~mask); : : What is the pixelvaue "c" for? Who gave greg that code? Greg? In the MicroWindows/Nano engine, there are color values (COLORVAL) and pixel values (PIXELVAL). COLORVALs are now always 32 bits, and hold the RGB color we're looking to see. After translation by the palette manager section of devdraw.c, the color value is converted into a device-dependent PIXELVAL that is essentially an index into the video card's palette, *or* the hardware RGB value, if the card is truecolor. Translated, for you the pixelval is either 0 or 1 (black or white), since you're running a monochrome screen. So, if c == 1, then you OR a bit into screen ram, else you AND out (set to 0) a bit. Good luck. Remember, the code you're running now is based on Jacob's code, and we want to add the horizontal byte-filling code that Bjorn sent us. Greg :
new idea for microwindows client architecture
Gang, I've been studying a truly interesting piece of code lately, cross-elf v-0.2, which allows linux, windows and dos programs to load 32 bit ELF code sections compiled on linux and run them on other platforms. This is realized through cross-elf implementing an ELF relocatable loader, and resolving all imported and exported symbols. After having reviewed this great piece of work (highly technical I might add) I've come to the conclusion that it would be *perfect* for the multiple client/single server architecture that we've been discussing on the nanogui list. This solution completely solves the problem of multiple clients on one machine communicating with a graphics server on the same machine. I think that this is where microwindows/nano should be concentrating (let X handle the multiple machine cases for now). In particular, this solution has the following advantages: o high speed o client binaries are *identical* on linux, win32 and DOS! o no network overhead or network needed (even UNIX sockets) o ELF format fully supported by linux tools o all modules seperable into .so shared objects if desired (this means that the nano-X vs microwindows engine could just be separate .so files in the same server...) To get this to run on ELKS, I would have to modify the ELF loader to support 16 bit binaries (small task) and modify the bcc/ld86 tools to support ELF format or add the import/export info (very large task). With the appropriate implementation, this architecture would allow static-linking of clients if desired, which would allow the extremely small binaries microwindows supports today. I plan on building a strawman implementation of this, so that we can move towards separate "applications" in microwindows being loaded/unloaded as desired. Note that we don't have to allocate another process for each application. Ideally, only a thread. Comments? Greg
RE: missin timezone, and a bcc-cc1 error
: I cant seem to get elksemu to work though. after endless fiddling : with the binfmt_misc/register echo statmeent suggestion in the README, : I always get permission denied. the log file says: : : /var/log/messages:... modprobe: can't locate module binfmt-0420 : Make sure that the module is installed in /lib/modules/X.X.X
RE: Herc in Microwin
: 2. To verify one important thing, cord 0,0 = top left and 720,348 = bottem : right. Is the CORRECRT??? : yep : 5. This is my understanding of the prob, correct me if I have go compleatly : wrong, or have gotten the wrong idea. So at the moment a draw pixel function : is called many times each time altering memory "bit" by "bit". I have to : write a func that writes a byte at a time to memory, (8 bits) and in case of : the herc card 8 pixels. : Just use Bjorn's submission "vert_line" to this list. rename it properly though ;-) gh
RE: missin timezone, and a bcc-cc1 error
On Wednesday, September 08, 1999 5:01 PM, Henrik Sorensen [SMTP:[EMAIL PROTECTED]] wrote: : Hello : : I got past the FILE *in =sdtin; problem as a result from the input from this list. : : I've gotten a bit further. When compiling elksemu/elks_sys.c : I get an error in line 557 (and 580?) about the tz size is unknown. : I figured the problem was with the struct timezone. So I copied the /usr/include/time.h to the directory edited the file and added the struct from the elks/include/time.h and removed the reference to extern long int timezone. : This helped. : This is another C Library incompatibility. I thought I fixed this the last time I saw it. : 1) What have I done wrong in my installation since I had to do this. : 2) Wont there be a conflict at link time when there exist a 'struct timezone' and a 'long int timezone' ? : : After doing a 'make all' from linux-86, I tried doing an /elks/make (after doing make config; make dep; make clean.) : : But I get the error bcc: 'exec of bcc-cc1 failed' : bcc -D__KERNEL__ -O -I../include \ : -0 -c -o sched.o sched.c : bcc: exec of bcc-cc1 failed : bcc: error unlinking /tmp/bcc2248 : You must "make install" from linux-86 or the compiler isn't installed. Right now you have it running out of linux-86/ncc Greg
RE: get compile error compiling objdump85
On Tuesday, September 07, 1999 3:24 PM, Henrik Sorensen [SMTP:[EMAIL PROTECTED]] wrote: : Hello : : I'm just starting into the ELKS system. : I'm atempting a make in linux-8086, and I encounter the following error in the ld :directory : 'objdump86.c:19: initializer element is not constant' : : I'm running on a Linux Red Hat 6.0 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i686 : using GCC gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). : I'm using it out the box so to speak. : Any idea of what I'm doing wrong ? Or where I should go look ? : This problem is a screwup with the new C library, version 6. Basically, the time-honored FILE * constants stdin, stdout, and stderr are no longer constant. The offending line is: FILE *in = stdin; the compiler is complaining that stdin is no longer a constant. This problem cropped up in one of the ELKS cmd sources, but I was able to fix it more cleanly. This can be fixed by initializing the "in" variable as the first statement in main(), as "in = stdin" and changing the FILE * decl to "FILE *in;". Does anybody (Rob?) have any comments as to why the C lib guys could have done this? It's going to screw up alot of old programs. Greg
RE: [Fwd: syntax doc. about as86]
: There's another advantage with this means of conversion that I forgot : to mention. By using macros to retain compatibility with as86, it's : easy to do regression tests to ensure the semantics of the code have not : changed. As I convert the code to use my macros, I periodically run this : make rule: : : first:first.S : gcc -DUSE_AS86 -E -traditional -o first.s first.S : as86 -0 -b first first.s : cmp first first.ref : Ken - quite cute. I'm glad you posted this, as I have found myself wondering how to cope with the myrad of idiotic assembler source formats, and how to make sure that as I change continually one to another, when to know I've screwed up. God I wish that the NASM guys would have at least allowed some of the more obtuse forms of source input, so at least we could have used a single assembler, then worked on changing source formats... Greg
RE: BCC and ANSI C without pain
: Yes, your are correct. The body of the function should still be coded : in K&R style. But ansi headers can be used with the `features.h' : technique. : : > Certain ansi compilers revert to older K&R style parm checking : > (read: none) when the K&R decl style is used, even if the fwd : > decl is ansi. : : Shouldn't be a problem with the more popular compilers such as GCC or : Borland. They won't revert unless explicitly told to, and it's easy enough : to check if someone is unsure. : I'm not crazy about the __P technique, but it does offer a quick benefit, that described by Thomas. ELKS could have all it's prototypes specified using the __P technique, and leave all the function definitions untouched. This would allow parm checking by gcc without modifying much ELKS code, only headers. This would be a good step in the right direction. I still think that we should move to ansi at some point, though. Greg
RE: BCC and ANSI C without pain
: extern int sys_open __P ((char *filename, int flags, int mode));
:
:
: Then the ELKS kernel can be compiled with either GCC or bcc. There
: is *no need* for bcc to use the "-ansi" switch; it will just slow
: things down. And GCC can be used as a form of "lint" by enabling
: various warnings such as -Wall etc. (You may have to add -fnostdinc
: to the GCC command line and twiddle with the -I switch so as to
: use the proper include paths).
:
If I'm not mistaken, this still requires that the sys_open
procedure be coded as:
int sys_open()
char *filename;
int flags;
int mode;
{ ...}
Certain ansi compilers revert to older K&R style parm checking (read: none)
when the K&R decl style is used, even if the fwd decl is ansi.
Greg
RE: Bug found in sys_umount()
: I am not quite sure whether this is the best way to proceed. It would make : ELKS easier to find bugs in, but the -ansi option to bcc is not a very : clean solution to wanting to convert the code to ANSI. The other thing is : that it may make it harder to build the code natively under ELKS. There's no question that it would help with bugs significantly. However, there is currently a problem getting native ELKS compilation going. Currently, I've got bcc running under ELKS, but it's got problems. There's also < 512 bytes left in the code segment, and that's using the special compilation model, -Mf. Also, unproto is not currently ported. My first look at it confirmed it'd be a little work, and I skipped it. BTW, copt also isn't ported, and is work, so even without -ansi we've got work to do to self-compile ELKS. Another idea is that we could have a makefile pre-processor pass that would run unproto on all the source and create another entire tree that is K&R compatible. With this scheme, the master source would always be kept in ansi, but anybody could make a K&R tree if they have a linux box. I think we should consider this idea highly. : If we can be fairly sure that compiling ELKS with -ansi does not have any : significant downside, and we can run bcc natively under ELKS with ansi : support included, then I think this is the right way to go, but it needs to : be properly discussed before we make the decision. ELKS has enough bugs currently that it's probably worth keeping it check with a real ansi compiler. : Comments? Greg
