Re: [fd-dev] DosEmu/Linux (was:Microkernel architecture)
Aitor Santamaria Merino wrote: I am not interested in this project for the moment, sorry. (sorry, I rephrase in case I was not correctly understood: In case my previous sentences could have given the impression that I am interested at this moment, I am not, sorry!) Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] [OT] Microkernel architecture
Hi, Something interesting! Now I remember where I took my information from: Undocumented DOS, the times of NT4 came later, I guess ;-)) Aitor On Wed, 2002-12-04 at 10:34, Aitor Santamaria Merino wrote: And I'll admit that I don't know much of the internal structure of NT, but I'm pretty sure that at least until 4.0, you could have device drivers that would run in kernel mode, which would be indicative of a monolithic kernel. Perhaps you misunderstood what I meant? (Just asking 'cause I know that under the best circumstances I can be cryptic sometimes, lol). No, but I believed that drivers in WinNT run in usermode (ring3) whereas in VMM they run at ring0, or at least, they have IOPL0. Windows NT 3.1 through 3.51 ran drivers in user mode, Windows NT 4.0 and later run drivers in ring 0 for performance reasons. Microsoft used to beat OS/2 up over the fact that OS/2 2.0 the drivers ran in ring 0 and so could crash the kernel, but they switched when as a server 0S/2 out performed them. NT was originally headed up by the guy who headed development VMS for Digital Equipment Corporation, so there is some similarity there. Anyway I've had enough of this thread. Regards, Paul _ Horas ilimitadas para leer y enviar correos con Tarifa Plana Wanadoo ¡¡ desde las 3 de la tarde!! Compruébalo en http://www.wanadoo.es/acceso-internet -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^^=== This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^^===
[fd-dev] [OT] Microkernel architecture
Minix is based on a microkernel architecture. Linux uses a monolithic kernel instead - and this inherent difference of architecture caused that by now well known fall-out between Tannenbaum and Torwalds, remember? No wonder thus that when in March 1994 version 1.0 was presented at the University of Helsinki, it was a totally different operating system from Minix. Has anyone tried GNU-Mach and GNU-Hurd? I didn't have time to have a look myself, but I am willing to see a replacement of Linux kernel where one does not have to recompile, for example, to activate the FrameBuffer, to add devices or to many other things (I admit I haven't read much about the PAMs). NT is microkernel too, in my understanding it's a little advantage over Linux at this moment (?). Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: AW: [fd-dev] [OT] Microkernel architecture
Hi, Jensen, Gerard wrote: Has anyone tried GNU-Mach and GNU-Hurd? At a version level of 0.2? A pitty ;-) NT is microkernel too, in my understanding it's a little advantage over Linux at this moment (?). Woah, hang on: NT uses a modified microkernel. Process Manager and Virtual Memory Manager for example are not seperate processes (as they should be in a true microkernel architecture) and communicate using function calls instead of messages. Is this that you describe happening under the mask of the DLL calling stuff? In my understanding, calling a DLL involves that the system is loading the module (if absent) then applying the relocations. I seem to recall that KERNEL.DLL simply calls a series of funtions on certain interrupt (whose number I can't remember) (protected mode, of course), which I seem to recall it's (part of /the whole of) NTKRNL. Is this the module that you mean, having both PM and VMM? Advantage: better performance (pretty relative value if you look at NT though...). Disadvantages: when last did you have your blue screen of death? Ages To be honest, with XP the PC has only hang twice, in both cases running a DOS app in full screen mode. I noticed that the system wasn't really hung, but I just couldn't switch to the API (nor Winkey neither Ctrl+Alt+Del worked). There you go. Shouldn't happen if it really was a microkernel... Actually I am impressed of its stability, comparable with the most recent versions of Linux (or am I mislead?). Nothing to do with Win98, for example. Even networking with NetBEUI, that with Win98 was a nightmare, seems to work ok... NT showcases that while the microkernel architecture sounds good with its modularised design, overhead leads to a lack of performace, so in all practical ways you probably are not exactly going conform to the microkernel architecture. And as that introduces back the problems you wanted to avoid, question is how far you will get with a pure microkernel architecture for your OS? Look at it this way: although Hurd has been developed since 1983, we are at a yet not very usefull version 0.2 now. Linux is being worked on since 1991 in comparison... To me this looks as if the microkernel architecture is an idealistic dream that just lacks that knack of practicality. But you're right, it *WOULD* be cool, if it'd work fast enough to be practical. Well, I hope there are intermediate solutions ;-) When I first installed Linux, X server didn't work (as usual, it never works well for me), imagine when someone told me I had to recompile the OS kernel !!! I like DOS despite its limitations. Some say that DOS is monolothic, but I can't understand this, bearing in mind that there are loadable device drivers, and many other stuff that is plugged by hooking interrups. I tend to consider that Interrupt/Functions is the message passing system of the realmode. The modularity could be proved perhaps by looking at what VMM did, it can replace some modules (even file management, with VFAT/VREDIR/VCACHE/etc) with some others... Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] [OT] Microkernel architecture
Arkady V.Belousov wrote: X-Comment-To: Aitor Santamaria Merino Hi! 4-äÅË-2002 13:15 [EMAIL PROTECTED] (Aitor Santamaria Merino) wrote to [EMAIL PROTECTED]: ASM NT is microkernel too, in my understanding it's a little advantage over ASM Linux at this moment (?). This (NT is microkernel) is only marketing hype. Hmmm... perhaps you are right, but so far Gerard Jensen's argument has been the most convincing. Do you have any other in mind, other than desiring that an OS that one produces sounds cool (and Gerard's)? Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^^=== This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^^===
Re: [fd-dev] [OT] Linux vs. BSD (was:Dosemu)
Simon Waite wrote: On Wed, Dec 04, 2002 at 12:55:26PM +0100, Jensen, Gerard said this: Linux is a rewrite of BSD. No, Linux is rewrite of Minix. [snip] No, Linux is a bit more than just a rewrite of Minix... ;-)) Or would you call OS/2 a rewrite of Windows 3.0? No, I'd call NT a rewrite of OS/2, and Windows 95 a rewrite of windows 3.11 Hmm. What was rewritten? The operating system was retouched a bit, and the graphical user interface a lot, but rewritten is not the word that I'd use ;-) Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] [OT] Linux vs. BSD (was:Dosemu)
Eric Auer wrote: OS/2 became a full-blown OS with a GUI around 1994, and it feels like a logical extension of DOS, adding GUI and multitasking. In 1994/1995, it was unclear whether OS/2 (better design) or Windows 95 (better marketing) would win the market. Things went horribly wrong, so almost everybody forgot about OS/2 :-(. It is unfair to compare OS/2 to Windows95. Please compare OS/2 to WindowsNT. Both are equally logical extensions, but for me the most logical is the VMM... Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] Enquiry: Update packs
Eric Auer wrote: Hi Aitor, you did not get the point... when you zip 100 files that are the same, the zip will be 100 times some size. However, when you use an UNCOMPRESSED zip, then the file will basically contain 100 times the same data structure. TAR is in principle the same as an uncompressed zip, but it is more UNIX while zip is more DOS. Yes, I knew this. However, we are talking about the resident size it will take in your harddriver after it has been installed. I am not trying to discuss the reduced/full issue. Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] DISPLAY CON?=
tom ehlert wrote: One could at least think of having multiple console drivers residing concurrently in a system, say CO80: and BW80: connected to different video systems and screens, and CON dynamically assigned one can *always* think of something, that would break something else. but with this kind of thinking, FAT16 would never have been presented to users (there might be drives larger then 1 Gb ...) BTW: I have a dual monitor configuration the second IS HGC I USE the hercules card - nearly every day I NEVER EVER got even the idea to install a DOS driver for that. I'm VERY happy to have a HGC card (and minitor) IMO, I prefer working 2003 for 98% all cases over might work in 2010 - eventually (if I'm not too busy) sorry for being harsh, but these 'one could think of' messages effectively STOP all useful work. Well, just a bit of positivity: at least it opens your mind to other possibilities, not meaning that they are going to be implemented in the near future. For example, I am conscious that DISPLAY should be a device driver that should parse files in a format being part of a CPI file, but if I had implemented this, I wouldn't have released any DISPLAY yet. Well, just it's nice to know even if just for information... (my opinion). Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] DISPLAY CON?=
Matthias Paul wrote: DEVICE=DISPLAY.SYS co80:=(ega,437,(6,3)) DEVICE=DISPLAY.SYS bw80:=(mono,(437,161),0) Interesting... understood. Well, this means that if a user makes a mistake like: DISPLAY CONN=(EGA,437,(6,3)) then it won't prevent DISPLAY from loading, but it won't work ;-) The : I assume it's optional Many times it appears, many others it doesn't. (and a silly comment, the : after the driver name makes your commandline look as if the := were the Pascal assignment operator ;-)) Hey, now that I notice, I'll have to review in the documentation (possibly in your long messages about internationalisation) what is meant by (437,161) At a first sight, the device to be replaced is single, the codepage should be single too (?). Note, that (unfortunately only) the DR DOS 6.0+ PRINTER.SYS driver supports multiple drivers in one go as in this example: DEVICE=PRINTER.SYS lpt1:=(1050,367,12) lpt2:=(4201,850,2) lpt3:=(5202,437,2) The advantage is that the code will be shared between these drivers and only the data is kept separate for each of them, resulting in a significantly reduced memory footprint compared to the usual sequence of: DEVICE=PRINTER.SYS lpt1:=(1050,367,12) DEVICE=PRINTER.SYS lpt2:=(4201,850,2) DEVICE=PRINTER.SYS lpt3:=(5202,437,2) So, at a later stage (not now!), it might be worth thinking about adding something similar to DISPLAY.SYS as well: DEVICE=DISPLAY.SYS co80:=(ega,437,(6,3)) bw80:=(mono,(437,161),0) Right A wish for the future, for a far future I guess :-) As another sidenote, under DR-DOS 7.02+ you can use the [D]CONFIG.SYS PRN=0,1..3,4 and AUX=0,1..4 directives to change the defaults. The main advantage of this being implemented into the DOS BIOS is that it required zero extra memory compared to a non-enhanced system (where you would have to overload drivers or hook into the System BIOS interrupts for a similar effect). I have seen something similar in the Waite group's book on DOS drivers, in the PRINTER driver, which is a driver for a printer in ANY port (or for several printers) you use IOCTL commands to change the port. Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
[fd-dev] Enquiry: Update packs
Hi, For a time now, I decided to branch the keyboard layout production from the xkeyb driver coding, so that Henrique Peron, which has been helping me with the layouts for some time, can update the layouts at his own rythm, without the need to wait for a new version of the driver. Everything mentioned in this mail also affects DISPLAY and the codepage sets (also due to Henrique). As the number of layouts and codepages has grown very much lately, I also decided to branch these packs in two flavours, the REDUCED pack and the FULL pack, where the later contains all the available layouts and the former is a subset of it. The idea behind that is the fact that the uncompressed size of the FULL pack is far too big compared to KEYBOARD.SYS (to EGA.CPI in the case of codepages), and maybe not suitable for a FreeDOS bootdisk, when one would only need the essential, or for which the layouts on the REDUCED pack could satisfy most of the users. In the version 1.00, the uncompressed size of FULL is 233Kb, of the REDUCED is 54Kb. Whenever a new version os xkeyb is to be released, then I would pick the most recent version of the REDUCED pack, and merge it with the driver, so that the user can use the pack directly, or download in addition the FULL if he/she needs it (just as I think it happens with FreeCOM in the kernel package). However, due to some comments that I have picked lately, I am in doubt about the best way to link both parts. What is, in your opinion, the most suitable thing to be done? (1) Keep as it is now, and release driver's version merged with latest REDUCED pack, FULL to be downloaded optionally. (2) Do not merge any layout pack with the driver: let the user choose either REDUCED or FULL, even if s/he has to download neccessarily at least two files . (3) Create several distributions of the driver: one would be packed with the REDUCED (say a bootdisk distribution), and other with the FULL layout. Other suggestions/comments welcome. Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] FreeDos with FAT32 Success!!!!!
Wouldn't this be/use cygwin, mingw (or was it mingv) and friends? Florian Xaver wrote: Hi! (I am not sure if FreeDOS supports files of 2 GB yet, The DJGPP team are working on a WinXP compatible DJGPP lib/compiler,which (if i remember right) will also support files bigger than 2GB under FAT32.But the will not use the os for this...(?) bye,flox -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] FreeDOS installer ideas
But=- FD.EXE could be made by RAR.EXE, and self extract into any 16 bit dos directory, or maybe even a floppy. You seen the drdos 7.03 install?It is, by far, the fastest of all of the above. I don't think plain unpacking will upgrade the boot sector, as required by the install disk. Since Mozilla will run on os2 and win 3.1, it dont seem outta the question to figure out the API calls Moz needs and answer them. I'd bet that such an application would need WINDOW, WINCONTROL, EVENT, and that kind of services that are not defined for DOS. You'd need to use a bunch of such services for DOS (such as MS-Windows' KERNEL, USER, GDI etc, and the corresponding for OS/2.) Aitor -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: RE: [fd-dev] Codepage IDs
Hi, = Actually, Michal and I are working on creating new .CPI files from scratch (to be used under *any* system supporting .CPI files, including DR-DOS, PTS-DOS, MS-DOS OEM issues, Arabic/Hebrew issues of MS-DOS, OS/2 and Windows NT/2000/XP), so you can include and exclude codepages as you like. Switching between the various .CPI file formats will also be just a matter of setting a different conditional define. = This is good, one of my goals is to introduce soon CPI parsing routines in DISPLAY, so that such project can also be used for FreeDOS with DISPLAY. But in order to have SOMETHING, I decided to release DISPLAY with the easier approach of the RAW files (simply a concatenation of the x8,x14 and x16 fonts). == There's something that I would need to know for KEYB to handle this easily: which is the highest codepage number known? May I refer you to the huge KBD.LST file containing all the keyboard related news for the forthcoming issue of RBIL? I already sent you a copy... For your convenience, here's one of the tables to be found under INT 21h/AX=AD80h: == Sorry, I always forgot that there's codepage info over there too! :-) === ( my wish: below 4000 my second wish: below 8000 my last wish: below 16000 :-((() Country codes, Code Page IDs, and Keyboard Layout IDs are 16-bit values and should be treated as such. Although far not all of them were or are used by Microsoft and IBM, the highest assignable Code Page number is 65533. 0, 65534 and 65535 are reserved as they have special meanings for the OS itself (see below). == So I was out of luck! Well, it can be patched more or less easily. == CHCP is an internal program that calls kernel, which calls NLSFUNC. Indirectly, yes. It calls the DOS kernel, which will usually call down to NLSFUNC, which will then call back into DOS to retrieve the info (for file I/O only). Once the info has been looked up, NLSFUNC will return it to the DOS kernel, which will then again call NLSFUNC in order to switch the codepage. NLSFUNC will then ask any character device driver in the system if it supports codepage switching. Any driver supporting codepage switching (like DISPLAY.SYS or PRINTER.SYS, for example), will then be advised to switch the codepage. If they return an error, NLSFUNC will return an error as well. DISPLAY.SYS internally will also communicate with ANSI.SYS and KEYB in order to switch display and keyboard codepages (ANSI.SYS is not called for codepage switching as is, only for communicating display properties). = Very interesting topic. Well, some more issues here: (1) The way of doing that is via int2Fh/MUX=1Ah or is it possible to call the next driver in the chain somehow? (2) In fact, I was expecting to reflect ALL the calls except the change codepage (generic IOCTL) to the next driver in the chain, how can I do it? (3) Suppose someone install DISPLAY.SYS before ANSI.SYS. Can I expect that ANSI (or other CON driver loaded later) will reflect to me any call? == (*) There is a case which, in my opinion, leads to inconsistency. DISPLAY.SYS is responsible for changing keyboard codepage too. Microsoft's implementation will switch the screen codepage regardless if KEYB managed to change codepage or not, which means that it would leave screen and keyboard with different codepages if KEYB failed. In my opinion, this is a bug. In my opinion, too, but I would simply implement an option into DISPLAY to control the behaviour - so the decision is up to the user. I suggest to use /E for this purpose because it would somewhat correlate with an option supported by my internal issue of DR-DOS NLSFUNC: = Ok, annotated in the TODO list ;-)) = This program is not required. It required only if you wish to switch codepages on the fly, but if you work only with one codepage, you may (should) initialize it with COUNTR= statement. Of course, in MS-DOS MODE and KEYB without NLSFUNC loaded will fail to load fonts/layouts other than pointed in COUNTRY=. This is correct, but still, a COUNTRY.SYS file parser is needed not only for NLSFUNC, but also for FreeDOS' DOS BIOS. In older issues of DR DOS, NLSFUNC has been an integral part of the kernel, and the disk file was only a dummy for programs expecting it to be there. But then the code moved into the DOS BIOS, where it will get discarded after init (the driver is temporarily linked in during the processing of the COUNTRY directive), and into the file parsing portion of the external NLSFUNC driver for later use. = We could have at least a very basic parser that would simply read the information in the formats defined by Steffen as chunks in a single file. If someone manages to cut on 1 half the Earth spinning rate, so that a day has 48 hours, I'd compromise to do that myself. ((I have removed it when you mentioned that older currencies are not longer in use)) There seems to be a symbol (I think in CP437) for Spanish PESETA, that I have seen
