From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Sun, 12 Sep 93 15:28:44 EDT Subject: Linux-Misc Digest #125 Linux-Misc Digest #125, Volume #1 Sun, 12 Sep 93 15:28:44 EDT Contents: Re: NT versus Linux (Wolfgang Strobl) Re: NT versus Linux (Brandon S. Allbery) Re: Windows Pop Quiz Re: NT versus Linux (Brandon S. Allbery) user time inconsistant. (Ron Watkins) Re: Windows Pop Quiz Re: NT versus Linux (Eyvind Bernhardsen) BUG FOUND IN GCC!! (Joakim Rosqvist) Re: Problem installing LINUX with OS/2 2.1 (Bernard Wei) Re: BUG FOUND IN GCC!! (Damien Neil) ---------------------------------------------------------------------------- Crossposted-To: comp.os.ms-windows.advocacy From: strobl@gmd.de (Wolfgang Strobl) Subject: Re: NT versus Linux Date: Sun, 12 Sep 1993 10:49:04 GMT In <1993Sep11.231221.1535@microsoft.com> muzok@microsoft.com (Muzaffer Kal) writes: >In article strobl@gmd.de wrote: >> >> A design is always limited. In what way is 16M better than 1M? Supporting > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >this is a joke right ? No, it was a serious question. > Even today 16M of physical memory is enough for most of >the systems and apps. Well, this is quite similar to the argument twelve years ago: most of the systems in use have 32, 48 or 64K, and even today 640K of physical memory is enough for most of the systems and apps. >Also there is nothing implicit in the software architecture >of 68000 which creates a 16MB limit. The very same statement can be made about the 80286. >The only problem is that the chip has 24 address >lines and it is in no way reflected to the software. All the address registers are >32 bits. The moment you upgrade to a 32 bit address bus, you get all the 4G space. >> only a flat, linear address space is a limited design, when compared >> with segmented memory, IMHO. >> >> What was the first thing Apple did when they implemented the memory management >> for the Mac? Right: they implemented memory segmenting on the 68000, >Again there is nothing implicit in 68000 which requires such an implementation. But perhaps there was something implicit in the design for a software system like the Macs OS which requires such an implementation? The fact that Windows took a very similar approach could make one believe so. >This is because of the brain-dead design of Apple. They didn't want to use 32 bit >offsets and their compiler generates jumps only with 16 bit offsets so the problem >of 32K segments. They had to fit their whole system into one 64K ROM and some part of 128K RAM, if I'm not mistaken. Changing a system which consists mainly of pointers from 16 bit pointers to 32 bit pointers blows it up by a factor of two. Does the 68000 have 32-bit offsets for PC-relative jumps (which are a necessity for position-independant code)? >> quite similar to the 286s 64K segmenting, without bounds checking and, >but unlike a 8086 vs 286 comparison, there is no mode switching in 68000 family. >68000 doesn't force you into using only 16M, it keeps all the 32 bits addressing >info. Of course if you are dumb and use the top byte of the address for book-keeping >(against the advise of Motorola, saying that 32 bit processors are on the way) >then you deserve all you get and have to wait for "32 bit clean" software to run on >your Quadra. Well, I don't have a Quadra, I'm just waiting for 32 bit clean software to run on my Windows NT machine :-). >Also 286 forces you into only these 3 segment cache registers at any time and only >8K segment tables. There are FOUR segment registers, and the 8K LDT/GDT limit is just as invisible to ordinary application programs as the aforementioned 24 bit adress lines limitation. In addition, there is nothing in the architecture which prevents the CPU from caching more than what's actually loaded into the four segment register. >So at any point in time, your window of the world is limited to >196K of your all possible space and changing any of these segment cache registers >takes MILISECONDS. (maybe tens of miliseconds). A LDS takes 21 clock cycles in protected mode, three times as much as in real mode. >So the brain-dead segmented architecture >of 286 is not very usefull. Calling something bread-dead doesn't convince me much. An architecture which is limited to segments of less than 64K bytes size is limited to memory sizes of a few MBytes at most, to be usefull. So perhaps Intel should have had built long segments into the 80286 instead of keeping that for the 80386, where it came to late, IMHO. >I agree that hardware bounds checking maybe usefull but not >with the limitations of 286 (64K size and only 3 caches); Agreed. >maybe not even with 386 (which only >solves one of the problems (This requires another discussion: In x86 family, all the new >modes of the CPU (286 protected mode and 386 32 bit mode) are all incompatible with >previous modes. On the other hand, it is possible to have the very same code run successfully in real *and* protected mode - demonstrated by the many Windows 2.x programs which run on Windows 3 without modification, in protected mode. >You can't run some real mode sw in PM and you can't even switch the stupid >286 back to real mode without hardware resetting the thing. But it was possible to write real mode software so that it runs well in protected mode - that's more important, IMHO. The stupid oversight of not leaving a door open back into real mode dosn't say much about the overall quality of the CPU architecture. >I think nobody can argue that >the x86 family of processors was the worst problem we have had in the last 10 years.) Aren't we doing this just now? :-) Anyway, I'd argue that Intel processors have a lot of problems and design faults, segments limited to 64K being one of them. But segmenting itself isn't a design fault, IMO. Just to the contrary, it nicely solves a lot of software problems (relocation, reentrancy, multiple instances, code sharing) which have to be solved by resorting to various kludges on flat memory designs. There is only one thing which really annoys me about the Intel processors: they can't virtualize themselves. A capability like this can solve a lot of problems, as demonstrated by IBMs VM system. -- o ( Wolfgang Strobl Wolfgang.Strobl@gmd.de (+49 2241) 14-2394 /\ * GMD mbH _`\ `_<=== Schloss Birlinghoven, P.O. Box 1316, | #include __(_)/_(_)___.-._ 53731 Sankt Augustin, Germany | ------------------------------ Crossposted-To: comp.os.ms-windows.advocacy From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: NT versus Linux Date: Sun, 12 Sep 1993 13:42:39 GMT In article <1993Sep11.231221.1535@microsoft.com> muzok@microsoft.com (Muzaffer Kal) writes: >Again there is nothing implicit in 68000 which requires such an implementation. >This is because of the brain-dead design of Apple. They didn't want to use 32 bit >offsets and their compiler generates jumps only with 16 bit offsets so the problem >of 32K segments. Well, no. The 68000 was only capable of 16-bit (not 32-bit) relative jumps, and Apple was trying to simulate position-independent code. So they used the 16-bit relative jumps, resulting in 32K "segments" (since the jump offset is signed, 32K comes from the inability to jump from the first instruction in a segment to the last if the segment is > 32K). The *idea* was laudable: position-independent code can be subject to garbage collection (as long as you're not *executing* a segment when the GC kicks in, the segment can *move*! Many garbage collection strategies work much better/ more efficiently when large parts of the GC'able address space aren't locked at fixed addresses). Apple would have done better to acknowledge that it wasn't going to work all that well in the real world, though. >(against the advise of Motorola, saying that 32 bit processors are on the way) It was against Motorola's advice in the 68000 databook I used to have, which was released in '76 or thereabouts. Apple echoed Motorola's advice in their own Mac programming documentation... but some of their own programs were the worst offenders. Stupid programmers get what they deserve. ++Brandon (*very* ex-Mac'er) -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ Crossposted-To: comp.os.ms-windows.advocacy From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Windows Pop Quiz Re: NT versus Linux Date: Sun, 12 Sep 1993 14:07:58 GMT Is this flamewar *still* going on, or am I the victim of a net.timewarp? In article <26uv1q$f9r@news.u.washington.edu> tzs@hardy.u.washington.edu (Tim Smith) writes: >Ted wrote: >>Basically, the salient aspects of operating systems that I can pull >>out of this is that an OS is a collection of programs that: >> 1. Manages resources at the hardware level. >> 2. Provides access to I/O devices and I/O time. > >OK, Windows does this. MS-Windows does *part* of this. DOS does the rest. I have, however, reached the conclusion that this is spurious. Traditional definitions of "operating system" break down when applied to the results of modern OS development, in particular to true microkernels like Mach 3.x. They also get fuzzy, as mentioned before, in the presence of virtual machines; although you can make them work by claiming that VM/SP is a virtual machine and CMS is an operating system, to most people --- including programmers who don't work on the virtual machine directly --- the distinction looks rather specious. (It was much clearer when CMS could still be run standalone, before it was modified to require VM/SP.) My own opinion on the original subject of the debate is that DOS+MS-Windows is an operating system; MS-Windows itself is *not* an operating system [!!!PLEASE READ ON BEFORE FLAMING!!!], but rather a loadable "personality module" for DOS, which *is* an operating system by most definitions. This is a tricky proposition: IBM's upcoming Workplace OS will have loadable "personality modules" for AIX and OS/2, among others. Will those "personality modules" be operating systems? Using the reasoning above, they will *not*, and I would defend that interpretation. Workplace OS will require that resources be shared between all programs regardless of the personality module under which they run, so ultimately resource management is performed by Workplace OS, while the "personality modules" merely provide interfaces to the Workplace OS; therefore Workplace OS is an operating system but the AIX and OS/2 modules will not be. In this light, is calling MS-Windows a "personality module" in this sense all that bad? >> 5. Schedules and protects processes from one >> another. >> >>With regards to this definition, is Windows an OS? No. Is DOS > >Windows does schedule and protect, so #5 is met. Which item do >you find not met? Does MS-Windows actually insure that each process does not have access to any other process's pages? How about the system's pages? (I'm not needling anyone, I honestly don't know. Previous versions didn't do this, but that says nothing about the current version.) If we are using the strict technical definition of "scheduling", MS-Windows does scheduling. *Scheduling is not multitasking, it is an aspect of multitasking*. Does the definition of "operating system" being used distinguish between pre-emptive and cooperative multitasking? MS-Windows does not pre-emptively multitask its applications (but it does pre-emptively multitask DOS applications) but it 8does* schedule them. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: ron@argus.lpl.Arizona.EDU (Ron Watkins) Crossposted-To: comp.os.linux.admin Subject: user time inconsistant. Date: 12 Sep 1993 17:25:55 GMT I have been working with the system call 'times' which is suposto return the user and system times in a buffer. Well, I have trying to characterize a convolution routine for image processing. I have noticed that when I surround a piece of code with two calls to times and subtract the results that I get a time which is significantly larger than the user time reported by the time shell command. Im using the user time from the structure tms as indicated by the manual page. The times reported by times() are about 80% larger than the user time reported by the time command. I have converted the time to seconds by dividing by 60. Can anyone shed some light on my problem? Which is more accurate, and why the difference? Ron Watkins -- Ron Watkins [ron@argus.lpl.arizona.edu] / /~~~~) / 931 Gould-Simpson / /____/ / University of Arizona / / / Tucson AZ. 85721 -- (602) 621-8606 (____ unar & / lanetary (____ ab. ------------------------------ From: eyvind@Lise.Unit.NO (Eyvind Bernhardsen) Crossposted-To: comp.os.ms-windows.advocacy Subject: Re: Windows Pop Quiz Re: NT versus Linux Date: 12 Sep 1993 17:42:42 GMT In article <26uv1q$f9r@news.u.washington.edu>, tzs@hardy.u.washington.edu (Tim Smith) writes: > Ted wrote: [...] > > 4. Provides a file system and command language. > > (whether keyboard or mouse based). > > Now it gets tricky. What does this mean? For example, if I run Unix > on a diskless workstation connected to an NFS server, is Unix still > an operating system? It's not directly providing the file system. Doesn't matter, because if you connect a disk to that same workstation, there will be a filesystem. You're talking about one specific case of a Unix system where you're simply not using the supplied filesystem, whereas there's only one Windows, which always goes though DOS for filesystem calls. > Note that what Windows does is similar, except that rather than an NFS > server across a network, the file system is handled by DOS running in > a V86 task under the control of Windows. Yeah, but Windows doesn't have the ability to handle its own filesystem at all. Your "diskless workstation" does. > --Tim Smith -- //| Eyvind Bernhardsen | eyvind@lise.unit.no // | | \\ //--| Finger me for my | Amigoid and Linux advocate. \X/ | public PGP key :) | Save the whalers! ------------------------------ From: dvljrt@cs.umu.se (Joakim Rosqvist) Subject: BUG FOUND IN GCC!! Date: Sun, 12 Sep 1993 18:09:21 GMT I hope I`m not making a fool of myself now, but try compiling: #include void foo(flyt,heltal) float flyt; int heltal; { printf("heltal=%d\n",heltal); } int main() { foo(1,2); exit(0); } To my knowledge of c, this should output "heltal=2", but I usually get something like -143088992. I`ve found that the problem goes away if I either 1) call foo with "foo(1.0,2);" 2) declare the types ansi-style: "void foo(float flyt, int heltal)" 3) declare foo as "void foo(heltal, flyt)" [gcc 2.4.5, libc 4.4.1] ''' /Joakim Rosqvist, $DR.HEX$) Email: dvljrt@cs.umu.se (o.o) =========================================================oOO==(_)==OOo===== Linux - out to fix what Windoze MS'd up. ------------------------------ Crossposted-To: comp.os.os2.setup,comp.os.linux.help,comp.os.os2.misc From: gwo@fraser.sfu.ca (Bernard Wei) Subject: Re: Problem installing LINUX with OS/2 2.1 Date: Sun, 12 Sep 1993 18:20:54 GMT leij@mentor.cc.purdue.edu (Jason Lei) writes: >I was trying to install LINUX (the latest SLS release) on a disk where OS/2 >2.1 has been installed. When I tried to format the linux partition with >mke2fs, error always occurs. The following is how I did it (according to >the instructions in OS/2 manual and LINUX faq): >1. installing OS/2 2.1 and making the following partitions on the hard > disk (405 Mb IDE drive) with the OS/2's fdisk: > a. Boot manager: 1 Mb > b. Linux partition: 120 Mb (on or not on boot manager menu, > unformatted) > c. DOS/WIN partition: 50 Mb (on boot manager menu, FAT) > d. OS/2 partition: 80 Mb (logical partition for OS/2 boot, HPFS) > e. OS/2 partition: 150 Mb (logical partition, HPFS) It is better to have the partition this way: 1 DOS/WIN 50M 2 Lunux 120M (unformated) 3 OS/2 80M Logical 4 OS/2 150M Logical 5 Bootmanager 1M Unlikely this is the cause of the problem, but putting bootmanager at the end of your harddrive is a good practice, since the drive need to move to the furthest part of your HD only once. >2. installing DOS 6/WIN 3.1 > (Every thing was fine to this point) >3. installing LINUX: > a. using OS/2 fdisk to set the linux partition as installable > b. rebooting from the LINUX installation floppy disk (SLS a1) > c. using LINUX fdisk to change the linux partition ID to 83 > (for LINUX Ext) (Is id 83 a right choice?) > d. rebooting or skipping reboot (which made no difference) > e. mke2fs -c /dev/hda3 123060 (hda3 is the LINUX partition > prepared by OS/2, 123060 is the size in block shown from > the LINUX fdisk table) Try adding LINUX partition in you bootmanager as primary partition and boot LINUX partition during bootup. When prompt with SYS message, CTRL-ALT-DEL with your linus boot disk in your drive. Hope this works... I was thinking in the line that linux installation doesn't regconize the "installable option" of fdisk os/2. >Finally, I got "mke2fs: Unable to find a block for the inode table." >Did I miss something? Any help would be appreciated. >My system is a 486 DX2-66 with 16 Mb RAM if that helps to clarify. I've got 486-33 16M, 325M HPFS, 202 FAT. No linux installed though... might try that after I've gained more unix experiences. :) Hopefully at that time you'll be a great help, hang in there. >Jason -Bernard >-- > Jason Lei > Horticulture > Purdue University > West Lafayette, IN 47907 ------------------------------ From: damien@b63519.student.cwru.edu (Damien Neil) Subject: Re: BUG FOUND IN GCC!! Date: 12 Sep 1993 18:53:11 GMT In article , Joakim Rosqvist wrote: [Program example deleted] This is not a bug. When you call foo as foo(1,2), you are passing two integers to foo; due to C's weak type checking, this is possible. Calling with foo(1.0,2) passes a float and an int, which is what foo expects, so everything works fine. >I`ve found that the problem goes away if I either > >1) call foo with "foo(1.0,2);" Right; this passes the first argument as a float. >2) declare the types ansi-style: "void foo(float flyt, int heltal)" By prototyping the function, you are (I think) telling gcc to use strong type checking on the function. This is a good reason to always prototype your functions. >3) declare foo as "void foo(heltal, flyt)" I'm not certain what you mean by this, but I think you are forcing type checking as in #2. Problems like this are one of the reasons Linus wants to use C++ to compile the kernel; the problem you pointed out cannot occur in C++, due to the strong type checking. Disclaimer: I am not a C guru; the above is my understanding of the language, and could easily be wrong. -- Damien Neil CMPS/EEAP "Until somebody debugs reality, the best damien@b63519.student.cwru.edu I can do is a quick patch here and there." dpn2@po.cwru.edu Case Western Reserve University - Erik Green ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.misc) via: Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Misc Digest ******************************