Re: [Freedos-devel] /M in SHSUCDX
Many thanks, Blair. I had it on my todo list but couldn't cope with it. Also thinking of the future of this bunch of info after FreeDOS 1.0. BTW, I also agree with the XCDROM stuff, now that Jeremy (=mainainer of ATAPICD) agrees too. I assume the license of XCDROM is good enough, right? Aitor Blair Campbell escribió: Hi. Just trying to clean-up the 1.0 todo list a little. Does everybody agree to take /M off the todo list for SHSUCDX? Move it to post-1.0? Remove altogether (for a cache, CDRCACHE can be used anyways) -- Fall is my favorite season in Los Angeles, watching the birds change color and fall from the trees. David Letterman (1947 - ) See ya --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Analyzing bugzilla bugs (part 1/3)
Hi Bernd, Bernd Blaauw escribió: Aitor Santamaría Merino schreef: That was all for the time being, relpies? :-) yes. Backup current Bugzilla items and start with an empty database, so bugs are reported against either: *Beta9 Service Release 2 (out now) *FreeDOS 1.0-preview1 (planned for this Christmas) Well, I still think it's too soon for a 1.0 release (see the message part 3/3), but anyway, it occurs to me that perhaps it's a good idea that the bugs are tried with the FreeDOS 1.0 preview1, and those who still remain, add a comment like Present in FreeDOS 1.0-preview1, otherwise mark it as Can't reproduce. I'll see which bugs I can already close in the next few days. Many thanks, that's good. Aitor --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Analyzing bugzilla bugs (part 1/3)
Hi Blair, Blair Campbell escribió: 1755: INSTALL?: Problem when booting, possibly metakern involved (?) I have had a problem that sounds like this, except it is a sys problem and has nothing to do with install or metakern. SYS seems to create a FAT16 bootsector for my FAT32 drive; the Win98 SYS works fine, but even creating a regular FreeDOS bootsector with FreeDOS SYS results in a non-working bootsector (just a blinking cursor at the top of the screen on boot) Seems? or Seemed? Does SYS do this everytime? I guess no... 1854: Kernel: TurboC++ fails to run I doubt that this is still valid, as many people use Turbo C++. I'd like someone could make just one more check to confirm... Aitor --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Analyzing bugzilla bugs (part 2/3)
Hi there, Continuing the bugzilla report, the following are reported as wishes, that is, to enhance the present functionality. They are mostly not included in the TODO list, but I will include them in the post-list (that I am going to renew). I simply list there, do any of you see any of these as absolutely necessary for FreeDOS 1.0? 12: INSTALL: Add package management 609: INSTALL: Translations for Disk and Package description (translations for the programs are post-1.0) 1021: KERNEL: Treat invalid FAT entries as end-of-chain 1176: KERNEL: Third (and subsequent) floppy drives on XT class machines 1236: DOC: Improve documentation for NLS/I18N 1408: DOC: Pack/index tutorials, info… (perhaps partly done with the wiki’s) 1613: All: Support for modern hardware (sound/graphics) 1652: INSTALL: Make NLS packages be independent, so that you only get installed the files you need 1700: KERNEL: a QUIET option 1703: KERNEL: DBCS support 1742: KERNEL: Improve menuing 1744: KEYB: Supress BIOS beeping on buffer full (already annotated on my wish list) 1775: FreeCOM: FreeCOM to self-load in UMBs 1795: DEFRAG: Defrag for FAT32 (included in the general wish of FAT32 support) 1798: FreeCOM: FreeCOM to assume to be started as /P if loaded at boot. I’d see what MS-DOS is doing, perhaps this happens for them, not relying on the kernel loop to find and execute the SHELL 1799: INSTALL: Install to detect the partition type in order to install the appropriate kernel version 1824: INSTALL: Where to get updates from last distro? 1831: HTML-Help: Files64Kb 1832: FreeCOM: Use alternative file endings 1836: XCOPY: Less disk changes on xcopy /v 1840: SYS: A:SYS B: requires too many disk changes 1851: MEMMAKER 1872: LOGO support 1909: JO.SYS support --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 2.08/Nomyso 2.0 Available
I can't avoid saying Many many thanks, Michael, for your excellent work in both Nomyso and EMM386! Aitor Michael Devore escribió: Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx208.zip, EMM386/HIMEM mostly executable package (EXEs compressed via mutant UPX), and emms208.zip, EMM386/HIMEM mostly source package. Nomyso version 2.0 was uploaded to ftp://ftp.devoresoftware.com/downloads/nomyso named nomyso20.zip. nomyso is the newly chosen subdirectory for all Nomyso versions. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Analyzing bugzilla bugs (part 1/3)
Hi there, I have been listing and analyzing the bugzilla bug list, or at least, until bug 1916, and I'd like to share this information with you. I have grouped the bugs, and will expose them in three mails. In this first mail I'd like to write about two groups of bugs: one, the bugs that have been already fixed somewhere, or they are to be fixed with the versions in CVS or devel (or even inlined in the bugtrack). Alternatively, some of them would need to be CLOSED because of not being true bugs. Provided that all of the developers should “FLUSH” the CVS and devel environments before 1.0, I’d say these bugs can be closed. I’d like to ask for these bugs to be CLOSEd, or alternatively, could you please explain if there’s a good reason not to? FreeCOM: 595, 1687, 1720, 1773, 1849, 1859, 1886 (fixed in bugzilla), 1905 Kernel: 1049, 1758, 1768, 1813, 1814, 1821, 1826, 1828, 1874, 1879 FDISK: 1195, 1827 INSTALL: 1293, 1915 EMM386: 1891 EDIT: 1892 Secondly, there's a large list of bugs that were found or tested with very old versions of the components (mainly Kernel, FreeCOM, INSTALL and EMM386), or perhaps there was a partial/total fix, and it was never re-tested. In some cases, the person who opened the bug is unreachable. I would like to ask here (and in freedos-user) where you can have a look with the LATEST versions of everything, and see if the bug confirms, or gets closed. Any information you could provide is welcome, otherwise I'll give a couple of days, and pass the list to FreeDOS User's list, to give the chance for someone to say something about them. Here it goes: 423: KERNEL: Failure to notice write failure, on quicken 3.5 for DOS 998: FORMAT: Format drives 4GB 1076: FreeCOM: PowerBasic IDE 3.5 having troubles with environment variables 1538: INSTALL: Is this still true several versions later? 1658: KERNEL: Problem with the file browser of a very specific Norton GHOST version 1672: FreeCOM: Distinction of grey/non-grey arrow keys in FreeCOM (however they should behave all the same?) MORE INFO REQUIRED 1689: FDXMS: ver 0.92 not loading properly? (can someone confirm?) 1706: KERNEL: Indenture game and problem with keys: seems to be a non-FreeDOS bug? 1738: KERNEL: Drive Z: not being possible, a problem to occur with the rest in such a case 1753: KERNEL (EMM386 involved?): Invalid opcode when logging to Netware 16-bit client 1755: INSTALL?: Problem when booting, possibly metakern involved (?) 1778: EDIT: Edit to close too many windows without confirmation 1779: FreeCOM: Graphical corruption with DJGPP, possibly a non-FreeDOS bug (?) 1786: INSTALL: In some circumstances, Install abort may lead to inconsistencies, some core files copied but not unzipped… 1788: FDXMS286: lockup on application exit 1791: EMM386: behaves badly under WirtualPC. Seems to be related with tuning up EMM386 correctly, so perhaps it has been fixed with the newest version of EMM386 1793: KERNEL: Problem executing GREP from RHIDE/DJGPP (system lock) 1797: KERNEL: Crashes running in ontracked HDs without ontrack, but unknown wether other DOSes do. I’d say not a FreeDOS bug 1800: SYS: ATA systems with 16MB flash memory, crash at boot (in the bugtrack mentioned to be possibly a SYS bug) 1806: EMM386: Problem with Game Wizard 32 Pro (probably EMM386 not correctly tuned) 1810: Kernel: cannot boot from partition made with Ranish Partition Manager. I seem to recall having this problem in the past too, but not related to FreeDOS, but the way Ranish Partition Manager creates the partition. I would say a non-FreeDOS bug 1811: INSTALL/UDMA: Crashes with divide by 0, in all options except for 2. Probably fixed in UDMA, anyway installation has changed a lot, and we are now using XDMA. After checking it has been fixed in UDMA, we could simply close this bug 1825: Kernel: Problems with file sizes and clusters on OrCAD SDT 386 1.21 1830: SHSUCDX: File corruption on read from partly unreadable cdrom without error message, already fixed in SHSUCDX? 1842: FreeCOM: problem with DOS=UMB, probably lately fixed 1845: Kernel: disk access failure on ultimatebootcd 1847: EDIT: Small bugs, do these occur in the lastest version (Eric’s) that is being distributed? 1854: Kernel: TurboC++ fails to run 1869: EMM386: Problems with SECOND REALITY 1870: SYS: disk drive not recognized and hanging GRUB 1873: EMM386: Just another possible mis-tune of EMM386 with Stargunner 1900: FreeCOM: Out of memory loading STRINGS 1916: EDIT: Some weird problem on key combinations, present in latest Eric’s version? That was all for the time being, relpies? :-) Aitor --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
Re: [Freedos-devel] FreeBack - backup tool
Hi Johan, Ralf Quint was writing such a tool (BACKUP/RESTORE replacement), but there hasn't been many news from him lately here, perhaps you can say something about this, Ralf? Aitor Johan Fjeltvedt escribió: Hi I want to join the programming FreeDOS programming team, if I can help with something... I am currently working on a backup program for MS-DOS compatible systems, in QBasic (yes, I know it's bad, but I hate to learn new languages, such as C). So, I wondered if you would have any use for that in FreeDOS? Of course, if there are nobody working on it now. If I am going to write it for FreeDOS - are there anything I should look out for - something that don't work in FreeDOS as in MS-DOS, etc.)? (sorry for my bad english - I'm norwegian ...) Johan --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [OT] FreeDOS at SF
Hi there, I have incidentally visited the [EMAIL PROTECTED] page, and I've seen their new redesign, I don't know since when it's there, but wow! It definitely needed it, and it's cute now, at least to my eyes. Aitor --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0
Many thanks! Interesting... I'll see about licensing, of course. Aitor Blair Campbell escribió: (Well, personally I would not be happy with LFN being mandatory, it'd force me to entirely write LFN for Pascal, or see how FPC's LFN can be compiled for TP, as the KEYB non-resident code is, for the moment, written in Pascal, the only inheritance remaining from the xkeyb days). What about this? http://pascal.sources.ru/dos/lfn.zip (for Borland Pascal 7) --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] ANNOUNCE: DISPLAY 0.12 ready
Hi all, I want to announce that a new version of FreeDOS DISPLAY, ver. 0.12 is ready for download here: FOLDER: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/ SOURCE: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/disp012s.zip BINARY: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/disp012x.zip What's new: (1) Changes in the Codepage Prepare Logic: the Multiplexer API is enlarged to support the following two unstandard function calls: - Generic IOCTL pseudo-call - IOCTL Write pseudo-call Of course, these functions will not be available through the multiplexer, but through device driver IOCTL in version 1.0 (when it becomes a device driver). The immediate consequence: you need a new version of MODE, that has already been compiled by Eric, and that he will probably make available in the following days. With this Eric (with which testings were made) it is possible to load several codepages to be prepared at once. For example, you replace MODE CON CP PREP=((850) EGA.CPI) MODE CON CP PREP=((,858) EGA.CPI) with MODE CON CP PREP=((850,858) EGA.CPI) (2) Bug fixes: - MS-Graftabl incompatibility - Using 6 prepare buffers - Using more than one hardware codepages Happy font changing! FUTURE: DISPLAY 0.13 and DISPLAY 1.0. There are really few features remaining for a DISPLAY 1.0 true device driver. My plan is that all the remaining features are to be implemented in DISPLAY 0.13, and no new features will be accepted for DISPLAY 1.0. I just want DISPLAY 1.0 be the device driver version of DISPLAY 0.13. Some remaining features: - Improve DISPLAY/PRINTER.SYS compatibility (easier to write DISPLAY or PRINTER hardware managers) - Software codepages take precedence over hardware codepages - Several switches to allow the ussage of different memory areas (still being thinking), such as /NOXMS, /BIOS, /HMA Finally, I have a list of other possible improvements, that I have kept as wishes, but that I am unwilling to implement, first because I don't think they are too interesting, second because I don't want to delay FreeDOS 1.0 because of DISPLAY. Here you have the list, should you want any of these to be implemented for FreeDOS 1.0/DISPLAY 1.0 please try to convince me now about it, as it should be implemented for DISPLAY 0.13 (unaccepted for DISPLAY 1.0). You'll have to be very convincing, I am not feeling the appeal to implement them. Of course, code contributors for these are wellcome. (a) Ability to expand the IOCTL capabilities of more than one device driver at a simple call. In other words, the ability to sum these: DISPLAY CON:=(EGA,437,1) DISPLAY OTHER:=(VGA,437,1) on DISPLAY CON:=(EGA,437,1) OTHER:=(VGA,437,1) (b) Allow to be able to IOCTL-Write a CPI file in more than one chunk (this makes FD-DISPLAY incompatible with MS-MODE) (c) PREPARED codepages to be compressed in memory. For this I require suggestions on assembler compressing code. (d) Writing a new hardware manager for NEC Pin Writers (for PRINTER.SYS). I am unwilling, becase despite of having source to watch out, I don't have such a printer, and it's not IMHO a popular printer (it would, for example, for IBM ProPrinter). (e) Ability to use a single XMS handle for all the PREPAREd codepages (currently using one XMS handle per codepage prepare buffer). I am unwilling because most people are using just one buffer anyway. Cheers, Aitor --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Towards FreeCOM (or FreeDOS) 1.0
Hi Alain, I completely understand your point, I can't help with that now, but I assume you have filled a bugzilla entry. We would just make sure that this bug goes to the 1.0 mandatory list (forthcomming). Aitor Alain escribió: Aitor Santamaría Merino escreveu: Given the interest back of the FreeDOS 1.0 issue, I really don't understand why so much effort is put in new and 1.0 stuff and when I report a BUG in the KERNEL so serious that I had to remove FreeDOS from a real user machine I didn't even get ONE answer from the list :(( Alain --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Towards FreeCOM (or FreeDOS) 1.0
Hi Tom, Many thanks, this is the kind of replies I was hoping to have. I just add my two cents, tom ehlert escribió: I'd like to launch a proposal as well: a) remove all components that don't work like DEFRAG's that don't do anything DEFRAG's that thrash FAT32 because they don't understand FAT32 As Eric said, I think DEFRAG DOES something with FAT16. I haven't tested under FAT32, but is it documented to trash FAT32 partitions? in that case, I'll fill (or someone'll) a bug report, and it should be a FreeDOS 1.0 showstopper. b) decide which chkdsk to use; providing 2,3 or more is as unuserfrienly as possible - if YOU can't decide which one to use, how's a user supposed to choose ? This is certainly a serious issue, and I agree. I am also into removing a SCANDISK that does nothing. I remember that in MS-DOS 6.X, CHKDSK would show a message advising you to use Scandisk. Perhaps there should be a message in our CHKDSK advising to use DOSFSCK for FAT32. c) make it a DOS distribution ( ~1-2 MB), not a pile of each and every more or less useful or useless programm that happens to work on freedos; provide a hyperlink for [more packets] It is nice to have a full distribution like Blair's, but I'd personally like a compact (not just floppy) distribution, as the officials by Bernd, 10MB of what you need. Finally there are these two related to swapping. I currently ignore the status of these two, if someone can explain/advocate for these two I'd be happy, thanks. - Swapping without any supporting secondary programs (KSSF.COM and VSPAWN.COM) freecom-swap ? - Redirection in conjunction with Swapping supported by freecom-swap I remember that in older versions of FreeCOM you had to use external programs (was it KSSF?) to swap it out, but I ignore the current status of swapping. it's either freecom-swap or KSSF + CALL /S + no redirection + a couple of other issues I don't know much about the world of FreeCOM's, but doesn't this mean that this is already done, and should be marked as such in the FreeCOM milestones? (Jeremy?) Okay, as yours was almost the only opinion on that, my own is that I agree, I'd say that FreeCOM is ready for FreeDOS 1.0 up to bugs, so let's see about the rest of the programs (you already mentioned). I propose: (1) I'd like to hear what people has to say about the remaining features of ATAPICDD (DMA transfer, error checking, ASPI support, Eltorito support), I remember that it was mentioned that this program shouldn't stop FreeDOS 1.0 because it didn't exist in MS-DOS. Well, I have personally always considered that it's a real MS-DOS nuisance not to have one, and always relaying on manufacturer's file (not being able to use CD-ROM since the very installation time). I am not saying all the features, and I don't really know what is meant by error checking, but I'd say that DMA transfer is a real need, if you can notice the CD-ROM to be many orders of magnitude slower than the disk (on the other hand, it could delay the release of FreeDOS 1.0 too much). Also what is experimentally the % of hits of CD-ROM drives for which it is working? (2) KEYB, DISPLAY, NLSFUNC: They are basically finished, and with the time I have till Bernd releases a new Service Release of beta9 (or perhaps Beta10?) I hope to have the first two this Christmas at the latest. Once the advanced COUNTRY= stuff is merged into the kernel, and DISPLAY becomes a device driver, possibly it's time to think about NLSFUNC too. (3) The MEM switches: I think there's some work on that now, which I'm happy about. I personally think that this is a FreeDOS 1.0 showstopper. It is not nice when you use MEM and the switches are completely others. IMHO the stuff about PRINT should be moved for later (FD 1.1), as few people seem to be using PRINT or have complained, right? Comments please? (Next and last: buglist; OUCH! 130 listed at bugzilla, it'll be hard to read them all :-(). Aitor --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Towards FreeCOM (or FreeDOS) 1.0
Hi there, Given the interest back of the FreeDOS 1.0 issue, and in the understanding of the several calls for a near FreeDOS 1.0 release, opposing the more conservative opinions of Jeremy or myself respect to this, I have been thinking and perhaps Alain's idea of a nearer FreeDOS 1.0 distribution followed by a FreeDOS 1.1 which would fulfill pending wishes, plus the huge amount of bugs/problems that would arise from such a FreeDOS 1.0 distribution, would be an excellent compromise solution. So the idea would be that FreeDOS 1.0 does not get stalled with some remaining features (like, say, PRINT /D) that are unlikely to be written in a near future (or ever). I'd like to launch a proposal, with this points: (a) That the features that are not being demanded AND not being developed, AND not found interesting by developers be put away till FreeDOS 1.1 (but not later) (b) That the features that are not changing functionality or interface, but are optimisations or re-works be left for FreeDOS 1.1 (not later) (c) That the rest of official distributions would be called Beta9 SRx till the remaining features/bugs are fulfilled, then we would make a pre-resease of FreeDOS 1.0 and have it under quarantine Am I being too simplistic? conservative? To start with, I'd like to divide the remaining work in three parts: (1) FreeCOM (2) The rest (3) Bugs, starting with FreeCOM in this mail, left the rest for later. About FreeCOM, I ignore if Steffen is out there still developing or with interest in his wonderful project. I do not dare change his roadmap, cleanly stated in: http://freedos.sourceforge.net/freecom/FreeCOM.html#-status But I am starting to reconsider wether all of them are needed for a FreeDOS launch, and I would suggest, of course guided by Jeremy or other people, such as Tom or Bart, that know well about the internals, that the features are changed in order, so that those features required for FreeDOS 1.0 are put first. For example, to my mind the following two would be essential: - INT-2E backdoor - Wildcards for REN, same filename pattern matching code for REN, COPY and DIR Whereas there seem to me like optimisations that may be left for later (FD 1.1), whichever the FreeCOM version is (1.0 or not): - Input/output functions to replace stdio.h by io.h (aka replace FILE*-based I/O by handle-based one) - Strict error recognition, probably _doserrno based - Code sharing of modules I ignore what is meant by DOS=HIGH, does it mean that FreeCOM would request DOS for swapping a piece of HMA, if possible? Finally there are these two related to swapping. I currently ignore the status of these two, if someone can explain/advocate for these two I'd be happy, thanks. - Swapping without any supporting secondary programs (KSSF.COM and VSPAWN.COM) - Redirection in conjunction with Swapping I remember that in older versions of FreeCOM you had to use external programs (was it KSSF?) to swap it out, but I ignore the current status of swapping. [Constructive] opinions? Aitor --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0
Hi, Blair Campbell escribió: Hi. I just thought that I'd start a topic before I left for two weeks about a FreeDOS 1.0 release. It has been suggested that I release my Beta 9 Enhanced Release distro as a FreeDOS 1.0 pre-release distro. For one, this would mean that it would get tested more frequently, also it would (possibly) encourage people to get the unfinished tools done, or fix any bugs that unfinished tools have. What does everybody think about this? Is FreeDOS almost ready for a I'm sorry, but my own opinion is NO. First of all, there are features about MEM, AtapiCDD and why not, DISPLAY that should be finished before 1.0 (doing my best on my part, I promise). But worst of all, the large number of bugs already existing. I doubt that naming it 1.0 would encourage users to patch the 42 existing kernel bugs. In my opinion, a good step towards it would be to start monitoring existing bugs to see which of them are considered for 1.0 or for post 1.0. This was tried sometime ago, but I guess it lacked interest/coordination. Also we should be very careful about a FreeDOS 1.0 with bugs that may discourage potential users (or better) developers. 1.0 release? One must remember that FreeDOS now surpasses MS-DOS in several ways, such as support for LFNs in some tools. One also must remember that there are tools that are incomplete or missing. Another thing to bear in mind is that MS-DOS 1.0 was not NEAR as finished as FreeDOS currently is, and that MS-DOS didn't even reach a complete Operating System until 3.1, and many more tools joined MS-DOS by 6.22. MS-DOS 6.22 had a decent disk scanning tool, we lack ScanDisk, for example. Is FreeCOM stable enough for a 1.0 release? Is ATAPICDD really needed to reach 1.0? How far away is KEYB from being ready? What would it take to finish print? Is MEM nearly complete? Can TDSK be replaced by another ramdisk driver? Would another ramdisk driver need to be MS-DOS compatible? Is the /M switch needed in SHSUCDX for 1.0? ATAPI: I think it'd be a very good point ahead MS-DOS to have own CD driver, otherwise we would have a FreeDOS that, as MS-DOS, requires of manufacturer's CD-ROM driver to work properly with modern hardware. KEYB: very close, a couple more of versions, same for DISPLAY. PRINT: no-one is working on that MEM: who was working on that? progress? Once these questions are answered, one needs to also consider what MS-DOS incompatibilities are considered acceptable, and what things could be postponed to a post-1.0 release. Sorry Blair, you joined late. We already *HAD* this discussion VERY VERY often, and last time it was agreed what there is actually in the FreeDOS 1.0 TODO list. So this would be to re-open the same discussion once and once again. Another thing that warrents attention is the question of what things from the post-1.0 todo list should be in a 1.0 release, and what things from that list are simple enough to make their way into a 1.0 If there are things already implemented, and more or less follow the general rules (NLS settings support, compatibility with exitcodes, etc) could be added, but I'd discourage to re-open the discussion of what post-1.0 things should be moved back to 1.0 things. cannot test this myself, even though I want to. About LFNs: Some think that LFN support should be mandatory in all FreeDOS programs for a 1.0 release. I personally do not feel that way, but how hard would it be to write a wrapper that simply allows for recompilation of programs to achieve LFN support? Would it be hard to make a dblspace/drvspace/stacker clone using large amounts of code from the linux fs driver dmsdosfs For all compilers, for assembler, etc? FAT32 users be able to manage without a defragger? What about NLS support? Should the number of programs which use kitten become expanded (which isn't really all that hard)? What about NLS support in programs coded in assembler? Should there be a version of kitten for assembler (as there is for pascal and C)? Is it necessary for Please, do NOT mix NLS things with string translation. NLS support (date/time, numeric, etc) is marked as mandatory, string translation isn't. HIMEM and EMM386 to have CPU checking? Should LBACache be a device driver and should CDRCache be merged in? Does undelete need FAT32 support and wildcard support (which I would particularly like to see... I have used undelete *.* once :-) )? Would a memmaker clone be difficult to write using the edit TUI or the defrag TUI? Of course, the post-1.0 list (that I agree with Eric, needs to be sorted out) admits merging everyone's personal TODO list. To sum-up, I don't think it's a good idea to make developers again be tired of the same 1.0 stuff (Blair, could you please read back the mailing list archives?), but I hope this can serve to open the question of which remaining bugs are for 1.0 or for post 1.0. Aitor
Re: [Freedos-devel] re: FreeDOS 1.0
Hi Eric,
Sorry, I'm SO lazy to read all this...
I just skip to the things pointing to me.
Eric Auer escribió:
Hi! Very nice topic :-)
I know you like it, but we have discussed this once and once again...
For KEYB, Aitor's TODO lists memory tuning, PC-XT support, Japanese
API (?), beeping (?) and a layout librarian. I think PC-XT support is
required for 1.0 (unless you say PC-XT users must use MKEYB) while
the rest would be very nice but not 100% required...
memory tuning, beep and PC-XT support are to come. The rest are already
implemented (it says KEYB 2.0 pre-3, that is, current version).
MKEYB can NOT be used in XT software, as it relies in the int15h
interface, not present, AFAIK, on XT's.
FD-KEYB implements this for XT, but the only problem for 1.0 is that I
use PUSHA/POPA for the resident stuff, and that I compile the
non-resident stuff with the {$G+} directive. Of course, this is the easy
part, the difficult part is to do the changes and TEST.
By the way, about ANSI DISPLAY MODE NLSFUNC: Work good enough for me
but do not yet model MS internals closely. And PRINT PRINTQ: Rarely
I hope DISPLAY will be ready in 2 more versions. MODE and NLSFUNC will
have optimally to share sources for what remains.
used, but adding device selection and buffer sizing would be
quite feasible if we want to shorten the 1.0 wishlist.
Again, who volunteers? talking is cheap.
Generally: We started by wanting to clone MS DOS 3.3x, now we
clone 5.0 and include several clones of 6.xx add-ons even. We
and of 7.10.
I would suggest that 1.0-preview style of PR, collect test results,
decide what should be fixed even BEFORE we release Blair's 1.0 preview
distro (I imagine things like wait for a new KEYB and MEM snapshot,
but no ground-shaking updates, as we are busy with waiting all the time).
I support this, but in a later stage, not NOW. I continue to support
Jeremy's idea to call the next release BETA10.
Aitor
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: FreeDOS 1.0
Hi, Eric Auer escribió: Hi Aitor... I'm sorry, but my own opinion is NO. First of all, there are features about MEM, AtapiCDD and why not, DISPLAY that should be finished... I would suggest to drop ATAPICDD from that list. And how is that you suggest it NOW and not THEN? But worst of all, the large number of bugs already existing. I doubt that naming it 1.0 would encourage users to patch the 42 existing kernel bugs. This might be strongly correlated to people losing interest in a project which does not even reach version 1.0 after eleven years... My idea would be that if we start calling things 1.0-preview (as in beta 9 release candidate some people will wake up and check those 42 bugs again - and probably find that half of them already ARE fixed but nobody had tested since kernel 2024. I agree that we need testers in order to close those that do not exist. But I disagree that people will start testing because you call it pre-release or pre-view. Our original goal was to start with MS DOS 3.3x compatibility. If you look at MS's versioning scheme, version 1.0 did not even support directories. Calling FreeDOS a pre-1.0 beta implies that we did not even manage to reach DOS 3.3 functionality. Only insiders know that we hesitate because our goals have grown to, say, cloning MS DOS 7. We have already discussed about the Spec, and how we are already chasing 5.0 rather than 3.3. In any case, to mention something that won't hurt anyone, MS-KEYB 3.3 could run on PC/XT. So there are things to have ready (again, working on that), and most important, the infamous 42 kernel bugs, and a similar number of bugs in all the rest. Given the freeze in most aspects of FreeDOS development I would say it is not good to always raise the goals without sometimes sitting back and being proud of what we reached so far AND settling and debugging that state. Instead of getting a certain level stable I agree. that is the newest official complete FreeDOS distro until we give the great comprehensive Blair FreeDOS distro a more charming name. It feels far better than a release candidate for beta 10. To me it feels more a preview of version 1.0 (not the 1.0 itself, as some things are still on the wishlist). And the thing is: for how long do you want to have a pre-release till the official release? At the speed bugs are fixed lately, it will be an unacceptable amount of time since the presumed 1.0 pre-release till the final 1.0. So please be cautious. I think it'd be a very good point ahead MS-DOS to have own CD driver FreeDOS - never reached version 1.0 but surpassed MS DOS 8 long ago, historicians could write ;-). Excuse my cynism, but a CD driver is nice but no standard part of what you get when you buy MS DOS. So if we find some resources to put into ATAPICDD, cool, if not, that would not stop FreeDOS from ever reaching 1.0 either. Okay, I agree. I continue to think that you should have said this in the previous discussion, though. I collected everything that was said. KEYB: very close, a couple more of versions, same for DISPLAY. I would suggest PC-XT compatibilty going first. I assume MS DOS was at a version number far above 1.0 before it supported Japanese and MS DOS did not even ever have a layout librarian at all... Sure, but do you volunteer to use your (presumed) XT and test? Please, do NOT mix NLS things with string translation. NLS support (date/time, numeric, etc) is marked as mandatory, string translation isn't. Right... But see above: We need testers, otherwise we never know where NLS support is missing. Most people who use FreeDOS at all just use it in English mode, I guess. Or maybe there is no feed- back because all except number layout (1.000,00 versus 1,000.00) already do meet NLS requirements?? Perhaps, but if someone complains then that's a big functional bug, as it was agreed the tools would meet that. I don't think it's a good idea to make developers again be tired of the same 1.0 stuff... I think most developers REtired because they think their work is finished and nothing is left to do for 1.0 - so we are in a dilemma about reaching 1.0, speed lowers as we approach 1.0 :-(. Talking is cheap, let's end this thread and work. Aitor --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Arkady Belousov - please answer me!
Hi there, Arkady V.Belousov escribió: 7-Окт-2005 15:08 [EMAIL PROTECTED] (Henrique Peron) wrote to freedos-devel@lists.sourceforge.net: HP From: Freewolle Voluntar Because we in public group, I translate our discussion. fv Me was asked to translate FreeCOM messages to ukrainian and I do this. fv Translation is correct. ... To see ukrainian characters in FreeDOS, next fv commands shold be performed: HP DISPLAY.EXE CON=(EGA,,1) HP MODE.COM CON CODEPAGE PREPARE=((1125) EGA4.CPX) HP MODE.COM CON CODEPAGE SELECT=1125 HP KEYB UR,1125,UR.KL -^^--^^ Strange name for layout - isn't Ukraine shortened as UA? This one goes to Henrique :) fv And I can't switch back from ukrainian to latin mode (after switching by fv Left Alt+Right Shift). I download Keyb (with sources) and study them, but, fv unfortunately, don't clear up this question. This question to Aitor Santamaria_Merino (aitor.sm at wanadoo.es), author of KEYB. I am in process of getting rid of the wanadoo address. Please use aitorsm at inicia.es instead, thanks! Regarding the question itself, whichever key combination has been used to go back depends on the layout itself, so this goes back to Henrique too :) (unless KEYB is not doing as it should). Incidentally, I think I have fixed the infamous DEL key problem, I am just working on other minor bugs that I have introduced with the library support, and when it's ready we'll have another version. Aitor --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DJGPP on FreeDOS LiveCDs
Hi, Blair Campbell escribió: almost 100% TP-compatible code), perhaps GhostScript, the DJGPP LaTeX Ghostscript is in the next release but LaTeX is HUGE (at least on linux), and I'm not considering it at present. Ok, good work anyway. But have you seen the DJGPP-LaTeX? I seem to remember it wasn't that big, but I may be wrong. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] A dilemma affecting next DISPLAY
Hi there, FD-DISPLAY is about 11KB size (the data for the 3 subfonts, 8x8, 8x14 and 8x16 is 10.5Kb). MS-DISPLAY is about 5KB resident size (the size of 8x16 is 4KB). Following Eric's step, I can use a single data pool to load the data into memory (I no need to make room for the three subfonts. I load one after the other), but I am facing this problem: Some Display Adapter interrupt functions (INT 10h) hooked by DISPLAY.SYS are there to get pointers to font data (yes, get pointers, not filling user's buffers). If I can only have 5Kb resident, I can only have room for one subfont permanently in main memory. Thus, the only idea that comes to my mind is that I leave there the data only for the current subfont in use (8x8, 8x14 or 8x16), and the request for the other pointers are diverted to BIOS. This way one would have the problem that if your program asks for these pointers, the characters of each subfont may differ (as BIOS is always codepage 437, it could be that the character number 200 is one character in 8x8 and another in the 8x16 font), but I can't come up with other idea, any hints? Notice that it's not use to put resident the data for the last requested subfont, because a program could well retrieve the three pointers at the very begining and try to use the three of them within the code. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DJGPP on FreeDOS LiveCDs
My personal opinion is that there should be the core and most useful apps in a single big package. Perhaps you should consider this an additional package, and release two CDs: one small without aditional things, one big with the additional things. There's also some other great GPL DOS Software (for additional packages), such as FreePascal (DOS branch is not kept up with the most recent changes, where multithreading was added, but the latest DOS release is pretty good and stable, and can create 32-bit apps from almost 100% TP-compatible code), perhaps GhostScript, the DJGPP LaTeX distribution, etc. Aitor Blair Campbell escribió: Hi all! I'm considering adding DJGPP to my FreeDOS ISOs and would like the opinion of everyone. This is a big change as it will probably add at least 50 MB to the size of the ISO. If I do end up adding it, should it be on the livecd? What components should be available? Should it be available in several split packages or a big monolithic package? (a bunch of small packages would be difficult to maintain, but would provide a way for a minimalistic DJGPP install, while a monolithic packages would be easy to maintain, although meanwhile a user may get a bunch of components he doesn't want.) --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: SCREEN=? for 43 lines
Hi, Eric Auer escribió: See RBIL about fonts: V-101112 load 8x8 font, so SCREEN=0x12 loads 8x8 font. Similar cases are 0x11 (8x14 font) and 0x04 (8x16 font), although the latter is not useful as this font is the default anyway. After being loaded, if you have chosen to use certain codepage, DISPLAY will care to port and use the appropriate fonts for all modes (8x8, 8x14, 8x16). Other font resultions are currently unsupported. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Chasing MS-DOS compatibility
Hi, Eric Auer escribió: Stable kernel supports at least 2 countries - Germany and USA - so people can test whether NLS date/time format selection has an effect. This does not need nlsfunc or country sys... Because current implementation of COUNTRY= is hardcoded, but would need COUNTRY.SYS if the unofficial stuff comes to light. You do not need NLSFUNC if you are not going to change codepages anyway, as most of the people do (use a single codepage for kernel/COUNTY, CON(DISPLAY/KEYB) and PRN(PRINTER)). Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: SCREEN=? for 43 lines
Hi, Eric Auer escribió: See RBIL about fonts: V-101112 load 8x8 font, so SCREEN=0x12 loads 8x8 font. Similar cases are 0x11 (8x14 font) and 0x04 (8x16 font), although the latter is not useful as this font is the default anyway. After being loaded, if you have chosen to use certain codepage, DISPLAY will care to port and use the appropriate fonts for all modes (8x8, 8x14, 8x16). Other font resultions are currently unsupported. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Chasing MS-DOS compatibility
Hi, Bernd Blaauw escribió: Alain schreef: I said not long ago that running windows on FreeDOS is not a real test, let me explain why: Windows at some point included some very complicated locking mechanism to *avoid* windows running other DOSes. AARD is only on beta releases, as was mentioned several times. well, Windows 3.x and DOS were separate products at the time. DR-DOS can run Win3.x, so for FreeDOS it should be possible. I am of this opinion, too. I'm not saying that things should be programmed so that Win3.x actually runs. However, running Windows 3.xx error-free on FreeDOS would show that the FreeDOS components don't have a lot of critical bugs. ALSO it makes an old computer actually usable again (for win3.x applications, and in a legal way if you own only a win3.x license for the specific machine) The thing is that Windows /S runs up-to-bugs. (Hopefully Windows 3.0 also runs in Real Mode). Lotus was an important program, so there could be sometings in this allegation. But, will someone *use* Lotus in FreeDOS? I sincerely doubt. if Lotus would be public domain, then maybe. Probably no-one is running DBASE either. Linux(, Windows) or ReactOS in combination with your wanted application type seem to be the way to go. Just a small correction, you are probably talking of 1-2-3, the spreadsheet+database+graphics. Just remember that Lotus is the brand name. Talking of running Lotus is as senseless as saying you are running the program named Microsoft. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Chasing MS-DOS compatibility
Hi, Eric Auer escribió: DEFRAG was taken off the list, because so many freeware / shareware / commercial defraggers exist - or because many people run FreeDOS in a DOS emulator like VMWare or DOSemu, and defraggers aren't needed... I disagree here. I have no idea what happened to Imre more than a year ago, but it would still be very nice to have a FAT32 defragger. Not even Linux has one yet. There is PC Mag DEFRAGR, but that can only do FAT16 and has no real user interface. Our DEFRAG can be nice and useful. Other defraggers exist, but are not open, not free, or both. Not optimal. I'm with Eric here. http://wiki.fdos.org/Main/Todo_1_0 - can somebody name a few tools for which the wrong errorlevels are returned? I assume it would not be too hard to fix them. Which EL are used by DYNALOAD, by the way? http://wiki.fdos.org/Main/ExitCodes Well, it can be left there as guideline so that users can report a possible bug - are there still tools which display DATE/TIME without using COUNTRY settings, or fail to do COUNTRY stuff for alphabetic sorting and upcase or downcase (except EDIT 0.7d upcase/downcase block functions ;-))? Same here - Aitor has bold plans with KEYB, as usual A new version is forthcomming. An important upgrade I'd say. - PRINTER SYS, which printers should be supported by it?? Remember that GRAPHICS supports HP PCL, ESC/P2 and Post Script, differs from MS style but felt like a good choice. IBM Proprinter and some others are supported. I'm planning to debug DISPLAY source so that it is so generic to be used as PRINTER (in a separate file), but the problem is that we lack of CPI files for printers (except Matthias Paul's Nec PinWriters). If anyone else knows of CPI files for printers, it would be appreciated. - FORMAT, please report any remaining bugs. In my original idea, the items in YELLOW are there because there are entries in Bugzilla, FORMAT does still have 998 open. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Chasing MS-DOS compatibility
Hi, Eric Auer escribió: Stable kernel supports at least 2 countries - Germany and USA - so people can test whether NLS date/time format selection has an effect. This does not need nlsfunc or country sys... Because current implementation of COUNTRY= is hardcoded, but would need COUNTRY.SYS if the unofficial stuff comes to light. You do not need NLSFUNC if you are not going to change codepages anyway, as most of the people do (use a single codepage for kernel/COUNTY, CON(DISPLAY/KEYB) and PRN(PRINTER)). Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Chasing MS-DOS compatibility
Hi, Bernd Blaauw escribió: Alain schreef: I said not long ago that running windows on FreeDOS is not a real test, let me explain why: Windows at some point included some very complicated locking mechanism to *avoid* windows running other DOSes. AARD is only on beta releases, as was mentioned several times. well, Windows 3.x and DOS were separate products at the time. DR-DOS can run Win3.x, so for FreeDOS it should be possible. I am of this opinion, too. I'm not saying that things should be programmed so that Win3.x actually runs. However, running Windows 3.xx error-free on FreeDOS would show that the FreeDOS components don't have a lot of critical bugs. ALSO it makes an old computer actually usable again (for win3.x applications, and in a legal way if you own only a win3.x license for the specific machine) The thing is that Windows /S runs up-to-bugs. (Hopefully Windows 3.0 also runs in Real Mode). Lotus was an important program, so there could be sometings in this allegation. But, will someone *use* Lotus in FreeDOS? I sincerely doubt. if Lotus would be public domain, then maybe. Probably no-one is running DBASE either. Linux(, Windows) or ReactOS in combination with your wanted application type seem to be the way to go. Just a small correction, you are probably talking of 1-2-3, the spreadsheet+database+graphics. Just remember that Lotus is the brand name. Talking of running Lotus is as senseless as saying you are running the program named Microsoft. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Chasing MS-DOS compatibility
Hi, Bernd Blaauw escribió: http://wiki.fdos.org/Main/Todo_1_0 - can somebody name a few tools for which the wrong errorlevels are returned? I assume it would not be too hard to fix them. Which EL are used by DYNALOAD, by the way? http://wiki.fdos.org/Main/ExitCodes http://home.earthlink.net/~rlively/MANUALS/INDEX.HTM seems like a nice and usefull template. Wow! Also the FDOS wiki should have a section on current popular DOS software and how to get it working on a bootdisk. Arachne, NTFS4DOS, maybe Supaplex or Stunts or so, Mark's radio program, etc.. May I mention DJGPP and FPC? PS: Note that the 1.0 list does not ask for Weitek support in EMM386 :-). The post-1.0 does. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: re: Your software on our CD/DVD/Internetsite
Okay, I remember telling in the FPC list my concerns about the ussage of FPC programs in machines laking 387, and I was told there was an emulator. It seems that it's optionally linked to code, and I guess there's a compiler directive to do so. I don't know if the author of the graphic installer is reading this, but in this case, it's just a question of recompiling with $E: From the documentation: 1.2.8 $E : Emulation of coprocessor This directive controls the emulation of the coprocessor. There is no command-line counterpart for this directive. Intel 80x86 version When this switch is enabled, all floating point instructions which are not supported by standard coprocessor emulators will give out a warning. The compiler itself doesn’t do the emulation of the coprocessor. To use coprocessor emulation under DOS go32v2 you must use the emu387 unit, which contains correct initialization code for the emulator. Under LINUX and most UNIX’es, the kernel takes care of the coprocessor support. Aitor Blair Campbell escribió: Please can you confirm that 387 is required (and the FPC emulator does not work)? I've tried the SVGA installer on my 386sx and it failed misrebly. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: What's new with latest kernel/freecom?
Hi, Personally I prefer the single-executable solution, rather than the creation of several executables that may take many room in your disk. Precisely I have recently finished debugging the new KEYB, that will support single KEYBOARD.SYS-like data files, instead of multiple KL files. So it's going in this opposite direction. In my opinion, it is more worth to save several tens of KBs of disk space for small distros than 1Kb of ram (nevertheless, ram optimisations are scheduled for the future too). Aitor Alex Buell escribió: On Thu, 28 Jul 2005, Aitor Santamar�a Merino wrote: There's a very small program that sets up the UK keymap; KEYBUK.COM, which is only 432 bytes long. I use this instead of KEYB to squeeze as much as memory as possible out of the UMBs. I don't know if you mean MS-DOS old style KEYB, that was splitted in several different programs (KEYBUK.COM, KEYBSP.COM, KEYBGR.COM). No, KEYBUK.COM is not Microsoft's. It's freely available for download. All it does is to set up the keymap for UK keyboards but I think it could be adapted for other countries' keymaps, perhaps compiling into a small COM for each country using a template and a country keymap. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: FreeCom daily builds
Hi, Andreas Berger escribió: Aitor Santamaría Merino wrote: Sorry, FreePascal, the Free Pascal compiler, open source compiler which is quite Turbo-Pascal compatible, somewhat Delphi compatible, and to my experience, stable and very well documented. According to enquiries, the most widely used Pascal compiler after Delphi and TurboPascal. The only drawback: it cannot generate 32-bit code (changes would be big: the 4-byte pointers are 32-bit offsets rather than seg:ofs pairs, etc, etc). You sure about that? The FreePascal compiler for DOS goes to Version 1.0.10 which is 32 bits. Support stopped here because newer versions have threading which is not natively supported by DOS. OOPS! My fault, I wanted to say: cannot generate 16-bit code! Of course, it's a 32-bit compiler. A pitty that support stopped there... I am just wondering if I compile for DOS with threading and run my app, renamed to KRNL386.EXE, under Windows95... :) Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: 386-kernel crash: Eric is guessing
Hi, Alain escribió: tom ehlert escreveu: IMO, scince FS, GS, and the high parts of EAX,... aren't used by MSDOS as well, drivers can get away when they destroy these resisters, so it's a good idea to save them as well. This gets complicated when Kernel is 386 optimized. MS-DOS never modified this because it is 16-bit. It could be argued that if a kernel is to be compatible it cannot modify them either. Now the other way round: can the kernel be sensistive to 386 registers being modified by drivers? IMHO not, because the original one is not and hence some drivers will stop working. Then I believe that it is the kernel resposibility to preserve it's registers. Well, I disagree. As it was posted, drivers are to preserve registers. Anyway, can't this be the cause why EMM386 + 386-optimised kernel are not working together? Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Master environment?
Hi, Eric Auer escribió: Hi, I did a bit of thinking about the master environment search... - you can use the parent PSP segment word at PSP[0x16], but this gets into a loop not only for FreeCOM but also for DEBUG. Are other programs affected by that as well? A trick explained by Tom (IIRC) long time ago, to make a memory region not being discarded at exit time is to make it self-parented. Of course, you won't invoke a program from KEYB (unless in future version I come up with the idea of using keypresses to launch programs, if we would like to make some use of the email and web buttons in the keyboard; in any case, far away future). Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: FreeCom daily builds
Sorry, FreePascal, the Free Pascal compiler, open source compiler which is quite Turbo-Pascal compatible, somewhat Delphi compatible, and to my experience, stable and very well documented. According to enquiries, the most widely used Pascal compiler after Delphi and TurboPascal. The only drawback: it cannot generate 32-bit code (changes would be big: the 4-byte pointers are 32-bit offsets rather than seg:ofs pairs, etc, etc). Aitor GNU_man escribió: What is FPC? On Sun, 2005-24-07 at 01:55 +0200, Aitor Santamaría Merino wrote: It is quite usual that everything that applies to DJGPP applies to FPC too. Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: [Freedos-cvs] freecom/cmd dir.c,1.20,1.21
Hi, Florian Xaver escribió: Hi! true, but according to TC docs, toupper() supports EOF (-1 I believe) to 255 and any non-lowercase item is returned unchanged; so no check should be necessary. I suppose we could explicitly check for a letter argument and return syntax error if not (since not a drive usually), then change to use _toupper macro or even straight bit manipulation (anding off bit 5 I think). OS like Dr-DOS support more than the aphabetical drives. There is f.e. [: possible. Even more crucially, Netware 4.0 supported this too, AFAIK. Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS and path limit 64?
Hi, Johnson Lam escribió: I found that FreeDOS unable to handle DBCS, those Chinese and Japanese Windows always have this kind of characters as folder and filename, that need to FORMAT, lots of trouble Portuguese version. Not too many strange characters... Single byte European characters should be OK. Since most of them 128 ASCII, Chinese and Japanese use up all 255. I would not say so, specially for languages using diacritics (éö etc), that is basically to say other languages than English. Even the pound sign I seem to recall not to be ASCII, which amounts to say that ASCII is just perfect fit in the United States, where it was invented. For most European countries ASCII is too narrow, you need a full codepage. In western countries (roughly speaking, you exclude cyrilic and greek), codepage 850 (or better, 858 = 850+EURO) should be preferred. Incidentally, I am not much an expert on Asian language representation, but I have understood that for Japanese only, you can live with a keyboard driver that produces single=byte characters, and the FEP program would convert that to Japanese charset as appropriate. This will be one of the new features to be supported by next FD-KEYB, amongst many others. As far as I know, there's unfortunately nothing to do about Chinese and Korean, altough I might be wrong. I have the english version all nicely wrapt up in GPL package. But... last version is not compiling in english. I will send you one soon. Thank you very much! Because the FREE DELTREE always refuse to work properly. You mean FD DELTREE? perhaps you should register this to bugzilla. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: What's new with latest kernel/freecom?
Hi, Alex Buell escribió: On Tue, 19 Jul 2005, Aitor Santamaría Merino wrote: Working on penultimate versions of DISPLAY and KEYB already :) There's a very small program that sets up the UK keymap; KEYBUK.COM, which is only 432 bytes long. I use this instead of KEYB to squeeze as much as memory as possible out of the UMBs. I don't know if you mean MS-DOS old style KEYB, that was splitted in several different programs (KEYBUK.COM, KEYBSP.COM, KEYBGR.COM). It's freely available and disassembling it should help you out with creating an ultrasmall KEYB executable... Thanks! However, if it's Microsoft's, I am not interested in disassembling, not only because of possible legal issues, but also the architecture of both drivers is far too different (and regarding the keyboard behaviour, we have Henrique Peron, who knows very much about this). I am also trying to make it quite general, which implies to be a bit bigger. Anyway there are things to be worked on in future versions to reduce it from the approx 1.5Kb of current versions, in particular, getting rid of the PSP and I'm also going to try making the resident/assembler part to be completely independent from the transient/pascal code, so that I save some FARPTR references. But this is for future versions, in the forthcomming version you'll at least be able to use a single KEYBOARD.SYS file (instead of several KL files), so that you can save some disk space too. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: What's new with latest kernel/freecom?
Hi, Eric Auer escribió: Hi Alex, Working on penultimate versions of DISPLAY and KEYB already :) There's a very small program that sets up the UK keymap; KEYBUK.COM, which is only 432 bytes long. I use this instead of KEYB to squeeze as much as memory as possible out of the UMBs. KEYB is meant to be universal, supporting all possible and impossible keyboard layouts with the help of separate definition files. The last limitation that I remember is that you cannot say scancode ... should be treated as AltGr key or otherwise redefine shift keys themselves. Sorry, I cannot understand this, can you explain a little bit? If you want a SMALL keyboard driver, I can really recommend MKEYB (see freedos.org software list). This has more than 20 built-in keyboard layouts, is a single small file on disk (7kb UPXed) and has very small memory footprint (512 bytes). True. The only problems you may come across come if you do (unfrequent) operations such as playing with different codepages, as AFAIK MKEYB layouts are bounded to a single codepage each. Aitor --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: EMM386/DOSLFN
Hi, Michael Devore escribió: MEMCHECK checks for illegal INT 15h function 87h memory transfers to/from the real RAM address range -- the CHECK and MEM parts of the MEMCHECK option -- and dynamically builds and sets two scratch page tables to allow the access to occur if it is outside of normal RAM range. Otherwise an exception is generated because the memory ain't there to access. Generally you don't want to allow such access because when it happens it usually means something has fundamentally screwed up and it scribbling across invalid addresses or overshot the mark. However, with memory-mapped I/O (MMIO), high addresses outside the normal RAM range are used to talk to a peripherals and the computer bus. The EMM386 MEMCHECK option was written so that MMIO devices don't auto-fault when using INT 15h to transfer bytes in those ranges. Now that MMIO is becoming more common, it would nice to automatically allow MMIO access without having to specify the non-default MEMCHECK option, while still keeping normal protections against faulty or crashed application memory scribbling. Hence the idea of 3-4G address space MEMCHECK behavior on by default. The non-default MEMCHECK option would still be available for someone who needs to transfer to or from addresses below 3G which remain outside of the normal RAM range. Downsides for the proposal are loss of wild memory access protection in 3-4G range and additional (extended) memory of 16K always, rather than optionally, consumed. Plus some nanoseconds of check address overhead on each transfer. Anyway with this protection would mean in most cases that something within the app would be going very bad, and would crash sooner or later. If you consider MMIO to become more and more popular, I would vote for making it default. It may be boring to test, but does anyone know what does MS-DOS do? Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: EMM386, Kernel, and Help
Hi, Eric Auer escribió: When using EMM386 there is a problem with help where help either reboots or gives an error and locks-up the machine... this is an old problem, and fixed, but no binary released. This sucks. Release an update. You have had the binary for months. How unpolite!. And I do not care whether the binary has a mismatch with the sources / whether you only have PATCHES instead of updated SOURCES or not. Just release that thing. Jeremy can help you to release updated SOURCES after that. AFAIK there's no official HTML-HELP maintainer, so this can be also a question of DO-IT-YOURSELF (and it wouldn't be the first time that you do such things, so...). Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: re: EMM386, Kernel, and Help
I dislike the style of this kind of letters, specially when directed to Bernd and Jeremy, who appart from others (like Michael or yourself, also testers like Alain, and many more) are working quite actively to get the project alive. Eric Auer escribió: What stops you from collecting those files yourself? Having to work, simple. Just as the rest of us, mere mortals. Perhaps you haven't noticed this. I appreciate very much your work in many projects, even with work you seem to have more time to commit to FreeDOS than the rest of us, which is good. But your messages are full of please do this, please test this. And after all I am NOT the FreeDOS distro maintainer. Guess who is. Having at least a delta-update twice per year is really not asking too much. I am not asking for a whole new ISO every few months or anything. You know how many bugs got fixed since 12/2004, and people still have to update every file manually. (Now if there would be at least a LIST of things which got updated since...!) D.I.Y. Rant mode: I do not care whether ODIN is a daily build or a manually uploaded diskimage. Nor do I care whether it is by you or by Jeremy. But I really hate having to tell people again and again that they have to update several packages after installing ODIN or FreeDOS beta 9 sr 1, also having to tell people the URLs or at least names of all those packages again and again. The wasted time would probably have been enough to update beta 9 sr 1 *and* ODIN myself in the meantime. But am I the maintainer? No. Do I even have a CD-writer to test such an updated ISO image? No. Sorry guys. There's something you can do. Create a webpage called FreeDOS upgraded components since Beta9 xxx, with a table of the components that have been upgraded, the latest versions and link to where to get them. You are plugged to the list just as the rest of us are, so there wouldn't be problems to have it updated, specially because if the page is made public, developers would also be interested in having it updated (thus you would be informed). Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Hope for HTMLHELP, peace on the list, and a new ISO (was: EMM386, Kernel and Help)
It seems I was a bit late with my reply to Eric. Needless to say I agree with Robert. Aitor Robert Riebisch escribió: Joe Cosentino wrote: You are an asshole. Did you notice Eric's Hope for ... peace on the list? I think, that Eric is *not* an asshole. He already did a lot for FreeDOS (you too). He probably was a little overmotivated... Please calm down both and return to normal work on FreeDOS! Robert Riebisch --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCom daily builds
Hi, Bernd Blaauw escribió: Note: I switched it so the cmdxms builds have loadfix loadhi, and these are disabled in the cmd8086 builds. WARNING: loadfix is completely untested by me! If you can test it, please let me know if it works correctly or not. old HTMLHELP binary required it somehow. Sorry, old HTMLHELP requires what?? Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: FreeCom daily builds
Hi, Eric Auer escribió: Hi Bernd, Jeremy, can you reduce the number of files which are downloadable? I guess the non-XMS build is most universal, despite the high memory consumption then. The non-XMS build is really only useful if you cannot provide XMS by any means. In other words, the non-XMS build is useful for 8086 and is useful to test if it helps to use a shell which does not use XMS, not much more. When one says the 286+ versions it means that it has been optimized for 286+ processors (i.e. compiled with 286+ opcodes), or that there's some additional code? Perhaps in the later case it is possible to have 286+ specific stuff be placed in a memory region to be discarded on the 8088, so that one can reduce the number of versions. Remember that you only get all FreeDOS features on 386+ with more than 1 MB of RAM (the SVGA installer is even worse, it needs a FPU and a system with more than 4 MB of RAM). I don't know if there are SPECIFIC issues about the installer, but if it has been compiled with FPC, there is no specific need for a coprocessor, it is emulated if there isn't any. Same for the memory requirements, I would test it on a 2MB machine before telling if there is such need. It is quite usual that everything that applies to DJGPP applies to FPC too. Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCom features desired?
Hi Jeremy, Perhaps a bit too late, but may I remind of Steffen's list? I think it's a nice one. Note that I'm not saying that I consider the listed features as most important, but I think there are some which are nice. E.g.: - Swapping without any supporting secondary programs (KSSF.COM and VSPAWN.COM) This seems to be implemented isn't it? - Wildcards for REN (still missing?) Kenneth J. Davis escribió: As bugzilla is still down (not that this is really there or should be) I would like to open a discussion. I make no assertion that I will implement any of these, but I'm curious and just may. What features in command.com would people like to see implemented? Please provide reference to full syntax and example usage. For example if there is a particular 4DOS syntax you like and FreeCom does not support it, then point me to the command and its documentation. Or maybe you want an extension that NT's command has. So far I know of CD ... syntax, which I believe is equivalent to CD ..\..; optionally where each additional . is one more .. down. I would like it to support LFNs. Currently I know DIR does, and I know CD needs it, probably also FOR. Any other commands? md/rd? How to enable and disable supporting them? and how acceptable is 7BIT ASCII only support, at least initially? Well, there's one that was on my personal pool, but I'd be grateful if you could implement it. - Expand $P on PROMPT to the LFN version, if LFN is enabled. As for the LFN extension to DIR implemented by Tom, it isn't a full LFN support, but just a way to make it more readable. Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Support for Hard Drives bigger than the BIOS allows
Hi, As I am a bit behind on reading mail, I don't know whether you have been replied already, but if this is still open, I judge it interesting enough to fill an entry on bugzilla, for the records. Could you please do this? Aitor Blair Campbell escribió: I would like to see if possible support in the kernel to see partitions that are bigger than the BIOS allows. In my case, I have a 386 and its kernel only allows for hard drives up to 201 MB, and I have a 700MB drive in it (The smallest drive I have available.) I am able to partition it using a linux boot disk to get all 700 MB out of it, and both DR-DOS and MS-DOS will recognize the drive, but the FreeDOS kernel just gives an error and continues, ignoring the partition. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Support for Hard Drives bigger than the BIOS allows
Hi, Eric Auer escribió: PS: If MS DOS allows you to access a drive which is bigger than the reachable range of your BIOS then MS DOS has a bug. It should ONLY allow you to access drive letters (partitions) on your harddisk which are ENTIRELY inside the reachable-by-BIOS range (usually at least 504 MB even for old BIOSes). Why? If it behaves nicely with data stored beyond BIOS range then it seems it's doing well... Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: EMM386/DOSLFN
For the records, from the FPC documentation: 203 Heap overflow error The heap has grown beyond its boundaries. This is caused when trying to allocate memory exlicitly with new, getmem or reallocmem, or when a class or object instance is created and no memory is left. Please note that, by default, Free Pascal provides a growing heap, i.e. the heap will try to allocate more memory if needed. However, if the heap has reached the maximum size allowed by the operating system or hardware, then you will get this error. Aitor Blair Campbell escribió: Just being curious: Does adding some EMM=... option to EMM386 make any of your programs crash which would otherwise work? I just tested a variety of programs with EMM=4019 and SEAL2 and the Free Pascal IDE crashed. Both worked fine without the EMM=4019 option. With SEAL2 it just finished the splash screen loader and then some miniscule lines of text too small to read appeared on the top of the screen and CTL-ALT-Del refused to work. With FPIDE it gave me this error: Runtime error 203 at $001AAD20 $001AAD20 $001AAE5A $001AAFAB $001A9C77 $001B0B10 $001A88C5 $001B154A Another problem I ran into (not sure if it is a FreeDOS problem) is that both with Cutemouse 1.9 and 2.0 the cursor didn't show in the IDE although I was still able to click on the menus. Blair Campbell --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] x-comment to Johnson Lam
Hi, Johnson Lam escribió: On Sun, 10 Jul 2005 23:55:13 -0300, you wrote: Hi, If they have MS-DOS,that is. Remember it is no longer available from Microsoft. Probably neither PC-DOS nor DR-DOS will also last for long. Even if they do, it is much better to have a free and open source OS than a proprietary one. Yes, I agree. But sadly, FreeDOS still not v1.0, that means it's still have some kind of bugs. which is cause, which is consequence? ;-) My point is, if the program run smoothly in FreeDOS, fine! But just like my Chinese System HAN, never works in FreeDOS, I have no choice but to use MS-DOS, in this period I can't switch to FreeDOS, and I'm willing to see the FreeDOS directions towards New Hardware for old software (of course new software will works), so in MY opinion, development should be 386 oriented and have a 8086/286 version. I agree with this, and if simplicity in the number of versions available is an issue, have 386+ and 8088 versions (being 286+ optimized is ok whenever possible, and whenever the differences between the 286-optimized and 386-optimized versions are small. Furthermore, this is something already done, I assume, but such versions should clearly say 386+ optimised version or 8088 version clearly in the /?, or this may become a nightmare of versions when a user reports bugs. Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: What's new with latest kernel/freecom?
Hi, Eric Auer escribió: *integrate user-provided drivers in the freedos distribution, for example cdrom drivers or USB drivers (not yet possible to implement). Definitely not worth the effort, I think. Complex, not failsafe, and users who cannot EDIT their CONFIG SYS should better not use DOS anyway. Well, you cannot EDIT files on CD-ROM, but as said earlier, just let users exit to a PROMPT, tell them about PG load-those-drivers.txt which contains info about DEVLOAD, and let them run INSTALL BAT as soon as they either got the drivers running or got the CD contents pre-copied to some directory on harddisk in any way of their choice... Time ago I had a thought at this, a simple pattern recognition on filename and then a list of lines to be added here and there. However I agree with Eric that hard (for example, after/before EMM matters). *allow uninstallation of FreeDOS (not yet possible to implement) There were two commands in MS-DOS related to this: DELOLDOS UNINSTALL PS: How about adding NLSFUNC and the updated DISPLAY / MODE (not yet public)? Working on penultimate versions of DISPLAY and KEYB already :) Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Your software on our CD/DVD/Internetsite
Hi, The ISO still uses the graphical installer, which needs 3-4 MB of free RAM and a 486dx (386 plus FPU, that is), do we care? The text mode installer is free from those pointless InstallShield-cloned looks and pointless klik-thru GNU license and it would work on pre-486dx/8mb PCs. I assume that the graphic installer maintainer doesn't like to hear wether we care. I don't know what's wrong with the new installer, as I seem to remember that you can choose the one you like within the install process, which is ok. I also seem to remember that on pre-486 machines (non VGA) the text mode installer is chosen automatically. Some eye-candy and some easiness for choosing disks, packages, etc will not harm, avoid them and use the text mode installer if you like. Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Re: re: More speed test
Hi, Eric Auer escribió: Memory moving to/from HMA is quite fast, as is moving inside low RAM. Enabling / disabling HMA (A20) can take time, but A20 is usually on most of the time anyway, and as said, FreeDOS EMM386 even blocks attempts to switch A20 off. MS EMM386 instead provides a fast A20 simulation created by page mapping. Is there a technical reason (i.e. other than I don't have time/interest) for this to be made so? If I were asked to implement it, mapping would be my choice. Aitor --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Away from email
Hi, (Sorry for catching up now) My public sorrow for you, Jim (even if late). Still available to cooperate and help the project and you as required. Aitor Jim Hall escribió: Hi. I've just been informed that a close family member of mine has died. So I'll need to leave right away for the funeral. I expect to be away from my email for the next week or more, and even then I don't think I'll be much into doing email for a while. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Advise from Jack Ellis about SHSUCDX 3.02
Hi, Eric Auer escribió: The 3.00 version was EXE, the new version is a COM. An exe can tell how much RAM it needs minimum, a com cannot. If you UPX a com and try to load it into e.g. a too small UMB, then the UPX decompressor inside your compressed program will abort and the com will just return to the prompt without any error message... Something similar happened to current versions of FD DISPLAY, then the solution was: use Arkady's COM2EXE, then UPX. Aitor --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Advise from Jack Ellis about SHSUCDX 3.02
Hi, Eric Auer escribió: The 3.00 version was EXE, the new version is a COM. An exe can tell how much RAM it needs minimum, a com cannot. If you UPX a com and try to load it into e.g. a too small UMB, then the UPX decompressor inside your compressed program will abort and the com will just return to the prompt without any error message... Something similar happened to current versions of FD DISPLAY, then the solution was: use Arkady's COM2EXE, then UPX. Aitor --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] emm386 2.0
Hi, Jim Hall escribió: Michael Devore wrote: We had this discussion. I say that until there's a FreeDOS database, SourceForge archives work about as well as an ever-growing mongo huge READ.ME file. I also say that I've allocated -- overallocated -- as much free time to working on this as I can afford from my real life and any more nonprogramming overhead (and I do too much already for my taste) is a nonstarter. Do you mean something like this: http://www.codeweavers.com/site/compatibility/browse/cat?cat_id=113 They list a bunch of software, then give it a rating Gold, Silver, Bronze, Honorable Mention, Known not to work or list it as untested. And there's a link to more details for each program. iTunes, for example, gets a Bronze. Looks like people get to vote on how well it works, and I suppose there's an average taken to generate the final ranking. Looks a nice page, are there useable automated scripts for this? (even Hardware could be categorized). Aitor --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [TEST]
List quiet or...? Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] XMS Manager on '286
Hi, Arkady V.Belousov escribi: They may preserve much of 3.3 in 5.0, they may rewrite most of 3.3 in 5.0 - this is unimportant. Fact is: 4.0 and 5.0 are sufficiently different from 3.3. Another example, changed INT25/26 and introduced support for FAT16 more than 32 Mb (ie., partition type 5). I agree. ASM but I think it goes much further than that: Contraditcion: don't think is an improvement or goes much further? ASM This sort of things happens when one does not want to understand. ASM diff (MS-DOS 5.X, MS-DOS 6.X) diff(MS-DOS 3.30, 5.0) ASM where is the sign meaning in phisics MUCH LESS. I agreed with last sentence, but you start this thread from contrary sentence (I don't think MS-DOS 5.0 is an improvement over 3.3). Ok, add I don't think MS-DOS 5.0 is merely an improvement over 3.3. ASM improved memory management, Improved? DOS' memory management is too dumb to improve it. Or, you mean additions in MM for UMB and HMA? ASM For me, the ability to use the extended memory is an improvement. But DOS doesn't deal with extended memory, this is issue of external driver (himem, qemm, etc). (Ok, you may begin discussion - is himem part of DOS or it independent. But fact is: you can't allocate extended memory through INT 21.) At least the kernel implements DOS=HIGH, DEVICEHIGH=, etc ASM (4) The necessity to comply with RBIL was questioned in this list time ago And? ASM Just to mention some. ? You mean: spec should mention RBIL as reference source? ASM No. I mean that I can't remember exactly the stage, but there was a ASM moment where MS-DOS behaviour does not go along RBIL, You mean, RBIL contains bugs in some descriptions? ASM and the spec ASM mentions RBIL in this case (although it claims about MS compatibility too). I can't understand your intention, idea of these your sentences. You wish to say, that RBIL descriptions somewhere differs from MS-DOS behavior and this somewhat should be reflected in spec? I seem to recall that this happened once, long time ago. But I don't dare say the author of such a mail, in case I'm wrong. Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] XMS Manager on '286
Hi, Arkady V.Belousov escribi: Hi! 16--2005 10:00 [EMAIL PROTECTED] (AITOR SANTAMARIA MERINO) wrote to freedos-devel@lists.sourceforge.net: ASM (2) I don't think MS-DOS 5.0 is an improvement over 3.3, even It is: HMA and UMB, config menus, new/documented APIs (and ASM Ok, let me re-phrase: of course it is based on 3.30, Same, as Linux based on Unix or WinXP based on Win9x. Wrong example: Linux has nothing to do with a Unix in its implementation, whereas the USER INTERFACE Microsoft Windows 5.10 (I believe?) of WindowsXP is the successor of the UI MS-Windows 4.X/5.X or WinXP/ME. I don't think that MS have rewritten MS-DOS 5.10 either, but it is based on the MS-DOS 3.30 sources. ASM but I think it goes much further than that: Contraditcion: don't think is an improvement or goes much further? This sort of things happens when one does not want to understand. diff (MS-DOS 5.X, MS-DOS 6.X) diff(MS-DOS 3.30, 5.0) where is the sign meaning in phisics MUCH LESS. ASM improved memory management, Improved? DOS' memory management is too dumb to improve it. Or, you mean additions in MM for UMB and HMA? For me, the ability to use the extended memory is an improvement. ASM and response to WIN386 broadcast messages are just two examples. ASM (4) The necessity to comply with RBIL was questioned in this list time ago And? ASM Just to mention some. ? You mean: spec should mention RBIL as reference source? No. I mean that I can't remember exactly the stage, but there was a moment where MS-DOS behaviour does not go along RBIL, and the spec mentions RBIL in this case (although it claims about MS compatibility too). Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: [Freedos-user] XMS Manager on '286
Hi, [Moving to devel, in the understanding that this is more internal). Michael Devore escribió: At 04:36 PM 3/13/2005 +0100, Bernd Blaauw wrote: probably better, make HIMEM compatible to 286+, which would end up in a single unified XMS driver. Adamantly and permanently opposed. And you might be too, with the potential size increase and performance decrease in HIMEM after the significant rewrite to regress the instruction set on all XMS 2.0 and admin code down from 32-bit registers to 16-bit. Nowadays I would just as soon write in 6502 or Z-80 assembly language as pure 16-bit 80x86 (except stubs), which is to say, only if somebody paid me to do it. For the microscopic percentage of 80286-level clients, just use FDXMS286. Simple readily available solution. Fix it if it's broken, no big deal. Why mug HIMEM when it's so unnecessary? I must say that I agree with you, at least in practical purposes. The problem arises, formally, because the spec (http://fd-doc.sourceforge.net/spec/) is clear about XT compatibility. There are other things about the spec that I also disagree. Furthermore, we are close to FD 1.0, and if current FD were released as 1.0 (bugs and todo list appart), we wouldn't even comply with the spec. I know I might face opposition, but I think that this spec, made 10 years ago, was made when many less things about MS-DOS were made, and in a period where the processor/OS market was on another level. I believe that there are parts of the spec that deserve a major rework, not just patches. In particular, and to mention some, (1) (minor) Microsoft will not develop DOS forever... = Microsoft ceased to develop DOS (we know this well, after their WinME). (2) I don't think MS-DOS 5.0 is an improvement over 3.3, even if you just watch the many differences in the LoL. Perhaps that is closer to be true if you say that versions after 5.0 are improvements (even with FAT32 support in 7.10). It is time to consider if we should specify that we are for MS-DOS 3.30 where the distributed kernel is closer to 5.0 (or to 7.10 I'd say) (3) The forcing of 8088/80286 should perhaps become strongly recommended and not mandatory (4) The necessity to comply with RBIL was questioned in this list time ago (5) I personally agree that commands must compy with MS syntax, even if we distribute programs that have a completely different syntax (such as MEM or ctMOUSE) (6) Date format: I guess it was made before NLS was better known to developers. I would replace it by use NLS (7) Reference compilers: I continue to be BC3, whereas it was mentioned repeatedly in the list the convenience of OW. Same for NASM over MASM/TASM. Note however that this could become a strongly recommended, because there are programs like EMM386 (TASM) or KEYB (TASM / TP) that are unlikely to change their code to reflect the spec. (8) Perhaps the (TM) statement could go there too. Just some ideas Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos aceesses c:\ ?
Hi Tom, (Sorry for the CAPs, I am forced to use webmail or other PCs, and I haven't reviewed thoroughly the configurations), I mean is it possible to get an emulation of a 1.4MB writable driver into memory (not ElTorito or such). Aitor tom ehlert escribió: Hello AITOR, 3) Burn a bootable CD with floppy emulation with disk image above, and put flash data in content What is a bootable CD with floppy emulation? What program does this? a bootable CD, where the bootcode emulates a floppy (and not a HD) tom --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Questions on EMM386 (part2 and last)
Hi, Arkady V.Belousov escribi: MD I don't think it affects anything important. MD As far as UMB's, I'm not sure if turning off the A20 line affects memory MD mapping from physical odd-address Mb. Seems like it should, Michael, strange to see such sentences from you. A20 is a pin of (186 and higher) CPU, which used to pass 21th bit of address. When this pin is disabled, all access with addresses like :200 (which make 21-bit address) are wrapped (by ignoring high 21th bit on A20 pin) to first 64k. This shouldn't affect any addressing in the UMB, which lies below 1Mb. I can be missing something, but the enabling/disabling of an Address line of the processor affects physical adresses, and not logical or linear adresses. UMBs are remapped to another linear/physical adress that may lay beyond the 1MB physical address, and can thus be affected by the A20 enabling/disabling. I repeat that what I meant is to remap/not to remap the HMA adresses into the first 64Kb. Not more, not less. Aitor --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Questions on EMM386 (part2 and last)
Hi Michael, Thanks for your reply. Michael Devore escribió: Now one more future wishes question: I guess that after Michael's excellent work through VCPI and VDS, the next remaining big todo for EMM is to have XMS/EMS shared memory pools, does it mean that EMM's XMS manager is enlarged to XMS functions that make use of the existing free pages for allocating EMBs? No. I've figured out how I want to do it via direct manipulation of XMS handles. Your post preceded by one day a new release HIMEM which supports INT 15h function 4309h. This exposes raw XMS handles via API call. I don't seem to find it on RBIL, undocumented or made-up? Aitor --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] keyboard layout
Dear Karsten, There are such tools. You write a keyboard layout in the form of an ASCII text file (in the KEY language). Then you compile this file with the latest KC (KEY compiler), to obtain a binary KL file that you can use with the latest KEYB. Links: Latest KEYB: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kb2pre2x.zip Latest KC: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kc110x.zip About the documentation on the KEY language to write the layouts, the package that includes KC has some documentation, although it is not very good, and I'd need to rewrite it. Please ask me (in private if you wish) for whatever isn't clear. If you want to use commands specific for FD-KEYB, then you can obtain a commandlist of FD-KEYB in the same package of KEYB. Finally, you could obtain the sources for the standard keyboard layouts shipped with FreeDOS and customise them for you. They are distributed in the KEY language under the GNU GPL license. Latest sources are: Layouts based on DOS codepages: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kblayout/KPDOS11S.zip Layouts based on Windows codepages: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/kblayout/KPWIN10S.zip Regards, Aitor Karsten Schenk escribió: Hello, can anyone tell me how to write an own keyboard layout. Are there tools available? I would like to include French characters in my German keyboard. Merry christmas to all Freedos programmers/users out there. Greetings Karsten Schenk --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 for USB flash drives
Jim, could you please post here an URL to the slashdot article? Thanks! Aitor Jim Hall escribió: Michael Devore wrote: Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx13c.zip, EMM386 mostly executable package, and emms13c.zip, EMM386 mostly source package. Now then, no more name and directory changes. ... Thanks! I've mirrored this release on ibiblio, and posted a news item on FreeDOS.org. When I posted your LSM, I noticed that the version number still read 1.13b so I changed it to 1.13c. -jh --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Dumping C000-EFFF
Hi, Johnson Lam escribió: On Fri, 3 Dec 2004 06:52:17 +0300 (MSK), you wrote: Make next file (say, DUMP.DBG): d c000:0, d d000:0, d e000:0, q then run DEBUGDUMP.DBGDUMP.RES (without quotes) and you get dump in file DUMP.RES. Be carefull - its size is 970k, so archive it before sending. 1) debug dump.dbg (file not found) No, COPY CON DUMP.DBG 2) d c000:0, (screen output) 3) d d000:0, (same) 4) d e000:0, (same) 5) q ^Z 6) debug dump.dbg dump.res (file not found) DEBUG DUMP.DBG DUMP.RES Am I miss anything? The redirection signs :-) Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Questions on EMM386
Hi there, I have started reading EMM386.ASM (not the latest hot version, but the previous one, not many changes I assume), and although I haven't yet finished, I think I'd need a couple of hints on some things there. BTW quite an interesting pierce of work! :-) I suppose some of them are related to TASM rather than EMM, I'm best used to NASM, and don't even know all of it. Anyway here we go. Thanks to all that can give a hint. (1) Constant EXT and variable _MONITOR_ADDR EXT is a measure of something in KBs, and _MONITOR_ADDR is in MBs. In GO_PROTECTED, _MONITOR_ADDR seems to be used as the base of some kind-of heap whose pointer is tracked in EDI. Why EXT=14KB, and why _MONITOR_ADDR is 1MB (ok, base real memory) + 1024*EXT? Why that 14 and why you add those 14MBs (not KBs) to the begining of this heap? (2) What is the meaning of this structure? How much memory does it weight actually, or how does the assembler determine that? (the bit that I ignore is the (?)) RES_STACK SEGMENT PARA USE16 DB V86_TOS DUP (?) RES_STACK ENDS (3) Why do several ASM labels begin with @@? For example: @@UMBloop @@UMBnext do those @@ have any meaning? (4) What are those special comments/marks for? What are they indicating? They are all over the sources ; (*-9-*) ; (#-9-#) (5) In the startup of the driver, it is set 00AAh into memory 0040h:0072h, but I can't find references to this BIOS variable, what is that? (6) Finally, a simple and un-intentioned question about TASM/NASM. Is it feasible that EMM386 be ported to NASM? I mean, of course the answer could be YES, but it is worthless, but I just want to determine wether there is any actual problem, or it is just that it is a lot of work for little gain. I seem to remember Tom saying it was not feasible, but so was VCPI, so I am afraid I mis-interpretated your comment, Tom. More questions coming when I finish reading the sources. Thanks in advance, Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Questions on EMM386
Hi, Michael Devore escribió: As it is currently a quite active development project, any nontrivial changes to EMM386 unrelated to fixing a verified bug should be sync'ed through me or Tom. Unannounced code changes to EMM386 could make Michael cry and misbehave. Sure :) Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Questions on EMM386
Hi, Kenneth J. Davis escribió: ... It was more interesting to have ATAPICDD in NASM, but I am not sure if the port has the same maturity as the original MASM/TASM version. At least it helps to test patches for ATAPICDD that it can be compiled with free compilers / assemblers. But you still need spare time for that :-(. ... actually current ATAPICDD, which is now split into cdrom.sys ataspi.sys to separate the CD code from the IDE/ATAPI code uses FASM. Could you extend a little bit on this? ATASPI for the ATAPI/ASPI layer and CDROM over it (which means I need to load two drivers, isn't it?), or ATASPI for ASPI CD-ROM, and CD-ROM for ATAPI or...? And in this case, CDROM will be the char device and ATASPI a TSR...? Aitor --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Changing e-mail address
I guess the trivial way: unsubscribe with this, subscribe with the new. Aitor Andreas Berger escribió: Sorry for this OT mail, but how do I change the e-mail address that this list will use to send messages to me? Andreas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [OT] A Sync program
Hi there, Sorry for the OT, does anyone know of a good and free (to download, not necc. open source) Win32 program that can be used to synchronise the contents of a folder A with the contents of a folder B, that is, copies and replaces all the files in B that are newer than files in A or inexistent in A (no need to touch folder B)? Ok, I could use Windows Explorer, but it has two problems: (1) I don't like that it is not recursing directories very nicely (it says it will replace files without confirmation). This problem is more or less ok, because I think in A there aren't files newer than those in B, but (2) Explorer will overwrite ALL files, thus it can be slow. I would prefer it if it would not overwrite files that match in last modification date, e.g. Any suggestions wellcome, specially if they are prompt (I'd love to do this sync before this weekend). Cheers to all, Aitor --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Mirror sites
Jim Hall escribió: Anyone here the webmaster for these mirror sites? They are out of date, and I may drop them from the list: http://freedos.rediris.es/ (site unavailable??) Over here it works well... (it has the beta9 release announcement). One thing about this files archive in this site: it seems that when you add files to the original site, they are added, but when you remove them, they are not removed, and thus, sites (such as the KEYB site) get untidy, because old files are still there. Compare: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/ http://sunsite.rediris.es/mirror/freedos/files/dos/keyb/ Aitor --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] DOS networking
Hi, Sorry for a slight offtopic, I am trying to find some online references about the MS-DOS/Windows9X networking pieces, does anyone know of something about that? In particular, I am higly interested in knowing about the meaning and configuration of PROTMAN.EXE, NETBIND.EXE and PROTOCOL.INI (I have found these programs online, but they don't have any valuable /? help). Thanks in advance, Aitor --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM/EMM386
Hi, Michael Devore escribió: To avoid inflaming the issue, I'm not going to ask why all new documentation is desperately needed to be written for something which has behaved effectively the same way for end-users for the past six months. And roughly 20 years for MS-DOS, as far as general behavior. If it's really all that horribly important, someone send me a target spec and I'll invest time crafting a document that shall cause the hard-hearted to cry tears of joy such beautiful literature has flowered and brought documentary peace to the FreeDOS universe of scribblings. Or, at least it will contain examples, both marginally readable and modestly accurate, of nouns and verbs conjoined in syntactic grouping. I don't know if I am understanding what you refer to, but in my opinion nobody is saying that new documentation is desperatedly needed to, say, describe thoroughly the behaviour of such tools. Before Rob took over HTML-Help, the help files there were (as Tom correctly complained repeatedly) info taken from MS-Help, thus useless for FreeDOS users. And I don't think it's too much of a quarrel to write a couple of HTML-files describing, for example, that there is no /INT15= option in HIMEM, and that we have instead /TEST, for example. An easy place where to find what the commandline is. 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] 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
