[Freedos-devel] Fw: turbovision etc
Forwarding back to the list in case anyone else is interested: - Original Message - From: David O'Shea [EMAIL PROTECTED] To: Eric Auer [EMAIL PROTECTED] Sent: Sunday, January 29, 2006 11:08 AM Subject: Re: turbovision etc Hi Eric, http://www.freedos.org/freedos/news/technote/104.html suggests that Turbo Vision won't compile with free Turbo C++ 1.x. Also there is the licensing issue of Turbo C++ 1.x in regards to what is the definition of personal or private use that we are allowed to perform with it :) I guess I'm also a bit concerned that Turbo Vision could be bloated too. I had a look at Defrag. It looks like the UI code must not be too bloated as the EXE isn't all that big, but the code isn't designed for reuse - e.g. the code for the menu includes the actual menu items in it rather than having some generic menu module that you pass your menu items to. I think it would be a fair bit of work to make the code nicely reusable and shareable between Defrag and Mem :( I think I will have a look around to see if there are any similar, open-sourced libraries out there we could use instead of me having to do all that work to Defrag (and then test to make sure I didn't break it!). Regards, David - Original Message - From: Eric Auer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 28, 2006 8:41 PM Subject: turbovision etc Hi, I recommend a TUI which compiles with free 16bit compilers. You can try to compile turbovision with Turbo C 2.01 or Turbo C++ 1.02 for example. The EDIT TUI is probably too bloated for MEM. I think the TUI of DEFRAG would be a nice idea (and we need somebody who can maintain DEFRAG a bit ;-))... Eric --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Turbo Vision or other Textual UI tool?
Hi Arkady, From: Arkady V.Belousov [EMAIL PROTECTED] Date: Sat, 28 Jan 2006 11:04:25 +0300 (MSK) 28-ñÎ×-2006 13:11 [EMAIL PROTECTED] (David O'Shea) wrote to freedos-devel@lists.sourceforge.net: DO different TUIs, and Turbo Vision has been suggested to me too. Turbo Vision DO however doesn't seem like it would compile in real mode with Open Watcom DO without a lot of work so it doesn't seem like a good option for now. What DO good options are there for a TUI that will work with Open Watcom?? TVision for DOS, OS/2, DOS32, WIN32 by Ilfak Guilfanov This is a TurboVision v1.03 (originally by Borland International) bugfixed ported to: Operating systemCompiler = MS DOS Borland C++ v3.1 MS DOS 32 bit (DOS4GW) Watcom C++ v10.0 OS/2Borland C++ v1.5 for OS/2 OS/2Watcom C++ v10.0 WIN NT (and Win'95) Borland C++ v5.01 WIN NT (and Win'95) Watcom C++ v10.0 All known bugs of TVision are fixed. Where can this be obtained from? Obviously in its current state it is not too much use since Borland C++ 3.1 isn't free and with Watcom it only compiles 32-bit executables, but perhaps it would be easier to port to Open Watcom for 16-bit DOS executables than the other Turbo Vision versions I've seen. Regards, David --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: HTML Help MEM
Hi Geraldo, Thanks for your reply. I see you made some updates to the MEM help page. There are lots of new commands now so I have a lot more updates to make to it. Mind if I make those and then send you the new page? Also do we need to try and be brief in the text so as not to consume too much disk space? I know the files are ZIPped up but was wondering if we still need to be careful? Thanks in advance, David --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Turbo Vision or other Textual UI tool?
Hi all, If I wanted to make some kind of interactive MEM tool, what would the preferred TUI to use be? It seems like FreeDOS' EDIT and HELP programs use different TUIs, and Turbo Vision has been suggested to me too. Turbo Vision however doesn't seem like it would compile in real mode with Open Watcom without a lot of work so it doesn't seem like a good option for now. What good options are there for a TUI that will work with Open Watcom?? Thanks, David --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS website
Hi all, How come all the URLs on the FreeDOS website are of the form http://www.freedos.org/freedos/something? I assume it was not always this way because fdos\doc\mem\bugs.txt refers to http://www.freedos.org/bugs; which doesn't seem to exist anymore. It would be nice if the old URLs still worked so that users who try to report bugs can do so without geting any 404 Not Found errors. Regards, David --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] HTML Help MEM
Hi all, I recall some discussions about HTML Help not being maintained anymore so I was wondering how I would go about contributing an updated help page for MEM such that it's integrated into the latest HTML Help download. Thanks in advance, David --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Turbo Vision
Hi all, For anyone who is working with Turbo Vision, if you want a WYSIWYG dialog designer tool, I think there are other non-free ones out there, but FYI dlgdsn is officially shareware but it's as good as open source - I contacted the author and it's just up to me to get the source to compile and then release it. See http://tvdlgdsn.sourceforge.net/ for more info. It might take me quite some more time before I manage to get to a stage where I can get it to compile as I'm busy with a new job :( Regards, David PS I have been working on MEM a bit more, slowly getting there.. --- 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] Kernel Problems
Hi Arkady, From: Arkady V.Belousov [EMAIL PROTECTED] Date: Thu, 8 Dec 2005 15:38:43 +0300 (MSK) This is not strange, because 29 buffers fit to remains of HMA, DO Anyone know if there's a way that MEM can check what the kernel is storing DO in HMA, specifically with regards to buffers and other things which can DO cause confusion in this way? No. FreeDOS doesn't splits HMA to blocks with headers, similar to MCB in conventional memory. Could we maybe store a char or word in HMA which is at a standardized location which we can read if we know we're running FreeDOS? I'm not sure what MS-DOS does in this respect? Regards, David --- 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] MEM - any changes made in my absence?
Hi Bernd, Eric, all, Were any of the bugs I created/propagated resolved while I was away or were any other changes made? I want to get back to fixing bugs but want to make sure I'm working with the latest sources. Thanks! David --- 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] Kernel Problems
Hi all, From: Arkady V.Belousov [EMAIL PROTECTED] Date: Sun, 27 Nov 2005 16:52:50 +0300 (MSK) 27-îÏÑ-2005 12:58 [EMAIL PROTECTED] (Andreas Bollhalder) wrote to freedos-devel@lists.sourceforge.net: AB Something stranges happens here. AB BUFFERSHIGH=29 - 615kB conventional and 150kB upper memory free AB BUFFERSHIGH=30 - 599kB conventional and 150kB upper memory free This is not strange, because 29 buffers fit to remains of HMA, whereas 30 already not. Anyone know if there's a way that MEM can check what the kernel is storing in HMA, specifically with regards to buffers and other things which can cause confusion in this way? Thanks in advance, David --- 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] MEM will miss my deadline
Hi all, Sorry, some bad news. I will not be able to get all the changes to MEM done before I lose Internet access. I will be offline for about 3 weeks starting at the end of this week. I will make a partly messy snapshot of the sources available before I go, but the key issue of 8086/80286 support will not be addressed yet as I just haven't had time. The documentation will be lacking too. I'll check the changes into CVS. If nobody objects I might call this another alpha version for now. In my absence others can feel free to make changes, and the translators can start to translate, although I may not have time to even bring the non-EN NLS files up-to-date, i.e. add the English strings that need to be translated, although hopefully I will because I imagine it would be painful if I didn't do that for you all. I'm hoping that after the move I should be able to spend more time on MEM, especially if I can't find a job :) Regards, David --- 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] Compiling FreeCOM...
From: tom ehlert [EMAIL PROTECTED] [...] if you want more features, make it compliable with watcom I think I would find this an interesting project but I should wait until MEM is done :) From: Bernd Blaauw [EMAIL PROTECTED] [...] I think Jeremy's descript.ion support has to be inserted into the build process, Thanks. Maybe that's my problem, I don't remember now :) Guess I should read up about what the difference is between these large/normal/small models. In the OpenWatcom help you can find this by going to: WHELP CGUIDE then scroll down to 16-bit Memory Models. There may be better/clearer explanations available via Google though! From: Kenneth J. Davis [EMAIL PROTECTED] [...] regarding the descript.ion thing not working, are you sure it was compiled in No, I'm not sure! or was that why you were building? (not sure why you were trying to build in large model though It was mostly due to cluelessness. I wanted to build with debugging support, debugging symbols seemed to require large memory model due to the added code space, so I tried that. I didn't know what I was doing :) see Tom's remarks, basically not going to work, even if you manage to get an executable) So it's pointless to build a large model executable even if I don't want XMS-SWAP? Can we never ever have large model? Thanks! David --- 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] MEM and CVS
Hi Bernd, Diego and Johnson, From: Bernd Blaauw [EMAIL PROTECTED] [...] Diego Rodriguez schreef: Will it work with 80286 processors ?? Why doesn't work with 8086 ones ?? MEM still has some 386-specific machine instructions which are not present in earlier processor generations (386 is 32bit CPU, older is 16bit CPU). Or the queries for XMS are not protected by 'if not 286 or later, return [not_available]'. Actually I found that Eric sent me some detailed instructions about what he thinks needs to be fixed so I will try and address all those additional places we need to do 386 checks and probably release a special MEM.EXE which has some debugging stuff built in so you can specify MEM /DBGXMS and it will output a trace of the checks and other stuff the XMS code is doing so we can tell where it hangs (if it still does). AFAIK, there isn't a CVS, you simply make a MEM19X.ZIP archive with binaries and a MEM19S.ZIP archive with sources, upload them to ibiblio and announce it at freedos.org http://cvs.sourceforge.net/viewcvs.py/freedos/?only_with_tag=MAIN#dirlist I'd also recommend to upload as a package. Blair and Jim have access to Ibiblio. Jeremy has access to Sourceforge (empty project so far), and I've access to Jeremy's fdos.org server. Plenty of locations possible. SourceForge isn't empty - http://freedos.sourceforge.net/mem/ has some files. From: Johnson Lam [EMAIL PROTECTED] [...] I'm currently working on a few minor issues. As for the bigger issues=20 of MEM not working on 8086 machines without /N[OSUMMARY] being used,=20 adding PCTools-like output, and possibly other things I've forgotten,=20 I'd rather leave these for later than possibly delay the next release=20 of MEM for too long. I hope nobody objects to that. Can you release as beta and notice on the program help (mem /?). Or temporary force /N until manual override? So most of the users can run it Yes, Bernd made the same suggestion to me about forcing /N on pre-386 machines so if I can't fix the code I will at least do that. I would like to call the release 1.9 instead of 1.8 due to the=20 fact that 'MEM /?' with the 1.8 alpha 1 version actually shows 1.8=20 and it would be nice to avoid confusion. I will make sure that the=20 next alpha release shows 1.8a2 or 1.9a1 or something to avoid=20 wasting more version numbers :) Any objections? I agree. Since you add PC-TOOLS like output screen, this is quiet a changes. Actually I'm afraid I haven't added that yet, sorry! It is on the wiki though as a future enhancement - see http://wiki.fdos.org/Main/Mem Perhaps you could help me by sending me a text file including MI /? and then all the different combinations of options it supports. If you could attach it as a text file instead of pasting it in the email it might be better because in the email you sent the formatting got messed up a bit [possibly on my end :) ]. Thanks in advance, David --- 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] Re: MEM and CVS
Hi Alain, Alain said to me: PS as to Translation, if some day it kets Kittenized, surely I will help :) It is already kittenized in version 1.7 beta (maybe even before that, I don't know). Currently I'm in the process of kittenizing all the new code I added and I'm almost done. Once I'm done with that I would like to put the code into CVS so long as it's reasonably stable so folks can translate all the new messages I added. I'm afraid there are a lot :) Alain said to Johnson: Yes, I agree that work should target at same as DOS, but if the original DOS option sucks, we can consider an alternative, like add a switch to workaround, original DOS v6.22 or v7.10 is not perfect In this case, MEM didn't stay resident, so I think bigger file size is not a problem, if someone interest, he can code a FDISK /menu or FORMAT /menu with TurboVision like window I agree, but I am sure that you will find many to disagree. For some people here, size *is* an issue, apparently even for the non resident files. May I suggest something that I used for a PCI driver: you put all the functions that do the real work in separate files fropm the output files, this way you can compile 2 targets and so keep one of them small. That is definitely what I am planning to do because of the fact that MI has a bunch of options and it would be a mess to offer the user the ability to use all of those different options and also offer all the existing options without some confusing code. Besides, are the users not used to typing MI? :) So I will make an MI.EXE. Eventually I would like to make a Turbo Vision or similar UI version of MEM which I would call, say, MEM For TurboVision or MFT which is coincidentally the same name as QEMM's Manifest program :) It may coincidentally offer the same options if someone tells me what they are, and similar output if someone can describe/capture that for me. The question I haven't thought about much yet is translations: there would be some shared messages, so perhaps we'll have a shared NLS files and MI.EXE would use MEM.EN, etc. Could be confusing for users, but otherwise it may be annoying for me and anyone doing translations to have to copy strings out of the MEM files unless we make a rule that set numbers below X are common and can be copy/pasted directly between the two applications' NLS files. Copy/pasting parts of programs is almost always a mistake though :) Regards, David --- 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] MEM and CVS
Hi all, I would like to get my work on MEM finished in the next few weeks as after that I'm moving and things could be a mess for me after that :) I'm currently working on a few minor issues. As for the bigger issues of MEM not working on 8086 machines without /N[OSUMMARY] being used, adding PCTools-like output, and possibly other things I've forgotten, I'd rather leave these for later than possibly delay the next release of MEM for too long. I hope nobody objects to that. Specifically, with regards to the 8086 support, if we don't fix that, is that a regression? i.e. are we going backwards? If so I guess it's probably not acceptable to release without fixing this, otherwise if you all insist that I fix it I can't promise I'll be able to do that anytime soon! I would like to call the release 1.9 instead of 1.8 due to the fact that 'MEM /?' with the 1.8 alpha 1 version actually shows 1.8 and it would be nice to avoid confusion. I will make sure that the next alpha release shows 1.8a2 or 1.9a1 or something to avoid wasting more version numbers :) Any objections? What is the process for getting the code into CVS? Do you have a review process? Is there someone in particular I should send the code to, or do I just send the patch to the alias (or, preferably, make it available at a URL since it will probably be large)? Can the changes be committed to CVS before all the issues are fixed (i.e. before we're at release quality) so that translation can be done in parallel with me doing fixes and we have the benefits of version control? Thanks in advance, David --- 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 Visit http://www.jboss.com/services/certification for more information ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: Freedos-devel digest, Vol 1 #664 - 9 msgs
Hi Aitor, Eric, From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: freedos-devel@lists.sourceforge.net Date: Mon, 17 Oct 2005 00:20:26 -0700 (PDT) Subject: Re: [Freedos-devel] re: FreeDOS 1.0 Reply-To: freedos-devel@lists.sourceforge.net webmail Hi David, MEM: who was working on that? progress? This is described in the 1.0 TODO wiki, but I have not heard back about the recent progress for quite a while. There should be some MEM 1.8, but I do not know where you can get 1.7-and-a-half now. Sorry, right now I am not able to spend very much time working on MEM. The 1.8 alpha version is not release quality, especially since there are lots of non-kittenized strings. === Time ago I sent to Bart Oldeman a file with the Spanish translation of what was kittenized at that time, but I always had the impression that the file was lost somewhere, do you want me to look back for it, or do you have it already? At http://cvs.sourceforge.net/viewcvs.py/freedos/mem/nls/ you can see that he checked in a Spanish translation from you a year ago. If you happened to send him more than one and would like to check if the one he checked in is the correct one you can click on the 1.1 next to the file name to view the text of the file. I see that this translation wasn't in MEM 1.7 beta though. Eric, in response to your message (and to clarify what I said about translations), the issue right now is not that there is translation that needs to be done. The issue is that the code I wrote doesn't call kitten/catgets for lots of the new strings I added. It would also probably not be wise for anyone to do translations just yet as there will probably be some changes and I wouldn't want to have wasted anyone's time! By the way, and sorry if I asked this before (I don't remember), are there any good tools for editing the NLS files? If there was a GNU Emacs mode that did synchronous scrolling in a bunch of open windows that would probably work nicely. I guess that's probably something that'd be easy to write myself too! Also nice would be a tool where I could say for every string X:Y, if it's in the .EN file but not in some other file, add it to that other file in English with a comment above it that it needs translation. I guess that is easy to implement too. Regards, David --- 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] TCC2WAT available
Date: Sat, 15 Oct 2005 13:50:02 -0500 To: freedos-devel@lists.sourceforge.net From: Michael Devore [EMAIL PROTECTED] Subject: Re: [Freedos-devel] TCC2WAT available Reply-To: freedos-devel@lists.sourceforge.net [...] You can't be serious. Do you cringe when [...] I don't cringe, just snicker :) I wasn't in fact serious, hence the smileys, which I think are normally not used when folks are expressing moral outrage :) I don't really think the name of the library needs to be changed. Regards, David --- 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
[Freedos-devel] re: FreeDOS 1.0
Date: Mon, 17 Oct 2005 03:39:04 +0200 (MEST) From: Eric Auer [EMAIL PROTECTED] To: freedos-devel@lists.sourceforge.net Subject: [Freedos-devel] re: FreeDOS 1.0 Reply-To: freedos-devel@lists.sourceforge.net [...] MEM: who was working on that? progress? This is described in the 1.0 TODO wiki, but I have not heard back about the recent progress for quite a while. There should be some MEM 1.8, but I do not know where you can get 1.7-and-a-half now. Sorry, right now I am not able to spend very much time working on MEM. The 1.8 alpha version is not release quality, especially since there are lots of non-kittenized strings. Regards, David --- 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] TCC2WAT available
Hi Blair, Date: Fri, 14 Oct 2005 18:20:39 -0700 From: Blair Campbell [EMAIL PROTECTED] To: FreeDOS Devel Freedos-devel@lists.sourceforge.net Subject: [Freedos-devel] TCC2WAT available Reply-To: freedos-devel@lists.sourceforge.net Hi all. Today I am releasing TCC2WAT 0.1 beta, available at www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/tcc2wat/tcc2wat= .zip . TCC2WAT is a library that makes porting applications from Turbo C to OpenWatcom easy. Currently, most of the text-mode functions missing equivalents in OpenWatcom are implemented, and there are people that might work on poly(), polar(), and gettext(). I would appreciate people implementing any other missing functions. When/if they are implemented, please update http://wiki.fdos.org/Main/TCC2WAT . May I suggest that you make a rule that if someone wants to start working on an implementation of one of the unimplemented functions they edit the wiki page to put their name (or pseudonym or ...) down against it so there isn't any duplicated effort? Also, sorry, but I have to say that in my head I read 2WAT as a rude word :) Have you considered any other names? :) Thanks! David --- 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
[Freedos-devel] Re: Freedos-devel digest, Vol 1 #640 - 10 msgs
Hi Blair and Bernd, Date: Wed, 21 Sep 2005 22:23:46 -0700 From: Blair Campbell [EMAIL PROTECTED] To: freedos-devel@lists.sourceforge.net Subject: Re: [Freedos-devel] Compile-time language selection with kitten, etc. Reply-To: freedos-devel@lists.sourceforge.net I thought it would probably be very simple to write a tool which, given an NLS strings file (e.g. MEM.DE), output a .h file with So you're suggesting to have kitten, but also have the ability to make the default fallback language selectable according to a header? Well probably selectable via something in the Makefile, i.e. maybe we'd do something like: make nlsbin\de.exe nlsbin\es.exe or: make nlsbin\mem.de nlsbin\mem.es or: make nlsbin\de\mem.exe nlsbin\es\mem.exe where obviously you want to be careful that you don't confuse your nlsbin and nls directories in that second case given that the filenames in them are identical :) I guess it would be good for Bernd to suggest how he would manage all these executables which would end up with the same names in the distributions but would obviously need different paths/names at compile time and when he gets them from me/other developers. Maybe the third scheme above is the most clear. You could merge the nlsbin directories from a bunch of different tools together and then have nlsbin\de\ full of German-language .exe's, etc., which would then just be copied to your distribution fdos\bin directory. I don't think there are currently any tools to create headers from a .%lang% file. I would be happy with some other method for doing the translation too, this was just the idea I had. Another idea I had was to make a pre-processor that parsed the .c file and the NLS file and substituted the strings in, but I would prefer to avoid coding a C language parser because it wouldn't be too hard to make it work most of the time but I'm bound to miss some case or break when someone uses some compiler-specific stuff. Thanks! David --- 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] Compile-time language selection with kitten, etc.
Hi all, Bernd asked if it would be possible to compile MEM with different languages to make things simpler for non-English distributions. Are there any tools that can already do this for us? I thought it would probably be very simple to write a tool which, given an NLS strings file (e.g. MEM.DE), output a .h file with e.g.: extern char *muschi_0_0; extern char *muschi_0_1; .. and a .c file with e.g.: char *muschi_0_0 = Speicher voll, %ld bytes zu wenig.\n; char *muschi_0_1 = Speicherkette zerstrt! (konnte UMBs nicht einklinken)\n; .. and then instead of: #define _(set,message_number,message) kittengets(set,message_number,message) we would have: #define _(set,message_number,message) kittengets(set,message_number,muschi_ ## set ## _ ## message_number) where of course if we were translating a program that didn't already #define _ ... kittengets ... we could just redefine kittengets. When building a non-default language version, we'd define some flag (I guess MUSCHI) and if that flag was defined we'd #include the generated .h file and change the definition of _ and we'd also link in the .c file, otherwise we wouldn't #include the .h file and wouldn't link in the .c file. Of course I haven't implemented the tool just in case it's already been done :) By the way, MUSCHI stands for Manipulating User Strings at Compile-time to Help Internationalization, and it's also German for another word for cat which I won't include in this mail in case it triggers spam filters, and is also the name of my cat which died this year :( Regards, David --- 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] re: Chasing MS-DOS compatibility
Hi Bernd, Having all of my notes on a web page that everyone can see, and using a tool which is very quick to edit those nodes so that I am more likely to keep them up-to-date, will be of great benefit to everyone when I suddenly disappear from the community :) But the page doesn't show any download link, CVS snapshots or whatever. Fixed, I put a download link for the existing releases on there and mentioned that they are pretty much identical to what is in CVS. I also put an alpha version on there which is my code in its current state which I think is not too bad.. I would appreciate an interim non-public release of MEM to test things. My batchcode and experiments often have the habit of exposing bugs/issues in programs by accident. ..maybe you will prove me wrong though :) By the way, check README.TXT for the things not yet fixed. most programs can be run with '/?' and will show a string then. either look for a line with 'version' or with %name_of_program% We don't ship with anything like 'grep' though do we? @echo off date /d report.txt time /t report.txt [...] Looks good to me. Do we already have this? Thanks! David --- 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
[OT] Mail filtering (Was: [Freedos-devel] re: Chasing MS-DOS compatibility)
Hi Aitor, Hi, David O'Shea escribi=F3: I got Eric to forward on an email to him from me but I didn't get a=20 response, possibly due to Hotmail being extremely agressive with spam=20 filtering (if that is the case, my apologies go out to GNU_man!). SourceForge is also quite agressive with this, it will not allow to send messages sent from a SMTP mailer which differs from the FROM email address, can anyone suggest a (1) free, (2) multiple SMTP (one per account, so Mozilla/Thunderbird out), (3) JavaScript/*Script disableable (so Microsoft out) mail client for Microsoft Windows? Aitor Actually Microsoft is not out, at least not for that reason :) Outlook Express lets you turn off viewing messages as HTML and you can make it use the restricted sites zone and configure that zone in Internet Explorer as having very little permissions so even if you do view messages as HTML they should be safe, although they always have those vulnerabilities where there is some way of getting around the restrictions so I suggest leaving it set to not view messages as HTML. I guess there is always the chance of buffer overflows in MIME parsing but they have probably fixed all of those by now. At least, I trust Outlook Express under Windows XP these days. Maybe if you are running an older version of Windows which doesn't support the latest Outlook Express and hence you can't get all the security updates you shouldn't feel so safe :) Regards, David PS Sorry I am replying so late, I have been quite busy with work. You may have already solved your problem by now :) --- 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] Wikis (was re: Chasing MS-DOS compatibility)
Hi Aitor, all, Very nice, forgive me for my ignorance with wikis. I've seen that MEM is a Topic under Main, is there a way to see the tree of all the topics under Main? The obvious stuff didn't work. As Robert pointed out, there is the Index page. I just wanted to mention for those who are not familiar with wikis that they are not structured in any sort of tree - you typically create a new page by creating a link on an existing page, following that link, then creating/editing the new page. The only way you find pages is via links from other pages which include the front page (called HomePage on PmWiki) or via a link on the SideBar (which is also a page but is included on the side of every page). Anyone can add or modify any page on the Wiki so you can easily create a page with information about whatever you are working on/knowledgeable about. The Wiki stores revision history so if someone screws up a page you can restore the old one, and if someone cares to add comments to my Mem page I can see what they added. Where I work I am quite keen on the use of Wikis as most of the team knowledge is stored in old emails because folks send around tips on how to do things and everyone else will store that email somewhere and never be able to find it, whereas if we put it on a Wiki new members of the team also have access to the information and the Wiki has a search function. Okay, my sales pitch is over now :) Regards, David --- 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
Hi Blair, Why not supply OpenWatcom instead? It's freely distributable. OpenWatcom is already supplied, but DJGPP is much more useful for porting GNU utilities or linux programs to DOS (like DOSFSCK in the Base FreeDOS diskset, and many games using the allegro library). Please excuse my cluelessness here. I know DJGPP is great for porting Unix tools, but with regards to OpenWatcom, does it lack in the area of the C libraries or is it just the need for sh/bash, sed, and other things used in the make process? Not that it matters, I was just wondering! Can DJGPP compile FreeCOM and the FreeDOS kernel? Probably not, without some work, but it wouldn't be useful anyway because I don't know what the kernel would do if it was compiled as a 32-bit program and if FreeCOM were compiled with DJGPP it would prevent using 16-bit DPMI programs (like Jazz Jackrabbit and Raptor) because the DPMI extender required to run DJGPP-compiled exes (cwsdpmi), only supports 32-bit DPMI and doesn't know how to support 16-bit DPMI. If FreeCOM were loaded resident, CWSDPMI would also be loaded resident and would cause conflicts. Is OpenWatcom's DOS compiler 16-bit DPMI too? I had trouble running it under the DJGPP-compiled GNU Emacs 20.4/5. However I got a hold of HX DOS Extender and if I run HDPMI32 before starting Emacs (actually needed HDPMI32 -r since I am running under Bochs and there is some bug there that Japheth has kindly provided me with a fix for) then I can run OpenWatcom's DOS compilers under Emacs so I think this means that theoretically a DJGPP-compiled FreeCOM wouldn't have those problems. Of course I still don't know if there would be any point to it? If OpenWatcom's DOS compiler isn't 16-bit DPMI but 32, then I could try running a Borland one under Emacs as I'm pretty certain they are 16-bit DPMI. Regards, David --- 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, Bernd Blaauw wrote: David O'Shea schreef: I put a bunch of notes at http://wiki.fdos.org/Main/Mem I have done just about everything except /FREE (should be simple like /MODULE since it just means filtering the list) and your suggestion of /NOSUMMARY (should be easy too of course). I have also not done any work on an 8088 version. GNU_man said he was doing some work on this, I think, and I got Eric to forward on an email to him from me but I didn't get a response, possibly due to Hotmail being extremely agressive with spam filtering (if that is the case, my apologies go out to GNU_man!). hi David, glad to see you're extensively making use of the Wiki :) I've never worked with it, but will have to learn it sometime soon. Having all of my notes on a web page that everyone can see, and using a tool which is very quick to edit those nodes so that I am more likely to keep them up-to-date, will be of great benefit to everyone when I suddenly disappear from the community :) Your notes seem very complete. I'd suggest a 8086 version with 386 optimizations/possibilities, not a '80386+-exclusive version a 8086 version' like many other programs. That sounds like a good idea given that the tool's performance isn't critical - it's not like it's the kernel or even a program that spends very much time running like CHKDSK. I've never had to write a program that worked like this but I guess I will figure it out :) Another suggestion, but probably too difficult to implement, is to get the versions from loaded programs. This means 'drivername in memory -- find binary -- find version string' I guess finding the binary isn't too bad, but getting the version string would be quite hard? I think that lots of *nix-like applications that are in CVS often have a string in them like $Id: ..$, but even if all of the FreeDOS tools had that, it would not be possible to read it due to the use of UPX. I guess if we added UPX de-compression code to MEM it would cause a bit of bloat and then folks would be unhappy about that :) I guess that having the version information is useful when people are asking for support, though, as you could see what versions of some drivers/TSRs they had loaded. Unfortunately although MEM shows the versions of HIMEM and EMM386 which are both pretty important ones, we don't actually get the real version numbers :) Perhaps we could include in the distribution a batch file which gathers information useful for providing technical support, e.g.: VER /R MEM [probably specify lots of args here] HIMEM /? EMM386 /? Regards, David --- 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] Walking the MCB chain...
On Thu, 28 Jul 2005, Alain said: Welcome aboard :)) Thanks! I have made an MCB parser using the code from MEM. It shows the name of program tha hooked some INT vector. If you want, I can send you the fonts, it's GPL and it is much simpler then The MEM version because I have extracted just that part. I noticed this code in MEM.C but disabled. Does anyone know why it was disabled - were there problems with it, or was it just never implemented due to the fact it would require a new command-line switch and maybe it all got too hard? I wouldn't mind finishing that code off. If your code improves what is in MEM.C, I guess that would help me to finish it off, thanks! Regards, David --- 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
[Freedos-devel] Walking the MCB chain...
Hi Alex, I just figured out how to walk the MCB chain. Here's an NASM assembly program (not quite finished but does walk it from 'M' to 'Z', the end of the MCB chain). Thanks must go to the fabulous book 'Undocumented DOS' by Andrew Schulman, Tim Patterson, Ralf Brown et. al) which I bought 15 years ago. I happened to get that book from a previous employer a few years ago and decided to start reading it cover to cover a few months ago to reminisce about the good old DOS days and that was what made me decide that contributing to FreeDOS would be a bit of fun :) Anyway, back to what you are working on, I just wanted to mention that the source for the MEM command might be useful to you although it's written in C and not assembler and you have probably already figured out everything you need to do. It's in CVS - http://cvs.sourceforge.net/viewcvs.py/freedos/mem/source/mem/mem.c?rev=1.11view=auto The version in CVS doesn't try and find the master environment although I am working on that myself. I am also using the technique of looking for a PSP with parent PID == own PID. I suppose that with this technique it is safe to assume that the process with the higest PID is the most recently loaded one and hence is the one with the master environment you need to edit? By the way, do you have the disk from the book? Mine didn't come with the disk :( Is there any chance you could send the files if you happen to have the disk? Regards, David --- 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] FreeCom pre-release, please test and report any release bloc
Hi Jeremy,
add: DIR: bug#1889, added limited 4DOS DESCRIPT.ION file support
{KJD}
[...]
no biggy, it was a bug, it works with my made up files, but I can't
say for sure no issues with ones people really use. Still needs
improvements to avoid re-reading the file.
Is there a new bug filed to address avoiding re-reading of the file? As you
might recall I suggested a fix for that, and maybe I might address it
someday myself if you don't get to it. Maybe I could try figuring out a way
to measure performance.
Regards,
David
---
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] Re: FreeCom and 4DOS descript.ion files
Hi Jeremy, There should not be a noticable delay if you do not use them (one attempt to open per directory displayed), but may be for big directories as the file is sequentially searched for each filename displayed (as the file is unsorted and may or may not contain a description Im not sure how to avoid this). I'm not familiar with the exact constraints that apply to FreeCOM, but the following might be an optimization that performs better if there is enough RAM free and the same if you don't. What I'd suggest is you use a binary search tree (with the key being the filename of course); the trick being that you just use up all the RAM available to build the tree, and if you run out before you finish reading the descript.ion file, you remember the file position of the first entry you couldn't add to your tree so that when you are looking up a description for a physical file you found on disk, if you don't find it in the binary search, you can then do a linear scan of the remainder of the file. I think this would be a good design because it should perform well if you have enough memory/the descript.ion file isn't too big, but it will still work if there's not enough memory. Of course I don't know if code size might be a concern for you guys and adding the above would be a problem! Apologies if these kinds of constraints are documented somewhere - I haven't gotten around to reading all the documentation yet but once I have I'm hoping I can contribute with regards to coding. Any suggestions of some small things that need to be done that are maybe the kind of thing that the main developers don't have time for or feel is below them - the kind of work that at my work we'd give to an intern? :) Thanks in advance, David --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
