Re: [Freedos-devel] Re: Developing in Linux / FreeDOS
Eric Auer escribió: That would be a bug then. Turbo C is for DOS, so use it in DOSEmu, not in Wine. According to the wine RPM description, Wine can do Win16 and DOS apps too. But I don't know much about their DOS virtualisation. Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Questions on HIMEM
Hi there, I have been reading the HIMEM sources, and have these questions. I am grateful to whoever can say something about these questions (which as usual are plain questions with no critisizing): (1) There is a /TEST option (not present in MS-HIMEM), and at the same time, MS-HIMEM implements a /TESTMEM:ON|OFF option to do this (defaults to ON). /TEST does a nice test by allocating, filling, testing, resizing,. to determine the reliability of the extended memory. I just wanted to ask if there's something I missing about something which is obvious (?) (2) This is something about TASM/MASM: what is a COMMENT block? (3) XMS UMB functions are not supported. I just wonder if MS-HIMEM implements them: now that HIMEM is quite machine specific, perhaps this is the way Microsoft implement their UMBPCI (just a reflection) (4) Finally, I am unable to understand the whole process behind making a mixed SYS/EXE driver, can someone clarify about this? - HIMEM64 starts with a device driver header - HIMEM.EXE actually starts with MZ, so it can be open as an executable. How is that the kernel can open it as a driver, if it doesn't start with the device driver header? - Who calls ASMSTART_EXE? Thanks in advance for your help, Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Questions on HIMEM
Hi, tom ehlert escribió: Hello Aitor, (1) There is a /TEST option (not present in MS-HIMEM), and at the same time, MS-HIMEM implements a /TESTMEM:ON|OFF option to do this (defaults to ON). /TEST does a nice test by allocating, filling, testing, resizing,. to determine the reliability of the extended memory. I just wanted to ask if there's something I missing about something which is obvious (?) differences: the MS HIMEM test (done always, unless disabled) is probably a much better memory tester. FD HIMEM is a VERY dull memory tester. I wrote it more to test HIMEM correct internal working, then as an attempt do do a serious memory tester. But much better than nothing. (4) Finally, I am unable to understand the whole process behind making a mixed SYS/EXE driver, can someone clarify about this? - HIMEM64 starts with a device driver header - HIMEM.EXE actually starts with MZ, so it can be open as an executable. How is that the kernel can open it as a driver, if it doesn't start with the device driver header? - Who calls ASMSTART_EXE? if the kernel loads a device= , it uses the device driver header. if the kernel loads an executable, it looks into the MZ-header to find the start address (which happens to be ASMSTART_EXE) Yes, but my question is how does kernel know where the device header starts? MZ doesn't look like a correct pointer to the next device driver inside the file... Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Questions on HIMEM
Hi, tom ehlert escribió: Hello Aitor, Yes, but my question is how does kernel know where the device header starts? MZ doesn't look like a correct pointer to the next device driver inside the file... 'MZ' is only an envelope around 'the real thing', specifying e.g. minimum space required, START POINT, size of envelope,... the 'real thing' in himem/emm386 start with the device header. Now I understand. Can I make a small suggestion for making it a little bit easier reading one line in kernel source? (if people agrees, I or Jeremy or whoever can commit these changes to CVS): I would move #define LOADNGO 0 #define LOAD1 #define OVERLAY 3 from TASK.C to EXE.H (or GLOBALS.H, or somewhere else), and then replace in CONFIG.C - if ((result = init_DosExec(3, eb, szBuf)) != SUCCESS) + if ((result = init_DosExec(OVERLAY, eb, szBuf)) != SUCCESS) Thanks! Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] This is a TEST
So please ignore. I have tried to send the same message twice to the list, but doesn't seem to appear there. I hope it doesn't appear twice. Are there automatic unsubscriptions, as with Topica? Cheers, Aitor --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Microsoft Windows runs on FreeDOS (and now for sure)
(new attempt) (NOTE: this is a copy of my infamous post, but this time WITHOUT the attachment; I hope we all don't get it three times later) (The attachment was a zip-ed BMP image (around 10KB) of Paintbrush over Windows 3.1 over FreeDOS) == Hi, From time to time I like testing how far we've gone with FreeDOS, and a good way to know is to test MS-Windows compatibility. First of all, Windows in the enhanced mode (WIN /3) does not work, (first it says that 32BDA can't be enabled, because DOS 3.20 version is required, I wonder why it complains, if reported version is 7.10), and the final obtained message is This version of DOS cannot be accepted, irrespective of the VERSION= setting of CONFIG.SYS, thus it's quite likely that the true DOS version is checked. The testings were made with a 386DX machine, running FreeDOS kenel 2035 FAT32. 2035 stable and 2035a unstable (posted by Lucho) were tested, with no apparent change of situation. Mouse was NOT present in my testings. Microsoft's HIMEM was used. The version of Windows tested is Windows 3.1 in Spanish. Some of the GRP files that the Program Manager needs were missing (and this was interesting for the test). I know that other people (e.g. Eric) posted about Windows working, I just wanted to give a hint. At a first glance, it seemed not to work: the complaining dialog by Program Manager of the missing GRP files seemed to lock the file: keyboard was irresponsive. However, if you make the change shell=winfile.exe in the adequate section of SYSTEM.INI (that is, replace the Windows shell from Program Manager to File Manager), then WinFile boots normally, and seems to work well. Further, if you open ProgMan.exe, the dialog complaining about the missing GRP files is responsive to keyboard. Some other programs (NOTEPAD, WINHELP, WINVER) seem to work well as well. Happy windowing over FreeDOS... Aitor PS: Attached picture is quite lame, it is as much as I could do without a mouse and with a poor screen resolution. Yet it is true ;-) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Microsoft Windows runs on FreeDOS (and now for sure)
Hi, Luchezar Georgiev escribi: Thank you for this information! However, in order to make the FreeDOS kernel fully compatible with Windows 3.1, a developer or a group specially interested in this must actively work to achieve it. Is there anyone here interested AND competent enough to do it? Well, that Windows in Standard Mode runs under FreeDOS well is a question of fixing bugs globally in FreeDOS kernel, as one could expect and has been seen. That Windows in 386 Enhanced Mode runs under FreeDOS requires that FreeDOS kernel communicates with the DOS386 (well, they call it WIN386 in the non-beta versions, and VMM32.VXD when they want to run Microsoft Windows version 4.0+ over it) is much harder and has already been documented by Bart and other people in the list. If I recall correctly, consists in responding to the enhanced mode broadcast calls, by telling Windows which data has to be instanced for each VM. One could simply rename COMMAND.COM to KRNL386.EXE (the Microsoft Windows boot up file) and try to make FreeDOS compatible with the extender as a first instance. Not speaking about caveats like (1) Whoever has Windows 3.1 probably has MS-DOS or DR-DOS too; (2) Windows 3.1 will be undistributable until Microsoft frees it or dies - that is, for very long. I do own MS-DOS 6.2 and Windows 3.1, from times in which you bought the OS software with your machine (and I do have original disks for Windows 3.11 for WorkGroups). Now they sell them empty (which is BEST) or with that PREINSTALLED SHIT, which is WORST, because (perhaps) you do not own the OS, they won't give you the Windows CD anymore, but nevertheless I am sure that you pay for it. They simply give you a CD with which you can completely restore the original contents of your HD (much worse than the ability to install the OS). To be honest, I have never understood the story about preinstalled. I don't know if I own WindowsXP Home edition or not, although my PC had it when I bought it from Acer. What is worst, one of the technical support staff person told me by phone that if I had problems with hardware, even within the guarantee period, they cannot be responsible if I change it for another operating system (Windows XP Pro, which is what I wanted to install because at work we have global licenses). Anyway I don't know if this is the official position of Acer of this person was wrong (it gave me the impression that she knew less about computers than I do), but if it is, then it is undoubtedly a shameless position. One more reason to set about to work for FreeDOS and hope that many other people would sell PCs with FreeDOS preinstalled as Dell Canada guys do: it is free. Cheers... Aitor PS: An advice for you not to SUFFER as I am doing: please pay careful ATTENTION to the keyboard when you are about to buy a laptop: I didn't, and my Acer Aspire 1600 series laptop does NOT have HOME and END keys standalone: they can only be obtained through the FN blue key, and it's a REALLY nightmare when editing text. BEWARE! --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Idea about Virtual PC compatibility / A20 handling
Hi, LOADFIX (should be part of every FreeDOS distro! Do we have one? LOADFIX is internal, and IIRC it is already implemented in FreeCOM. Aitor --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] ANNOUNCE: DISPLAY 0.11
Hi all, I announce version 0.11 of FD-DISPLAY, with several new features: - It implements a new MODULE for the CGA hardware type (CGA adapters), thus making unnecessary the existence of a GRAFTABL tool for the FreeDOS project. This is yet untested (I have no CGA cards handy). Furthermore, any other GRAFTABL is prevented from loading - It allocates buffers to XMS if available, thus saving 9-10KB of convenctional memory for each buffer (in the most frequent case of a single buffer, resident TPA memory size reduces to about 11KB. The SELECT buffer has now the approrpiate size (and may save even more KBs on CGA and EGA) - DISPLAY is now DISPLAY.EXE (instead of DISPLAY.COM), with the same resident size, in the hope that it will bypass the kernel UMB allocation bug for COM files (as reported by Bernd). Notice that in few more versions it'll be turned into a SYS - Better commandline parsing (tab, #10 are now blanks also) - The maximum number of allocated buffers now depends on buffer size and available memory (and is no longer of 5), with a maximum of 8 (or the available memory) - FIX: the limit mentioned in the previous item was not observed when you specify the fonts explicitely in the commandline. Unfortunately, the new version (that has already been tested and seems to work) requires that FD-MODE be modified to admit this new version (it's simply that FD-MODE allows version 0.10, and has to check wether version=0.10 OR version=0.11). Download links: executable: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/disp011x.zip source: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/disp011s.zip Happy testing... Aitor --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] How to detect if fd #0/#1 are the local console (was Re: [Freedos-devel] BEEP)
Hi, Steffen Kaiser escribió: Til this time there had be no suggestion to overcome the requirement about how to detect if: 1) FreeCOM's input comes from the local keyboard (in opposite to FreeCOM MUST use the file descriptor #0 or the read from stdin DOS APIs) and 2) FreeCOM's output goes to the local screen (in opposite to FreeCOM MUST use the file descriptor #2 or the write to stdout DOS APIs). There are two obvious indicators that the console is NOT the local hardware: 1) when fd #0 (or #1 respectively) is NOT connected to a device, and 2) when fd #0 (or #1 respectively) is connected to a device, which has the NUL or CLOCK$ bit set. How can FreeCOM detect a CTTY COM3 situation _without_ FreeCOM had carried out the CTTY command itself, e.g. when you boot the system with another shell or when a special setup (embedded system or maybe a CONFIG.SYS patch making CTTY= available) is used. There had been a discussion that the LoL field last loaded CON: driver is not suitable. Also, the name of the driver itself CON is not suitable, as one can name a driver like that, that is not driving a console at all. Are the stdin/stdout bits of any value? As I see it, FreeCOM should in all cases use files stdin and stdout for entries. I see it as logical that someone (maybe Kernel) should guarantee that only one device has stdin/stdout bits at a time (and this is the device where file #0, file #1 should point to), regardless if it is CON or has other name, but I haven't tested this, so I don't know. I just wanted to use this thread and ask (whenever DISPLAY becomes a SYS) if when I chain to a previous CON driver, wether I should clear the previous CON driver's stdin/stdout bits, and set my own stdin/stdout bits. If I just do this, I don't think it is guaranteed that stdin points to me. Of course, it's faster (and less mess) if stdin/stdout continues to point to the old CON driver (DISPLAY will just chain all the calls except IOCTL), but I think that this wouldn't be logical. Any ideas or light on this is welcome. Aitor --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Ensemble Lite Redux
Hi, Eric Auer escribió: Hi, I vote for Bernd's idea: me too. Aitor --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Ensemble Lite Redux
Hi, Well, I tend to be concerned about MS compatibility, but your arguments are convincing. I was just thinking if it is sensible (I don't know, opinions wellcome) to call the option /NOALTBOOT instead, so that those that use this option get not confused. (well, my option would be compatibility so do not include by default, unless you include /ALTBOOT, but that's your call). Aitor Michael Devore escribió: Ensemble Lite didn't go away after all. Someone here notified the Ensemble person trying FreeDOS who, in turn, contacted me. Originally, I got Ensemble Lite past its first error message by loading SHARE, whereupon Ensemble later caused or encountered a hard crash. Subsequent to the last report here, the Ensemble user sent me a new setup file to work around the ominous sounding file system driver crash problem in Ensemble. That caused the same crash until I took _out_ SHARE, at which time Ensemble started to work. Got that? No SHARE gives error message, but SHARE causes crash until file update from user which works if SHARE removed. Note to any who cares or tracks these things: Ensemble doesn't like FreeDOS's SHARE. Don't know whether to blame a bug in Ensemble, SHARE, or both. Don't much care anymore. Following that, as advertised, Ensemble did experience a problem only when EMM386 was loaded: the keyboard stopped working. Nothing to do with EMS, but definitely a problem. Turns out that Ensemble doesn't like EMM386 hooking INT 9 keyboard interrupt to check for Ctrl-Alt-Del keypresses so EMM386 can clean up UMB's and what-have-you for reboot. To correct the problem, I have added an ALTBOOT option to EMM386, which bypasses the INT 9 check and makes Ensemble Lite happy. Normally, I'd give a rat's butt about working around Ensemble's internal problems, but there is a strong precedent for the ALTBOOT option. The ALTBOOT option is present in Microsoft's EMM386 due to documented cases of problems with the memory managers hooking INT 9. So I'm not just fixing a problem with Ensemble here, I am fixing future problems for other programs that Microsoft knew about, plus extending EMM386's Microsoft compatibility. Wow. Purists may point out that Microsoft's ALTBOOT option appears to work the reverse of FreeDOS, adding the INT 9 handler when present rather than subtracting it. But FreeDOS has worked fine up to now, so I say ALTBOOT should shut off our default handler, rather than enable it. As long as there's an option to toggle behavior, it should be fine. I'll upload Yet Another EMM386 Update soon. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New tools: CONCAT, OSCHECK (for installer)
Bernd Blaauw escribió: still SYS should have some additional possibilities, like WARNING the user. I remember my SYS C:..while C: contained Win2000 bootloader..bye bye Win2000 installation :( A bit offtopic, well, I don't know much about the NT loader, but it always surprised to me how fragile is the whole installation of a robust operating system like WinNT can be easily trashed in a few seconds, by just SYS:-ing whenever it loads from an existing MS-DOS (read Win9X/ME)... Does anyone know if there is some recovery in this case? (and you don't have a backup of the bootsector, or a GHOST, or whatever). Aitor --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: [Freedos-user] Eric's new and shiny inofficial FreeDOS 1.0/2.0 TODO list ready
Hi, This mail explains my position on the recent 1.0 list issue. If the FreeDOS version 1.0 concerns you, please read this. When I declared my intention to create the TODO list, I explained my two major concerns about it. First of all is that I wanted it as a checklist, and second, that I just wanted consensus or at least majority in order to perform changes on it. The rules for applying the changes have always been, and are, (1) Majority wins against minority (2) If tie, then things remain as they are, and the reason to do so is that when I announced my intention to create the list and its features, few people replied. It's far easier to wait till the work is done and then complain when you don't like such or such thing. In particular, there several things that Eric likes (one vote for), and that I don't (one vote against), so applying rule (2), this means they remain as they are, unless majority speaks in favour of them, of course (they are roughly speaking verbosity, that is, I want A, B, C,... and not A, this uses interrupt XXX, please see here, and comment there; B: ..., including the POST items mentioned in the todo items, IMHO they are just noise, that don't let you see clearly what is to be done yet). Now if you dislike something on the list, there are two ways: - Comment in the mailing list, and see what majority thinks. Everytime majority has decided to change something, even if I voted against (e.g. the parameters of EMM386/HIMEM, although I must admit that Michael Devore convinced me in his latest messages, please read them), I have committed the changes - Fork the list, make the changes you like (regardless if you weren't in majority) and post it somewhere (that is, Eric's way) Needless to say, I don't think this helps the FreeDOS project. Branching is ok whenever a person wants to take sources for a particular purpose. Generally speaking, I don't think that branching between two freeDOS developers is good, and I say this knowing that - you are FREE to do it - there are dramatically opposite positions against this or that everytime a branch happened (e.g. MEM, Kernel) So I just have to live with that, and thank Bernd and Jeremy, that have been acting as mediators many times very well. But I think it can be specially harmful that, being a single project, there is something like two sets of goals for FreeDOS 1.0, almost as critical as if there was a branch on the spec or manifesto. Eric, you say your list is not to replace the official, then why you do it? why, being over 70 bugs, do you waste your time (and mine) in creating such a list? Respect to the list consulting and posting: the list is updated weekly (what a remedy! read below) in my hard drive, and latest edit is always available via mail. Modifications, typos, etc (some come from Eric) are always welcome, but specially welcome when ALL of them (say 20) are listed AFTER one official release, and not when they come by twos every week: this forces me to be updating the files and going over them once and once again. The normal behaviour has been: I upgrade the files, send them to Eric and Bernd, Eric reports 2 typos and 1 feature (for which there's no majority, so I explain for the n-th time and ignore), I change the list, I send it again to Eric and Bernd, etc etc). In a past time, Jim was with myself concerned with the TODO list, and he understandably gave up. Now it is Bernd who very kindly uploads the list to a web server from where it can be checked online. But I ensured that the list will NO LONGER be sent to be uploaded every time Eric has a change, that is, every... four days?, and I claimed that updates would come at a reasonable rate, say once each two month (or at most month), or every time big changes occur, in order not to be bugging Bernd everytime. rantmode Thus, in the message from Eric (that I haven't read yet) he seems to mention other reasons why changes are not reflected in the webserver. Eric there are no conspiracies or similar. You know very well that I have been very clear with you in what concerns the todo list. It's simply that, despite I, stupid of me, allow you to be bugging me every week with a slight change (and not, say, every two weeks with SEVERAL changes, and with changes that have been discussed and agreed in the mailing lists), and do the appropriate modifications to the files in my hard drive, I don't bug Bernd in turn to upload the file till he things it's ok to do it. So I hope it is now clear forever why changes are not reflected in the list fast. Bernd, you do NEVER have to justify yourself why you couldn't have uploaded the files (you didn't have to) because you had other personal non-FreeDOS stuff in your real life to do it. Likewise, I don't have to justify that I was on a trip, thus I couldn't just reply to Eric's messages in the space of four hours. So Eric, if you get bored, I think you help much more the FreeDOS project if you
Re: [Freedos-devel] FORMAT 0.91r - new features / KERNEL DOS-1c DOS-36 bugs
Hi, Eric Auer escribió: [...] So Aitor should now be happy with the features. Okay, I have updated the todo list entry for FORMAT to fix bugs (please note: web server not yet updated). Actually, Eric, you can close 1022 (as I assume that this feature is supported), and maybe some FreeDOS users or developers with partitions/drives bigger than 4GB, so that you can also close 998 and FORMAT becomes Ready!. Anyway notice that, except for the missing SCANDISK, at least all the disk utilities are at most set to fix bugs (no features remaining), same goes for file utilities and user interface utilities. I finish just by mentioning those utilities that numerically, the utilities that show numerically more features to do are PRINT and MEM (presently not being worked on, I think), and besides my own utilities that I hope to work out this summer. And those having larger amount of bugs remaining are Kernel, FreeCOM, FDISK and INSTALL. Happy coding and debugging! Aitor --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
Eric Auer escribió: This is also the main problem now: Arkady wants RAM= and he wants an HIGHSCAN change, as far as I understand. I have had longish discussions with Aitor about what exactly those options should do, so I recommend that Aitor tells us some more details. Easy: RAM (parameterless): trivial (same as none, I think): specifies that we need UMBs and EMS (as opposite to NOEMS) RAM=area (UNIQUE) means: this is the area that you have to scan in search of empty useable blocks I=area (possibly MULTIPLE) means: assume that this area is useable and USE it (could well overlap with RAM, and it has precedence over it) X=area (possibly MULTIPLE) means: always unconditionally exclude this areas (could well overlap with RAM, and it has precedence over it) If I/X areas overlap, the X switch takes precedence. Aitor --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Device drivers using XMS
Hi, Does anyone know if it could cause problems (to kernel or whatever) if a device driver (loaded after HIMEM.SYS) would use XMS to allocate EMBs? Aitor --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Apologies... (got the answer)
Hi, I have just remembered, EMM386 is such one device, so I guess the answer is no (anyway, if I am forgetting about something, please tell it). Aitor --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS distro delayed
Hi, Arkady V.Belousov escribió: BB and then ask people who have worked on the kernel in the past to review BB your work, and ask them is this good enough and understandable enough to BB commit it into CVS? I already know that tom will never accept my changes for kernel. Wasting oue time. Bart also is very conservative, and prefers not fix things, but make lesser diff. Who else? I suggest that you stick to the liberal rule. Do your own compilation as Bernd suggests, then convince us that your kernel is better and works better than 2035 (and may be eligible as for 2035a). In this case, I see no problem why it should be 2035a. If Tom doesn't like your patches, he will argue why, and you'll have to face it... Aitor --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] bug in UMB support
Hi, One more opinion on this topic. I don't think it's a good idea that the UMBs are chained into the main MCB chain. UMBs are different from other memory blocks. For instance, if you are using EMM386 to provide UMBs, you may get troubles with DMA because of the mismatch of linear and physical addresses. This is the sort of reasons why most of the programs provide /NOHI switches and such to avoid being loaded high. Thus, we might get into troubles if the UMBs are inserted into the main MCB chain, as it might be that current DOS algorythms allocate some memory unavoidably high. Aitor Alain escribió: tom ehlert escreveu: if the a000 block is ever merged into the lower memory area, interesting things might happen. I remember one for instance: it was possible with a MDA to have 704k lower memory. Not interesting anymore, after the advent of VGA. So, my vote is that any workaround is as good as a fix for something that will never get used ;-) Alain --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 5.0 v0.4
I have done a couple of testings with /X:ON and DIR FD-APPEND + NT/CMD.EXE is NOT affected MS-APPEND/NT + FreeCOM is AFFECTED Thus my guess is that it is, I would say, COMMAND.COM who has to care about this (NOTE: I filled a bug report about this long time ago, but it was a guessing, because MS-APPEND made FreeCOM crash, I guess due to problems with 2Eh). Aitor Eduardo Casino escribió: El vie, 18-06-2004 a las 23:12, Alain escribió: Is this append FreeDOS only or should it run in MS-DOS 7.10 or in a Win98 DOS-BOX? FD only. It is untested under MS-DOS 7.10 or W98 DOS-Box and it breaks DIR under MS-DOS 6.22 when using /X[:ON]. Anyway, can you please test it under MS-DOS 7 and W98? Eduardo. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0
Arkady V.Belousov escribi: Hi! 24--2004 10:12 [EMAIL PROTECTED] (Aitor Santamar?a Merino) wrote to [EMAIL PROTECTED]: ASM See for example the flags (B706h to get, B707h to set, both through BX): Where see? Which interrupt function? ASM 2Fh You mean: BX=0, AX=B706, INT 2F, append_state = BX if (BX 1) /* APPEND enabled */ BX = ~1, AX=B707, INT 2F ...perform searching... BX=append_state, AX=B707, INT 2F ? Yes... Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0
Arkady V.Belousov escribi: How to overcome presence of APPEND? I mean, APPENDed names, probably, may/should be ignored by ATTRIB? ASM APPEND will hook File Open, and with the /X modifier, also FindFirst and ASM Exec. ASM See for example the flags (B706h to get, B707h to set, both through BX): Where see? Which interrupt function? 2Fh ASM Bitfields for APPEND state: ASM Bit(s) Description (Table 02980) ASM 0 set if APPEND enabled ASM 1-11 reserved ASM 12 (DOS 5.0) set if APPEND applies directory search even if a drive ASM has been specified ASM 13 set if /PATH flag active ASM 14 set if /E flag active (environment var APPEND exists) ASM 15 set if /X flag active ASM By default, APPEND (NT-APPEND and FD-APPEND) sets the flags 0,12,13 (and ASM 14 with /X). 13 can be modified through commandline. ASM So one option would be to disable 12 through the API, then invoke ASM FindFirst with d:*.*, or the easiest, save, disable and restore the ASM flags. This is one way? There is not possible to disable APPEND while searching files (and restore its state later)? Yes, in the last sentence I forgot to add bit 0. Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0
Hi, Arkady V.Belousov escribi: Hi! 21--2004 23:07 [EMAIL PROTECTED] (Aitor Santamara Merino) wrote to [EMAIL PROTECTED]: ASM I mention this of backdoors in particular because: ASM (a) MS-DOS 6.22 help does say that COMMAND's DIR is not affected by ASM APPEND /X. FreeCOM DIR is not affected by FD-APPEND /X, even with no ASM modification on the side of FreeCOM How to overcome presence of APPEND? I mean, APPENDed names, probably, may/should be ignored by ATTRIB? APPEND will hook File Open, and with the /X modifier, also FindFirst and Exec. See for example the flags (B706h to get, B707h to set, both through BX): Bitfields for APPEND state: Bit(s) Description (Table 02980) 0 set if APPEND enabled 1-11 reserved 12 (DOS 5.0) set if APPEND applies directory search even if a drive has been specified 13 set if /PATH flag active 14 set if /E flag active (environment var APPEND exists) 15 set if /X flag active By default, APPEND (NT-APPEND and FD-APPEND) sets the flags 0,12,13 (and 14 with /X). 13 can be modified through commandline. So one option would be to disable 12 through the API, then invoke FindFirst with d:*.*, or the easiest, save, disable and restore the flags. Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0
Hi Alain, Alain escribió: Hi Aitor, Can I use this append with MS-DOS or in Win98se dos-box? MS-DOS: In theory, unless there is a backdoor somewhere, this APPEND is implemented following RBIL and MS-DOS 6.22 help (except that the functions mentioned are not implemented, but I doubt that you have programs using FCBs?), and it should even be compatible with MS-APPEND, except with MS-APPEND 3.21 (but I recommend not to mix them). I mention this of backdoors in particular because: (a) MS-DOS 6.22 help does say that COMMAND's DIR is not affected by APPEND /X. FreeCOM DIR is not affected by FD-APPEND /X, even with no modification on the side of FreeCOM (b) If you check RBIL, Int 2F/AX=AE01h it says that APPEND hooks this call, and not just APPEND USES this call (as could be used to SET APPEND= in APPEND /E, for example). I haven't hooked this call, I don't know exactly why to hook this. WindowsNT/XP: It seems that FD-APPEND works well under NT DOS Boxes, but you have to rename APPEND.EXE to other name (otherwise, the NT's APPEND is used). Win98SE dos-boxes: I ignore what the effects of locally hooking int21h could be, I suppose there will be bigger problems if you run it on AUTOEXEC.BAT or WINSTART.BAT, but I haven't tested this. So if you test, please tell us :) Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] ANNOUNCE: FD APPEND 1.0
Hi all, I'd like to announce FreeDOS APPEND 1.0, a very basic APPEND that I have created. With this, I could run WordStar Express in a mixed directory installation, as I intended. APPEND 1.0 is very basic. In particular, it is NOT implemented: - APPEND /E - FCB functions - The function 11 of the API You can get it from here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/append/aappend.zip (not to be confused with the other file present there). Regards and enjoy, Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New MODE version for UPX(!) packed CPIs
Hi, Eric Auer escribió: Let me know if it works for you and when you have some more CPX files uploaded to some homepage out there :-). Note that without the --8086 option the CPX file will contain a 286+ rol [...],8 command instead of a mov / xchg bl,bh / mov one to squeeze out a few bytes more. Such CPX files will not open properly on 8086 CPUs, obviously. Maybe Henrique is interested in creating packs of CPX files. You can explain to him how to create them, but mind that he is not a programmer. Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bug/enhancement development questions
Hi Michael, I support your concerns about the tracker. I admit that I had forgotten about it, although I knew of its existence. Michael Devore escribió: Absolutely agreed, Bugzilla is too complicated and busy, and the usage documentation is sub-par. But, it's what FreeDOS has, so we need to make the most of it unless and until something better comes along. There was a time in which we had bugtrack, a simple and quite good (for my taste) bug tracking system. I don't mean to go back to bugtrack (as it seemed to happen to that faq-o-matic stuff?), I'd say that porting the bugs to other system (bugtrack or others) would be now a lot of worthless work, that could be better spent in coding and patching bugs. Just in case it helps, when I have to fill in the bugzilla form, I leave most of the fields empty (I just care about title and the comment, and forget about the rest). Seems to work ;-) And last but not least, I am not picking mails for any bug recorded in bugzilla either (although it's harder to say because there were no bug reports lately, had one improvement request for KEYB time ago), so yes, there might be a bug in bugzilla, or something we are not doing right about it. Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released
Ooops... Aitor Santamaría Merino escribió: Bernd Blaauw escribió: right now on updated ODIN bootdisk the CPI files take almost 600KB (10 * 60KB), which is nearly half the disk! (and makes creating 720KB more difficult). Perhaps it's a question to check the CPI files, perhaps for MOST of the countries, just 2 or 3 of those CPI files are not enough, and not 10 of them. Ouch, I meant just 2 or 3 of those CPI files ARE enough (no not). Sorry... Aitor (Thanks Eric :)) --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 ROM/RAM (was: FreeDOS Version 1.0 reviewed)
Hi, Eric Auer escribió: RAM= assume that there already IS RAM at this place, so leave it mapped 1:1 and put UMB or EMS page frame there Do not mess with terms: RAM= scanable area: scan it, and if found empty, map, and have into account any X=, I= X=unconditionally excluded for UMBs/pageframe I= unconditionally included for UMBs/pageframe Aitor --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Version 1.0 reviewed
Hi Michael, Ok, thanks. Then is noone is against, I'll move those to post-1.0. I chose to set those there, as in the examples they seemed to be popular options. Particularly, what I missed mostly is VCPI, so thanks for that. By the way, I have remembered that I should list VDMA there too, pre- or post-? Aitor Michael Devore escribió: At 09:46 PM 4/24/2004 +0200, you wrote: Hi all, I have commited some changes to the list (some more to go, read below), and I am submitting a message to met you know. In addition, comments are welcome: if you consider that such or such option should be left for post (if any), or which tasks should be there. NOTES: - remember the golden rule: not as many wishes so as never to reach version 1.0, but not as few as creating a FreeDOS that could let potential users down - to commit: re-check MIRROR status, leave APPEND and HIMEM/HMAMIM= to post-1.0, some minor misprints, etc. - last time we discussed about the meaning of ROM= and RAM= in EMM386, still to be evaluated if pre/post? (I'd say that RAM= is trivial to implement, and with latest changes perhaps ROM= is not too hard) I'd say RAM is a practically useless option. Probably could emulate it within EMM386 parsing just by mapping X= ranges around it, though. Not too much current practical need for ROM or most of the other missing Microsoft-analogous HIMEM and EMM386 options, for that matter. There are other extended options which are more useful. Most of what's left can wait for a post-1.0 sweep that tightens up MS-command line option compatibility in general. We are putting out the final fires, not putting on lipstick. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS Version 1.0 (LINK)
Hi, I forgot the link. There's a direct link from freedos.org on top (directly from http://www.freedos.org/news/version1/), although files are being posted to TODOS: http://fdos.org/ripcord/fdos_1_0/official/todos.htm POST-1.0: http://fdos.org/ripcord/fdos_1_0/official/post.htm Aitor --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Version 1.0 reviewed
Hi, (Arkady, I know that you also posted to this thread, but the shit of programs that I used to remove spam trashed your message, could you please re-send to me that in private? I like keeping those messages as mails than acceeding them from web; anyone kind out there can also resend, thanks) Eric Auer escribió: EMM386 RAM= is well enough implemented if you make it an alias to X= if you ask me. WRONG. Please, recheck old posts by Arkady and myself. ROM= on the other hand would be not too hard to do (Michael already shadows ROM to trap :0 reboots). But ROM= does not help much, because all newer computers (even an 1990 NeAT 386 mainboard) have a BIOS setup option to shadow ROM into RAM. So no need to let EMM386 do that. So ROM= can be post 1.0 if you ask me. Good. It will be moved, as said to Michael. HIMEM HMAMIN / INT15 / A20CONTROL are probably not too hard to do, so why not. So are you suggesting to keep them as pre- or post-? snip explanations, this is about if to keep them or not, not about explanations http://fdos.org/ripcord/fdos_1_0/official/post.htm LBACACHE /L load to low memory is pointless - LBACACHE has no self-loadhi anyway. Either you load it low (prompt / DEVICE) or high (loadhi / devicehigh). No command line option for that. So I'll rename this feature to Add self-loadhi. ? LBACACHE CD-ROM caching is already there in CDRCACHE. If you mean CD-ROM caching which is actually part of LBACACHE and shares the same XMS handle, please mention that explicitly. I'll add a note. Missing tools: FASTOPEN / DRIVER / DRIVPARM: I vote that those should be kernel functionality eventually, not separate programs. DRIVPARM is a CONFIG.SYS option, not a utility. Anyway funcionality not discussed, I guess you are meant to leave them as post-, so left there. :) DOSSHELL: [...] I leave that discussion for later maybe. I think for the moment we should focus wether they should be pre-/post By the way - pre 1.0 - as far as I understand Aitor, Euro compliancy is already okay. I think only a few disk tools still TRASH LFNs, but which? Test results? I guess those dealing with directory entries, that is, kernel, UNDELETE and the disk tools (possibly others). My aim is to leave them there as reference, not that I know of a tool that has problems with that. But if we found a utility trashing LFNs, we should care about that (or that's the purpose, unless people considers that post-1.0). BACKUP / RESTORE can be post-1.0 if you ask me. Annotated... Todo list should mention who plans to do what (e.g. Aitor: GRAFTABL, APPEND) or is already working on it, to avoid 2 people working at the same thing without knowing about each other. As I said already, I have to update the APPEND entry, and it will specify that I am into that. But adding people's names for other entries than those that are missing and are being started is hard: so when kernel is ready except for fix bugs, shall we list everybody there working to patch bugs? Are FreeCOM REN wildcards actually still missing? When will DIR be able to show 2 GB free? ... Could you please test and add bugzilla entries as appropriate, or suggest Steffen for his table? Aitor --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Should MODE raise DTR / RTS ? -- MODE updated!
Hi, Eric Auer escribió: PS Aitor: Would LZSS compression be okay? Modified public domain Lempel Ziv Welch plus Huffman coding compress / decompress tool, very small, compresses a 57k CPI file to about 19k. ZIP and GZIP would reach 6k but it would need ZLIB (not included in HELP, this is why the help sources did LOOK as if they had not grown that much - to compile HELP, you download ZLIB sources separately!) or TUNZ. Not sure about TUNZ license...!? MODE binary is 16248 bytes UPXed right now - almost 16k. Well, actually I can't tell much... It won't affect DISPLAY.SYS at all, and I am not a lawyer... ;-) So you can just try and ask Henrique wether he can compress CPI files with that. Aitor --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] CTTY
Hi, Arkady V.Belousov escribió: Hi! Question: by default, only CON device have bits stdin and stdout yes, at boot only the ORIGINAL CON device has these bits (subsequent CONs could make this to change and gain these bits). (mask 0x3 in attribute word). What happen if I use CTTY NUL - is this equal to plain redirecting to NUL or shell sets stdin+stdout bits in attribute word (INT 21/4401, as I understand)? Also remember that in the lists of lists you have: 0Ch DWORD pointer to active CON device's header (most recently loaded driver with STDIN bit set) This is a pointer to stdin, guess that it has to be changed too. Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: GOODBYE FROM LUCHO THE FOOL!!!
Hi, I don't know if related or not, but for two subsequent days I have received in one of my accounts (not this, but one I was subscribed some time ago, and that I am currently used for private email) about 150 messages of 25-26Kb each which I assume to be a virus. I haven't annalyzed them, as I have removed them from servers, and have set up mail filters. It happens when I go to sleep, and see it as I get up in the morning. This is becoming the plague of the century... Take care. Aitor Eric Auer escribió: That said: The ratio of viruses in my spam folder sharply increased from 30-40 % on normal days to 65-80 % this week. I got about 250 NetSky T since Monday. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS mail-list spam, was GOODBYE FROM LUCHO THE FOOL!!!
Michael Devore escribió: My domain receives an average 200-300 spam and virii every day, with typical big fluctuations due to spreading of The Virus Infestation Of The Month. The FreeDOS-dedicated account has only received viruses and spam through the sourceforge mail-list posts, or possibly forged from there. Those average less than one a day, with the most in a single day being five or six based on my recollection. This, by the way, is emphatically not a challenge to those generating them to aim better. On the very few occassions I've checked the sourceforge mailing list archives it gives me the impression that email addresses are better protected than they were in the topica mailing list archives (or in the archive by the AIM's group, that is, otherwise, quite useful). I suspect that most of the spammers come from the archives being scanned. So all of us that had been once subscribed to topica suffer from this much more. Also I was subscribed with the email I mentioned for a short while (since Wanadoo Spain blocked Wanadoo accusing them of spammers till we moved to sourceforge), but it seems it was bad enough to be caught: during these days I've got more than 150 viruses PER DAY with From: field being one FreeDOS developer or FreeDOS-related guy, which may mean that somebody that was subscribed there may have such a virus. So I have to join Johnson in recommending not to use Microsoft Outlook Express as mailer, because they don't seem to have an option to block JavaScript only for mail (as Mozila Mail has), as it would be required by a reasonably safe mail program, in my opinion. Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] DISPLAY 0.10b ready
Hi, This is to announce a revision of DISPLAY 0.10, namely DISPLAY 0.10b. It just fixes a couple of bugs: - a bug that assumed a space to lead the parameter - a bug affecting the DISPLAY Installation check function (AD00h in int2Fh) MODECON.EXE also disappears from the distribution: please always use latest version of FreeDOS MODE. Source: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/dis010bs.zip Executable: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/dis010bx.zip Regards, Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Loading HIGH and the commandline in PSP
Hi, Some time ago, it was mentioned that there is a bug in FreeCOM's implementation of LOADHIGH (or in LH), by which, in my understanding, no space was left in the commandline between the program name and the parameters. This revealed that I am assuming in DISPLAY that such spaces exist, thus preventing DISPLAY from loading high as normal. But my question is: in the commandline found on the PSP when loading high, if I don't have to assume that those spaces are there, what is the separating character? or how am I suppose to find where the parameters start? As in my understanding what it's there is a fully qualified program name (or perhaps exactly the way it was callled), then the length is variable, I hope it doesn't mean that I have to explicitely look for the DISPLAY pattern... Thanks in advance, Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] ANNOUNCE: KC 1.0 ready
Hi all, I want to announce the availability of the KC (Key Compiler) tool, which is a tool for compiling text source keyboard descriptors into binary-type KeybCBs that will be used by KEYB2. In the binary pack, you have - the compiler, - documentation about the KEY language, that is used to describe the behaviour of a keyboard - documentation about the KL compiler and its particularities - a small test program to explore the behaviour of your current keyboard (KEYCODE); this will retrieve the (scancode/ascii) pair generated by a keystroke or key combination Output compied files can be bare KeybCBs, or they can be wrapped by a small header (forming a KL file) that is required for the forthcomming KEYB 2.0. The source package contains more information about the anatomy of a KeybCB, and of a KL file. On the KEYB page: http://projects.freedos.net/keyb you will find other useful documentation, such as the list of KEYB2 commands, that is, a reference of the actions you can program KEYB to do upon a keystroke. These include diacritic starters, string display, interrupt trigger, APM functions, codepage/layout management, user-defined modifier keys or switches manipulation. [NOTE1: the page is to be updated now, perhaps you'll read this before I have updated the page] [NOTE2: it seems that doosh.net is tyding up at the moment of writing this] If you want to test the output files, KEYB2 is available on personal request. For the moment I am optimising it a bit and writing documentation, and when this all is finished, KEYB2 will be released. The command list for KEYB2 is also available to be sent via mail. KC can be obtained from here: EXECUTABLE: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kc100x.zip SOURCE: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kc100s.zip Both KC and KEYCODE have been packed using the UCL version of the UPX packer kindly provided by Lucho, thanks indeed!!! They are just a little bit bigger than with NRV, but the difference is really small and I am fully satisfied. It is warned that the packer version used is beta and may contain errors. Should errors occur due to the packing, I would immediately produce a patched or UPX/NRV version of it. Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi all, I have committed most of the pending changes to the TODO list. While Jim and I acknowledge on the way of reintegrating it on the site, Bernd has kindly posted a preview of the list in the links below: 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm post-1.0: http://fdos.org/ripcord/fdos_1_0/official/post.htm When the todo list is back ready in its place I'll make an official announcement, but for the moment, it is open for discussion wether you think that the items in the 1.0 list are to be created/edited/removed/moved, etc (I'd prefer not to talk into post-1.0 list yet, I just send it here so that you have a reference of what it's there, and in case you think that something of what is there should be for 1.0 and not for later). So all of you that have soemthing to say about this, please speak. Public and private (aitorsm _AT_ inicia.es) mails are admitted, although perhaps it's better to make them public, so that other people can give their opinion. Please note that the list is supposed to be a list of items, that is, CONCISE, and NOT verbose. Also I suppose it's better if the messages posted here are also CONCISE, that would be helpful because my time is limitted. Note that there's also the list of DOS exitcodes kindly collected and contributed by Matthias Paul. For compatibility, please check that your utilities comply with these exitcodes as much as possible. Finally, if someone has an opinion on some item to be modified, but noone else says nothing, after certain time I'll understand that everybody agrees, and I commit the change (or at least, I'll annotate the change for the next big update). Regards, Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Nice that you pointed about FAT32. I'll explain what I tried to reflect in the list (because FAT32 was not popular time ago). My point has been: FAT32 support is left as post-1.0. The fact that KERNEL, FDISK and other components already support FAT32 is an extra plus, but maybe we don't need to mark FAT32 as one of the milestones for FD1.0 precisely because NOT ALL the utilities already support FAT32. Of course, this all is changeable: we can set that support for FAT32 be requested for ALL the components (including ALL disk utilities, UNDELETE, etc). How does people feel about it? Respect to the reference to DOSFSCK, I don't know well how to do it, so do you people prefer that (a) DOSFSCK be added to the list as a base utility? In my understanding, this decission corresponds to Jim Hall. Notice that there is no tool in MS-DOS called DOSFSCK (b) simply make a reference as with HIMEM/FDXMS286? (although FAT32 support is not required for 1.0 in the present situation, this may be technically a bit rare to be noticed there) I'll opt for (b), unless the contrary is decided. Notice that this does not solve the problem for other utilities (UNDELETE, DEFRAG?,...) that may not support this. Aitor Alain escribió: Hi, I found this: chkdsk Ready2003-10-6 I don't agree. If we have a fat32 kernel, and chkdsk is only fat16 we cannot use it :( There could be a reference to dosfsck, stating not compatible or something. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, BTW, TO EVERYBODY (I forgot to say): changes will not be commited IMMEDIATELY, ok? tom ehlert escribió: emm386 RAM=m-n range for UMBs + EMS emm386 ROM=m-n range of RAM to be used to shadow ROM as soon as someone finds out what that's supposed to do _exactly_ My guesses: RAM (you can specify it without parameters, in that case it is trivial: use both UMBs and EMS, and thus incompatible to NOEMS) In any case, RAM should always be incompatible to NOEMS. It's long ago since I last watched EMM386 code, but I seem to recall that there's some upper memory scanner to determine the memory that cann be used as UMBs, I guess that with this paramenter you skip the testing, as the user will tell you which gap of the memory may be used for UMBs and for the page frame. My suspicion is that you can specify more than one of these parameters. ROM, my guessing is (only a guessing), it copies the memory of that range into several pages, and maps that phisical memory into those pages. himem /INT15H=xxx himem /HMAMIN=m prehistoric crap might be moved to Post 3.0 Ok, for the moment we'll leave it for post-1.0, quite more generic ;-) I have never used int15h to allocate embs, which would be the impact of this for application compatibility? I guess not much, as I haven't heard complains about this yet... backup / restore Missing - Addressed (Ralf Quint) might be changed to 'missing' ( if someone ever missed that) I'll leave it as it is, I know Ralf is working on it (although all of us have different amount of timeslice to work on FreeDOS I guess ;-)) setver (CALLVER, VERSION= in CONFIG.SYS) Ready should be changed to missing - it's simply not the same thing Well, it may do the same functionality, that's why (1) I said NOT MS compatible (2) in post-1.0, specified that a compatible one is REQUIRED, what about the rest? one more opinion on this and I'll change it (if you also think it is confusing as it is). Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, Alain has introduced in this mail something interesting that was introduced in other posts too: the spec mentions a kernel compatible to MS-DOS 3.30, but actually I think that our current FreeDOS kernel is closer to 5.0 and sucessors than 3.30. Also 3.30 and 5.0 have many differences in data structures and such. Perhaps we should have other thread to see if it would be time to upgrade the spec? (before DOS disappears forever on the computing world ;-)). Alain escribió: DOS 6.0 not really - our EMM386 is limited, Not so much anymore :) For me, VCPI is the contribution of the year, thanks Michael!! MEMMAKER not existing at all, emm... set for post-1.0 already ;-) (and maybe add a network drive Well, I leave this discussion for post-1.0 ;-) if you are willing to go that way, Andreas is working on an IP driver for DOS/Win/Linuix which is great (I am using it) and would be free for FreeDOS. I think we can call FreeDOS a clone of MS DOS 5.0 features with many goodies from later Win/DOS versions inside but with still a few DOS 5.0 features missing - some legacy ones do not hurt, My point of view is: can we use it to run the programs I want? Read above. some others like Win 3.11 compat should probably be fixed before we call it FreeDOS 1.0 ... There is probably a patent to prevent us of it anyway :( I don't think so... Did it prevent DR-DOS from doing that anyway? I think it's just a question of misscompatibilities here or there... Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS 1.0 TODO list ready (but not yet posted)
Eric Auer escribió: Hi, some comments on your comments... HIMEM /INT15H=... should not be extremely hard to do, so I vote for it. That's another argument that I like: low cost to implement it. A third opinion (or more) for the untie? Eric, you say DOS5 we have it more or less, I just watch the TODO list and tell you: problems with PRINT and FORMAT, and some other utilities with bugs to be fixed, so even there not quite. DOS 6.0 not really - our EMM386 is limited, MEMMAKER not existing at all, ClamAV clamscan can replace MSAV, a VSAFE would be nice (I would like to start such a project, who wants to help? Rob?), DBLSPACE would have to be removed 0.21 versions later due to license issues ;-), BACKUP would be bought from PC-Tools, DEFRAG would be bought from Norton/Symantec, Ok, so shall we open a bank account so that we developers contribute to this purchase to PC-TOOLS and Symantec?? (sorry, just kidding, couldn't resist ;-)) some others like Win 3.11 compat should probably be fixed before we call it FreeDOS 1.0 ... More opinions on this Congrats if you have reached the end of this mail 8-). Thanks indeed. This is what I meant when I said I wanted CONCISE mails... :-( Anyway thanks for your opinion, I knew you were going to be verbose even with my notice... Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Internationalisation of HTML Help
Hi, Robert Platt escribió: OK, I'll end up in a giant mess if I try to put code page detection and information into HELP. I've been looking at things all wrong. Why not use the catalogues to translate the character entities for a given language, and stop worrying about code pages altogether? If a catalogue is being used, HELP will simply trust that the correct code page for that catalogue has also been loaded. This problem is not new. You may assume that the correct codepage is loaded, ok (Microsoft itself does that). However notice what could happen if for some reason, you had SET LANG=RU but DISPLAY for some reason failed, thus current codepage were 437. If the language were Spanish, or probably also French or German, not using 850 but 437 may be somewhat aceptable (just the capital diacritics ÁÂ...) will not be displayed correcly, and one may try to avoid these characters (I tried in FreeCOM as much as I could). If the language is RU, running the help catalog in Russian under CP437 may render the messages completely unreadable... Alongside all the more usual messages, that catalogue can contain a message for each of the character entities you would expect to use in the language. So when help comes across a character entity, it looks up how to display it in the catalogue. You mean using the catalog for the conversion? It could be a bit slow to read the file too often... Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Internationalisation of HTML Help
Hi, Robert Platt escribió: Help is often run when the user is having problems setting up FreeDOS. Their codepage could be incorrect. Help should be robust in such circumstances. It would be great if I could detect the codepage, rather than assume it. Is there a DOS interrupt or something that could do this? Well, as you suggest there would be a way to determine wether the codepage being used by the system and the codepage of the document match. There are different components in the system that might unfortunately have different codepages (e.g. by using MODE CON CP SELECT=), but I guess you are asking mostly for the codepage of the CONsole, which is the codepage of the characters being displayed (and unless rare errors, the codepage of KEYB too). The CONsole does not implement any codepage support in DOS kernel, unless you load DISPLAY.SYS (DISPLAY.COM still in FreeDOS), that implements codepage management for the console. You have the following interrupts in the DOS multiplexer (int2Fh): AX=AD00h: DISPLAY.SYS installation check AX=AD02h: DISPLAY.SYS get active codepage These calls are implemented in FD DISPLAY. If DISPLAY is not present, you should almost certainly assume that the codepage is 437 (US/English). You may find that there are other ways to obtain the system/kernel codepage (21h/6601h), but unfortunately the user may have called MODE CON CP SELECT=, and this codepage may differ from the CONsole codepage. In FreeDOS this will almost certainly occur, because we do not have NLSFUNC, which is the component that to some extent coordinates the codepage management. Now, to guess the codepage of the document/string catalog, there's no way to do this for an arbitrary text file. IBM seemed that planned this for OS/2 and DOS 4.0, so that the file system would store the codepage of each file (for those files in which this makes sense), but this was, I think, never implemented (nor in DOS 5+). All that I am saying in this paragraph is mostly what I seem to recall from reading some books. Kitten: as I understand it then, the use of correct ASCII character codes is left up to those who create the catalogues - the program does not interfere with this and just treats the message return by kitten as plain text. Makes sense. Yes. You could force the creators that one of the string variables is the codepage under which it has been programmed. The kitten messages would hence not benefit from detecting the code page. That said, help could run the character entity parsing code on kitten messages. This would allow charater entities to be used in the kitten messages. Good/bad idea? I don't know if I understand what you mean, but if you mean to map any-CP to current-CP, then mind that this problem doesn't have a good solution, just because some of the characters in the source codepage are not present in target codepage. Suppose that DISPLAY is not installed, thus current codepage is 437. Now if I write a message catalog using 850, and I use the character Á, this doesn't have any counterpart in CP 437... Unless you want to map not-found characters into a filled box or the like... Is there somewhere I can find an ASCII character map for each code page? It would save Eric the ordeal of sending me a transcription ;-) Henrique Peron may help you with this. I seem to recall a unix/linux utility called recode that may serve as source of information. Aitorç --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Internationalisation of HTML Help
An addition... Robert Platt escribió: Is there somewhere I can find an ASCII character map for each code page? It would save Eric the ordeal of sending me a transcription ;-) If you can't map in general codepage to codepage, it's almost impossible to have a decent mapping from codepage (8bit, 256 characters) to ASCII (7bit, 128 characters). Just mind that ASCII has 32 control characters, and in the remaining 96 characters there isn't much room than for letters (uppercase/lowercase), numbers, and some basic symbols. I don't think you can do much more than very basic American English with that (even for British English is not enough because IIRC the pound sign is not there ;-)). Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Don't you think its better to use Msdos file names?
Hi, I posted the message the 24th, and we all received it today. Unfortunately, I am already used to the quality of service of my ISP, Wanadoo/France Telecom... :-((( Sorry, there isn't much that I can do... Aitor Bill Marcum escribió: On Tue, Feb 24, 2004 at 09:18:28PM +0100, Aitor Santamari'a Merino wrote: Most people doesn't know that this difference even exists, and get puzzled when they open binary data files with TYPE. This message dated Feb. 24 just arrived today. Maybe it's some problem with the list or your ISP (or mine?), or maybe your system clock needs resetting. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] file to diskette
Long time ago Brian Reifsnyder wrote RAREAD to do this: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/raread10.zip I don't know if it is implemented in current DISKCOPY already. Aitor Arkady V.Belousov escribió: Hi! How to copy diskette image from file to diskette? By which utility? rawrite? URL? --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS with open source ClamAV antivirus?
Hi, Eric Auer escribió: Note that gcc / Linux and DJGPP / DOS are 2 versions of the same thing. A bit too optimistic, isn't it? AFAIK DJGPP libs lacks (obviously) all multiprocessing stuff... Could somebody with CYGWIN (which is DJGPP plus BASH plus some common Linux textutils like SED all in Windows versions) A bit too far here too... very roughly speaking, and in my understanding, CYGWIN is POSIX (or even LinuxAPI) for Win32... And the API is implemented in at least one DLL, that you are unlikely to have in DOS anyway (ok you could try to use WDOSX afterwards to try to make it work in DOS, but this would be a bit too much luck, wouldn't it?) Aitor --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] GRAPHICS / MODE moved, help with help wanted!
Hi, Jim Hall escribió: Begin3 Title: mode-modecon Wouldn't it be easier just to call it MODE? Aitor --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Please try new HIMEM64
Hi, Michael Devore escribió: There is a requirement for HIMEM for FreeDOS to work on 386+. Ooops... sorry, then I can't do the testings on that PS/2 machine. It has a 286 A pitty. Aitor --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
