Re: [Freedos-user] command.com (Freecom) main environment location
On Mon, 8 Jul 2013 16:29:14 +0200 Tom Ehlert t...@drivesnapshot.de I may sound harsh, but being accused of ignorance by more ignorant is the only word of excuse I will utter. this 'more' makes me think that you should prove your competence first I agree. The above quoted phrase was a late minute, unfortunate addition to my mail, that was meant jokingly - but now on reading it again I can see it does not reflect my true purpose, which has been to put an end to respective sarcasm and ire. Sincerely ! That more was meant to be no less, as in, ok, we're all ignorants, let's live with the fact and do our best to learn from one another. Oh, well... I retire the phrase and beg your pardon. Then again : Let's forget /name calling/ ? If you agree, I'm your man Concerning the subject - locating the main env immediately above the small 3 K ? block of FreeCom's PSP, I honestly cannot discern whether you are seriously in want of explanations or only asking in jest. It is not complicated, at least from an ASM programmer's perspective where you can organise your modules at will. Or were you questioning the feasibility from the perspective of or a complex modular 'C' language program ? Then the detailed how is beyond my limited competence, I /suppose/ it might be harder, possibly requiring compiler-dependent variations and /some/ amount of 'glue' coded in ASM. Coding details are not to derail this mail list, you'll agree. We might dig down slightly deeper in private email, or on the developers' list if it's of interest to the community. not rocket science. But as they say, the devil is in the details .. it looks like a real experienced programmer (you) has to show us confused youngsters how it should be done! I'm deep impressed. we have a black belt grandmaster on visit. unfortunately too busy to work, but we are so happy to receive good advice ;) I can take sarcasm still :=) There are even other enhancements that could be made in the same domain, an easy one is to give back the /initial/ environment Retiring this as already done by FreeCOM (yeah!) I have no idea why MS-Command doesn't , 4DOS neither. In particular, when one of those other Command's is the primary shell in MS-DOS 6+, the intial env block inherited from config.sys, is retained which causes incompatibilities with some older DOS programs. Bye ! -- Czerno -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
I may sound harsh, but being accused of ignorance by more ignorant is the only word of excuse I will utter. this 'more' makes me think that you should prove your competence first I agree. The above quoted phrase was a late minute, unfortunate addition to my mail, that was meant jokingly - but now on reading it again I can see it does not reflect my true purpose, which has been to put an end to respective sarcasm and ire. Sincerely ! That more was meant to be no less, as in, ok, we're all ignorants, let's live with the fact and do our best to learn from one another. Oh, well... I retire the phrase and beg your pardon. Then again : Let's forget /name calling/ ? If you agree, I'm your man apologies accepted. Concerning the subject - locating the main env immediately above the small 3 K ? block of FreeCom's PSP, I honestly cannot discern whether you are seriously in want of explanations or only asking in jest. It is not complicated, at least from an ASM programmer's perspective where you can organise your modules at will. Or were you questioning the feasibility from the perspective of or a complex modular 'C' language program ? Then the detailed how is beyond my limited competence, I /suppose/ it might be harder, possibly requiring compiler-dependent variations and /some/ amount of 'glue' coded in ASM. the bizarre design decision by a confused programmer was made because a single 'load as high as possible' takes care of all the trouble. (there's enough necessary trouble left to swap command in/out of XMS...) I call this 'intelligent design', and so far there were no adverse effects reported. sure your particular problem could be solved by freecom, but nobody will spend time on this. it can be solved as well or better by a small external utility; just have the first line in autoexec.bat be ENVLOW.EXE. and moving program code around is probbaly easier in ASM then in C even better: you can do it yourself without learning C ;) not rocket science. memory juggling in freecom was advanced engineering; in kernel.sys it *was* rocket science. Tom -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Tom Ehlert wrote : sure your particular problem could be solved by freecom, but nobody will spend time on this. Still, Rugxulo, I think, has suggested one could ping Bart Oldemann with the question. Now, after you have pointed out very plausibly that FreeCOM does not hold hidden pointers to the master ENV, I must admit I do not see the point originally made as crucial any more. it can be solved as well or better by a small external utility; just have the first line in autoexec.bat be ENVLOW.EXE. Is that found in the FreeDOS distro ? Don't bother, I'll g00gle it... This list's Macej brewed his own tiny, simple mover and sent a copy for me to play with (thanks Macej).. It's amusing, but needs to be run several times in a row to get a chance to relocate the ENV properly :=) and moving program code around is probably easier in ASM then in C Undoubtably even better: you can do it yourself without learning C ;) Great relief, that! C was not around when I educated myself to programming in the 50s - early 60s,.by the way. I intend to do mine indeed - unless the envlow you mentionned is doing the job. Macej's is good as a proof of concept but does not quite do what I want done, which is leave no hole after it. DOS memory ought not to look like Swiss cheese (gruyere) Hmm, question may be considered closed for the moment being. Cheers -- Czerno -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi, Eric Auer ! PS: XBDA and moving it is not necessarily trivial. Our EBDA mover is working flawlessly AFAICT.Old code of mine actually, written for MSDOS 5+ before MS introduced the switches=/E option (or before I was aware of the switch?). Last week when I had discovered that the respective FreeDOS kernel's switches doesn't work (see below), we merged in new code to deal with it. My and the project's intention as a way to somehow repay in part what FreeDOS is giving us was to offer this generic MSDOS+FreeDOS EBDA mover for inclusion at the FD repositories as soon as all the project's people has had a chance to field tested the release candidate on as many DOS machines and configurations as they can. I must say, though, the reception which I got from Herr Ehlert on this list is making me wonder whether spontaneous contributions made in good faith are welcome and / or opportune. maybe Tom does not have the patience to explain you why there are good reasons why FreeDOS does things the way they are done, but you can trust him :-) As in, I should /trust/ someone blindly who /starts/ interacting by affirming that I /do not understand/ the point ? Which is funny because, as much as I claim I /do not/ grasp the C language, I will claim having a /good/ understanding of DOS's memory management, the API and the 'innards' as well, and even the implementation quirks (Microsoft's). So I /might/ take offence of what you call, mildly, Tom's lack of patience. Further to stating that I Czerno do not understand, and that he Tom does not care about your users, I have yet to read Herr Ehlert's statement of why it would be (dangerous? unwelcome?) for Freecom to allocate the master environment block in low memory using first fit. I'm open and ready to accept sound reasons, which must be FreeCOM specific then, just not the you wouldn't be happy stance ! Am I bizarre ? XMS swapping is done by FreeCOM, not the kernel... Indeed, my typo. SWITCHES = /E directive in Config.sys is ignored silently CfgSwitches says: ... /* allowed values: [48..1024] bytes, multiples of 16 ... You also want to read some of the related code. You are right that there is no feedback telling you step by step what happens with the EBDA, but making the kernel that verbose would also make it unnecessarily large. Well, I won't enter into that code in detail - I don't do *C*, remember ! but the FreeDOS kernel mover /does not work/ on *real* machines, ours /does/ work ;=) At first sight, FreeDOS makes assumptions which are much too restrictive (in present days, XBDAs are over 1 k byte in length, 6 kilobytes aren't rare.) Is there a FreeCOM 'blueprint' or design document for FreeCOM other than the code comments ? There are some text files, wiki / homepage documents... But generally speaking: If it is not part of the source download, it is probably not included. This is a problem with many projects of course. Well... the project which I keep mentionning won't include a COMMAND processor in the final distribution as self sufficient bootable images for a floppy or USB key. The final user may want to add one and we certainly want a command shell during project building. I'll be recommending 4DOS for internal use - license allowing. In case a future version of FreeCOM finally can be persuaded to locate the ENV low, like MS and all other Command.com flavours rightly do, shall we reconsider. Kind regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Bertho ???, You may call me Czerno, Herr Ehlert You can't escape having to explain what adverse effects you were evoking, now anyway. command.com is a 'normal' program. just allocating DOS memory will give you an environment at ~1800:0. not such a good idea. You are joking, Herr Ehlert, richtig ? Launching a basic FreeDOS+FreeCOM virtual machine while I'm typing... No upper memory. Using (Jack Ellis's, I think ) XMGR.SYS. MEM /D indicates the ENV would be at *526:0*, /not/ such a /bad idea/. And this is /with/ VMware's BIOS 5 kilobytes EBDA relocated low, mind you. Of course the kernel is in HMA, which may be what your reply eluded ! And EVEN if for some reason HMA was not available or not given to the DOS kernel, what makes you deem an environment at ~1800:0 not such a good idea ? I this all your deep reason for forcing the master ENV up at 9 ? In which way other than your respectable personal preference is it better? This is highly ridiculous. At least provide a choice. Leave it to power /users/ to determine for themselves what memory layout is best in /their/ situation. Ah, but - sorry, I was forgetting - you /don't care/ much about your users. No wonder you don't have many. usually ~9f00:0 is a much better place. and juggling memory around (beyond what is already done) was so far never necessary (and still isn't) How do you say arrogance in German, Herr /Doktor/ Ehlert ? Wiedersehen -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Bertho ???, You may call me Czerno, Herr Ehlert your email signature reads Bertho Grandpied y31415926...@yahoo.fr that translates to Bob Bigfoot, right ? You can't escape having to explain what adverse effects you were evoking, now anyway. command.com is a 'normal' program. just allocating DOS memory will give you an environment at ~1800:0. not such a good idea. You are joking, Herr Ehlert, richtig ? Launching a basic FreeDOS+FreeCOM virtual machine while I'm typing... No upper memory. Using (Jack Ellis's, I think ) XMGR.SYS. MEM /D indicates the ENV would be at *526:0*, /not/ such a /bad idea/. And this is /with/ VMware's BIOS 5 kilobytes EBDA relocated low, mind you. I recommend to apply your 'allocate low' change to FreeCOM yourself. you will see what happens. Of course the kernel is in HMA, which may be what your reply eluded ! no. And EVEN if for some reason HMA was not available or not given to the DOS kernel, what makes you deem an environment at ~1800:0 not such a good idea ? you would end up with 3 K COMMAND.COM, (resident part) 100 K FREE (remainders of freecom before resizing) 1 K command.com environment (at ~1800:0) I this all your deep reason for forcing the master ENV up at 9 ? In which way other than your respectable personal preference is it better? This is highly ridiculous. At least provide a choice. Leave it to power /users/ to determine for themselves what memory layout is best in /their/ situation. Ah, but - sorry, I was forgetting - you /don't care/ much about your users. your are making things up - again. you asked How many users do you have ? I answered I have no idea - and don't care. How do you say arrogance in German, Herr /Doktor/ Ehlert ? Arroganz. Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi, On Mon, Jul 8, 2013 at 5:30 AM, Bertho Grandpied y31415926...@yahoo.fr wrote: I must say, though, the reception which I got from Herr Ehlert on this list is making me wonder whether spontaneous contributions made in good faith are welcome and / or opportune. Patience, young padawan. Things like this take time and thought (and research and testing). If you draw up a patch and it isn't accepted upstream into SVN, I can still mirror it somewhere (e.g. iBiblio) for you. Or you can do almost anything with it anyways, it's free/libre. There can be no one stopping you from contributing (somewhere, somehow). maybe Tom does not have the patience to explain you why there are good reasons why FreeDOS does things the way they are done, but you can trust him :-) As in, I should /trust/ someone blindly who /starts/ interacting by affirming that I /do not understand/ the point ? Give him the benefit of the doubt, as he is one of the resident experts around here who has contributed a lot. But even the smartest person in the world gets tired, too busy with real life, or just forgets some minor details from years ago. Further to stating that I Czerno do not understand, and that he Tom does not care about your users, I have yet to read Herr Ehlert's statement of why it would be (dangerous? unwelcome?) for Freecom to allocate the master environment block in low memory using first fit. I'm open and ready to accept sound reasons, which must be FreeCOM specific then, just not the you wouldn't be happy stance ! Am I bizarre ? Yes, of course, technical explanations (or how to test for correctness) would be ideal, but he may not have time for that nor remember the details. Well... the project which I keep mentionning won't include a COMMAND processor in the final distribution as self sufficient bootable images for a floppy or USB key. The final user may want to add one and we certainly want a command shell during project building. I'll be recommending 4DOS for internal use - license allowing. 4DOS is ambiguously licensed. I don't really recommend it, though there aren't a lot of full shell replacements available. If you can avoid some (most?) .BAT internal stuff, you may find it easier to replace: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/contrib/ In case a future version of FreeCOM finally can be persuaded to locate the ENV low, like MS and all other Command.com flavours rightly do, shall we reconsider. Again, I take this to mean that (admittedly) FreeCOM is too hard to rebuild (preferably with TurboC). If you need help with this, feel free to try and ask specifically for assistance. (It's definitely what I would call slightly annoying, but it's definitely not impossible to rebuild either.) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
You may call me Czerno, Herr Ehlert your email signature reads Bertho Grandpied y31415926536@... that translates to Bob Bigfoot, right ? Ask Yahoo!... Then if you insist on calling me Bertho, be my guest. And EVEN if for some reason HMA was not available or not given to the DOS kernel, what makes you deem an environment at ~1800:0 not such a good idea ? you would end up with 3 K COMMAND.COM, (resident part) 100 K FREE (remainders of freecom before resizing) 1 K command.com environment (at ~1800:0) How lame ! Of course, your Freecom shall have to play a minimum game of releasing its own initialisation code and data, resizing and possibly moving things along. Basic DOS system coding skills, not rocket science. This is/the/ official shell we are talking of, not some half baked throwable transient proggy, it deserves having a minimum of /intelligent design/ applied :=) There are even other enhancements that could be made in the same domain, an easy one is to give back the /initial/ environment (if any) received by your Command from its caller (or from Sysinit). It is of no use after the Master ENV is built. Freeing it would give FreeDOS an edge over MS Command. But the important is the above. You (or was it Eric) repeated that FreeCOM had to follow MS-Command, but in this respect it doesn't even start to try, I am /sorry/ to observe. What is the legal status of 4DOS in relation to FreeDOS ? There's a fully baked product, could it become /the/ main FD shell ? How do you say arrogance in German, Herr /Doktor/ Ehlert ? Arroganz. Itself ! I may sound harsh, but being accused of ignorance by more ignorant is the only word of excuse I will utter. Let's forget /name calling/ ? If you agree, I'm your man -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi, On Mon, Jul 8, 2013 at 8:57 AM, Bertho Grandpied y31415926...@yahoo.fr wrote: What is the legal status of 4DOS in relation to FreeDOS ? There's a fully baked product, could it become /the/ main FD shell ? Unlikely to become the main shell (though that's not my decision anyways). I'm honestly not sure how free/libre it is. IIRC, the original license (when sources were released) was quite contradictory, so I'm not sure if commercial use is allowed, which is indeed a big restriction that OSI and FSF rally against. (Not to mention requiring non-free tools. I don't think the partial patch to use OpenWatcom was ever very successful, but I never tried, and certainly Lucho only used old official MS tools.) I don't know the details, I'm no lawyer. It's unlikely to ever change. Feel free to contact the copyright holder (Rex Conn? JPsoft?) for clarification, but then again, they may not respond (in any useful manner), so don't get your hopes up. http://jpsoft.com/company/contact-jp-software.html Sorry to be so pessimistic. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
you would end up with 3 K COMMAND.COM, (resident part) 100 K FREE (remainders of freecom before resizing) 1 K command.com environment (at ~1800:0) How lame ! Of course, your Freecom shall have to play a minimum game of releasing its own initialisation code and data, resizing and possibly moving things along. Basic DOS system coding skills, not rocket science. This is/the/ official shell we are talking of, not some half baked throwable transient proggy, it deserves having a minimum of /intelligent design/ applied :=) it looks like a real experienced programmer (you) has to show us confused youngsters how it should be done! There are even other enhancements that could be made in the same domain, an easy one is to give back the /initial/ environment (if any) received by your Command from its caller (or from Sysinit). It is of no use after the Master ENV is built. Freeing it would give FreeDOS an edge over MS Command. But the important is the above. I'm deep impressed. we have a black belt grandmaster on visit. unfortunately too busy to work, but we are so happy to receive good advice ;) You (or was it Eric) repeated that FreeCOM had to follow MS-Command, it was dennis but in this respect it doesn't even start to try, I am /sorry/ to observe. How do you say arrogance in German, Herr /Doktor/ Ehlert ? Arroganz. Itself ! I may sound harsh, but being accused of ignorance by more ignorant is the only word of excuse I will utter. this 'more' makes me think that you should prove your competence first Let's forget /name calling/ ? If you agree, I'm your man Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Att: Rugxulo Hi, Patience, young padawan. I had to look that padawan up on wOOkipedia (not a typo!) :=) http://starwars.wikia.com/wiki/Padawan Things like this take time and thought (and research and testing). Accepted. I've passed the message, now letting things ripen (and tone down) as appropriate. If you draw up a patch and it isn't accepted upstream into SVN, I can still mirror it somewhere (e.g. iBiblio) for you. I'm afraid no patch to FreeCOM is likely will be coming from me, for reasons already stated and rehashed. Should OTOH you (and the FreeDOS project at large) wish to offer the free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll contact you for arranging the mirroring. It's a simple, robust and tiny DOS device driver coded in ASM, a few hundred bytes altogether. maybe Tom does not have the patience to explain you why there are good reasons why FreeDOS does things the way they are done, but you can trust him :-) (...) Give him the benefit of the doubt, as he is one of the resident experts around here who has contributed a lot. I think I did give the, whatever, benefit - but maybe it was not apparent ? But even the smartest person in the world gets tired, too busy with real life, or just forgets some minor details from years ago. Sure. but the smartest person in the world won't convince me s/he cannot discard 100 K of temporary code/data and do some memory resizing, move part of itself out of the way if need be - before allocating memory. It's not exactly a beginning programmer's task, nor is it rocket science either. [...] want a command shell during project building. I'll be recommending 4DOS for internal use - license allowing. 4DOS is ambiguously licensed. I don't really recommend it, though there aren't a lot of full shell replacements available. If you can avoid some (most?) .BAT internal stuff, you may find it easier to replace: I /love/ 4DOS - been using it for 20 years - used to be NDOS. For internal use, it must be OK, right ? The question wrt to licensing was rather whether 4DOS.COM could be legally envisaged to become FreeCOM as FreeDOS official, or alternate official? shell. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/contrib/ Again, I take this to mean that (admittedly) FreeCOM is too hard to rebuild (preferably with TurboC). If you need help with this, feel free to try and ask specifically for assistance. Having never written a line in C makes it a no-no for myself, and no programmer on their small team will take an interest in what is outside the realm of the project. (It's definitely what I would call slightly annoying, but it's definitely not impossible to rebuild either.) Rebuilding is one thing, patching and debugging properly is another. This task takes a motivated, seasoned C programmer, who preferably were familiar already with FreeCOM. All I can do is try to argue it, knowing well it's a possibility that no one will be convinced and undertake it. On the other hand, if FreeCOM hasn't been revised since 2001, maybe it's not to early for 'someone' to give the old code a look and some fresh thought. Regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi, Should OTOH you (and the FreeDOS project at large) wish to offer the free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll contact you for arranging the mirroring. It's a simple, robust and tiny DOS device driver coded in ASM, a few hundred bytes altogether. it probably should be merged into the kernel, or actually used as a blue print to fix the bug (?) in the current kernel that prevents the XBDA move. On the other hand, if FreeCOM hasn't been revised since 2001, nobody said that. Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi, On Mon, Jul 8, 2013 at 10:06 AM, Bertho Grandpied y31415926...@yahoo.fr wrote: Should OTOH you (and the FreeDOS project at large) wish to offer the free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll contact you for arranging the mirroring. It's a simple, robust and tiny DOS device driver coded in ASM, a few hundred bytes altogether. A nice readme.txt telling how to use it would be most helpful. :-) But yes, of course, anything free/libre (four freedoms) can be mirrored. 4DOS is ambiguously licensed. I don't really recommend it I /love/ 4DOS - been using it for 20 years - used to be NDOS. For internal use, it must be OK, right ? I don't know, I'm no lawyer. I don't even want to think about it. It's out of my hands anyways. (And now I remember that Bernd put it in FD 1.1 anyways, maybe as default!) The question wrt to licensing was rather whether 4DOS.COM could be legally envisaged to become FreeCOM as FreeDOS official, or alternate official? shell. It's not as easy as it sounds to be compatible between shells with .BAT scripts. Personally, I stick to plain .BAT (usually FreeCOM) and third-party tools (or external scripting languages) rather than rely on 4DOS. Though there's nothing technically horrible about 4DOS, but it's not really worth using exclusively, IMO. (Though, again, it's not my decision what FreeDOS proper does.) I do have it as an optional shell in my CONFIG.SYS menu, but I rarely use it. Rebuilding is one thing, patching and debugging properly is another. This task takes a motivated, seasoned C programmer, who preferably were familiar already with FreeCOM. All I can do is try to argue it, knowing well it's a possibility that no one will be convinced and undertake it. Bart Oldeman is the dude to contact. He was the last one officially working on it (circa late 2011). You may have to email him directly, but again, he may be too busy these days (educated guess). http://sourceforge.net/p/freedos/svn/1709/tree/ freecom 2011-07-29 bartoldeman [r1696] Merged fcompl1 and fcompl2.c to filecomp.c On the other hand, if FreeCOM hasn't been revised since 2001, maybe it's not to early for 'someone' to give the old code a look and some fresh thought. Not sure where you got 2001 from. It's hard to tell from (very) quick glance, but it seems 2003 (0.82) and 2006 (0.84). I know, not much better, but still ...! :-) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi Bertho, I've spent the last three hours writing a tiny COM program that moves COMMAND.COM's environment block to the lowest address possible (using DOS's low memory first fit strategy). Unfortunately, it does not seem to be able to find the environment block if used in AUTOEXEC.BAT after HIMEMX and JEMM386 were loaded in FDCONFIG.SYS (I only tested both at the same time, so I don't know which one causes the problem), but it works if run after AUTOEXEC.BAT has been processed (for some reason - but by then you may have TSRs loaded between COMMAND.COM and its environment, which may or may not be OK for your needs) or if those two drivers are not loaded. So for example, without HIMEMX and JEMM386, FreeCOM will allocate its environment block at e. g. segment 9F7F, but after running the program, the environment block will reside at segment 23B4, almost immediately after COMMAND.COM (it depends on the order in which you load TSRs). Please contact me off-list if you want to try it out. Matej Horvat http://matejhorvat.si/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
I'm surprised you have to question this! after ~12 years without anybody complaining, I'm surprised about you complaining. How many users do you have ? I have no idea - and don't care. Of these, how many understands this level of detail, /and/ in addition, will care ? answering this question would imply that /you/ understand the problem. you don't. Methinks you were p.ssed off by my remarks, but there is nothing personal to them. Who is , or are, the 'appointed maintainer(s)' for FreeCOM ? Are you one of them ? 'appointment' would imply structure, leadership, organisation, ... none of this is currently happening. I just wrote the code to put the environment where it is (in 2001), that's all. and it's placed where it is for a *very* good reason. just think a bit about it the FreeDOS kernel relocates the XBDA. Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by default. this is either a bug, or your XBDA behaves somewhat different. an unrelated story. *then* config.sys processing happens; possibly some driver maps a000- b7ff as conventional memory *then* comes command.com, and maps it's environment as high as possible. if b7ff is available, it will load it's environment there. if ef00 is available, it's loaded there. Why these latter limits would be thus hard-coded is beyond me. b7ff is shorter then 'the highest location in conventional memory' it was easier to do it the way it is, and so far nobody complained. HA ! Sincerity itself, at last! Now this I /can/ understand, and even sympathise with :=) Not in line with what Dennis wrote, though... there are always people with more time and energy to write then knowledge to write about :( that's a pretty good design decision. Only for so long as no one disputes it :=)... FreeCOM can't claim MS-Command.com compatibility until time it has an option, and I would suggest, the /default/, to allocate the master env block from the bottom, instead of the top of conventional mem. Besides, I hardly see how it was easier, your word, for FreeCOM to do it in the current way. I'd rather suspect whoever made the decision, *I* back when, was confused, *no* similar to how DM Cunney remained somehow apparently confused to this day. ;) Casually peeking at Freecom source, branch MAIN, init.c v 1.31, Freecom's rev 1.31 (Excerpt, from Sourceforge CVS, w/ line numbers) [code] 437 env_resizeCtrl |= ENV_USEUMB | ENV_ALLOWMOVE | ENV_LASTFIT; 438 if(forceLow) 439 env_resizeCtrl = ~ENV_USEUMB; 440 if(newEnvSize 16 newEnvSize 32767) 441 env_setsize(0, newEnvSize); [/code] et caetera, etc... I'm not an expert in C, not even close to a novice... good find. With this duly noted, it appears it won't be hard for you Freecom code contributors / revewers (is this not you, Tom E.?) to edit the above module and possibly a handful of dependencies so that FreeCOM eventually will request the environment block using Firstfit instead of Lastfit strategy, at least when allocating from low memory. I don't care as much if it uses lastfit when the request is effectively UMBs only, although I'm not sure what is to be gained by using 'lastfit' even in upper memory. Hoping someone will take the challenge, left as an exercise to the reader. suffice it to say: you wouldn't like the adverse effects. Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Tom, How many users do you have ? I have no idea - and don't care. Of these, how many understands this level of detail, /and/ in addition, will care ? answering this question would imply that /you/ understand the problem. you don't. Now, is that not arrogance ! This kind of remarks is best avoided, it is not a way to prove your competence which has not been disputed anyway. I just wrote the code to put the environment where it is (in 2001), that's all. and it's placed where it is for a *very* good reason. just think a bit about it If there is such a reason, you should be able to state it, for the benefit of us all who are not geniuses like you. Please *enlighten* me ! the FreeDOS kernel relocates the XBDA. Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by default. this is either a bug, or your XBDA behaves somewhat different. An XBDA is an XBDA is an XBDA, furthermore this is observed on more than one machine. Im using a kernel v. 2040 with XMS swapping compiled in. An SWITCHES = /E directive in Config.sys is ignored silently - no error flagged. My conclusion has been that the option was reserved but unimplemented. Is kernel 2041 different in this respect ? an unrelated story. Agreed. Why these latter limits would be thus hard-coded is beyond me. b7ff is shorter then 'the highest location in conventional memory' Really ? 80x86 systems /other/ than the standard Wintel PC (a moving goal anyway) should be able to run a DOS efficiently. Think out of the matrix! let's not be formatted by years of IBM/Microsoft/Intel/PCI-SIG...whoever's... idea of what a PC/DOS machine must be like. Rant and digression over. ... Snipping repetitive stuff... Casually peeking at Freecom source, branch MAIN, init.c v 1.31, ... I'm not sure what is to be gained by using 'lastfit' even in upper memory. ... Hoping someone will take the challenge, left as an exercise to the reader. suffice it to say: you wouldn't like the adverse effects. Is there a FreeCOM 'blueprint' or design document for FreeCOM other than the code comments ? You can't escape having to explain what adverse effects you were evoking, now anyway. Bye ! -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi Bertho,
maybe Tom does not have the patience to explain you
why there are good reasons why FreeDOS does things
the way they are done, but you can trust him :-) If
you take the time to FULLY understand the issue and
then have exact ideas on how to do things yet better,
you are most welcome to submit patches or explain an
algorithm change and why that new algorithm is good.
Cheers, Eric
PS: XBDA and moving it is not necessarily trivial.
Im using a kernel v. 2040 with XMS swapping compiled in.
XMS swapping is done by FreeCOM, not the kernel...
SWITCHES = /E directive in Config.sys is ignored silently
CfgSwitches says:
case 'E': /* /E[[:]] Set the desired EBDA amount to move in bytes
*/
{ /* Note that if there is no EBDA, this will have no effect */
int n = 0;
if (*++pLine == ':')
pLine++;/* skip optional separator */
if (!isnum(*pLine))
{
pLine--;
break;
}
pLine = GetNumArg(pLine, n) - 1;
/* allowed values: [48..1024] bytes, multiples of 16
* e.g. AwardBIOS: 48, AMIBIOS: 1024
* (Phoenix, MRBIOS, Unicore = )
*/
if (n == -1)
{
Config.ebda2move = 0x;
break;
}
else if (n = 48 n = 1024)
{
Config.ebda2move = (n + 15) 0xfff0;
break;
}
/* else fall through (failure) */
}
Also, PreConfig2 says:
if (Config.ebda2move)
{
ebda_size = ebdasize();
ram_top += ebda_size / 1024;
if (ebda_size Config.ebda2move)
ebda_size = Config.ebda2move;
}
...
if (ebda_size) /* move the Extended BIOS Data Area from top of RAM here */
movebda(ebda_size, FP_SEG(KernelAlloc(ebda_size, 'I', 0)));
You also want to read some of the related code. You are
right that there is no feedback telling you step by step
what happens with the EBDA, but making the kernel that
verbose would also make it unnecessarily large.
Why these latter limits would be thus hard-coded is beyond me.
b7ff is shorter then 'the highest location in conventional memory'
Really ? 80x86 systems /other/ than the standard Wintel PC (a moving goal
Well... Anyway. The DOS running on not so standard PC,
say TI PRO or TANDY, also was not vanilla but had to
hardcode the non-standard aspects of those platforms.
Is there a FreeCOM 'blueprint' or design document for FreeCOM
other than the code comments ?
There are some text files, wiki / homepage documents...
But generally speaking: If it is not part of the source
download, it is probably not included.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Bertho ???, Casually peeking at Freecom source, branch MAIN, init.c v 1.31, ... I'm not sure what is to be gained by using 'lastfit' even in upper memory. ... Hoping someone will take the challenge, left as an exercise to the reader. suffice it to say: you wouldn't like the adverse effects. Is there a FreeCOM 'blueprint' or design document for FreeCOM other than the code comments ? nothing except 'look at how MS command behaves' You can't escape having to explain what adverse effects you were evoking, now anyway. command.com is a 'normal' program. just allocating DOS memory will give you an environment at ~1800:0. not such a good idea. usually ~9f00:0 is a much better place. and juggling memory around (beyond what is already done) was so far never necessary (and still isn't) Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
In composing this reply from the terrible Yahoo! web mail, I'll be trying to /force/ hard end-of-lines, not flowed lines, at long last! fingers crossed. On Thu, 4 Jul 2013 dmccunney dennis.mccun...@gmail.com wrote: Placing the environment at the top of conventional memory is what MS-DOS COMMAND.COM did, and FreeDOS tries to be DOS compatible. With all due respect, you must be mistaken :-( I've used almost all versions of Microsoft from 3.2 to 8 (and assorted DRDOS versions also). They - or rather their 'command.com' always have asked for the /lowest available/ DOS memory block for their master environment, which is to say practically always the env has been immediately above the program itself. I've /never/ seen a compatible command.com, including 4DOS, use that alternate allocation strategy which you claim, incorrectly, was DOS's default ! Maybe, just maybe, your confusion arises from the Microsoft Command interpreter's internal use of the top of the TPA for its data (but /without/ any MCB reservation! When control is returned from a transient, they *check* for possible memory corruption in the unprotected are by way of a control sum). This is nothing to do with the environment anyway. I never had a problem because of it. One thing I used to run on my old PC XT clone under MS-DOS 3.3 and 5.0 was a freeware utility form Chris (CED) Dunford. It could map unused video memory in the segment above 640K to DOS conventional memory. Yep this is the kind of things you could do, although VGA memory was exceedingly /slow/ for executing programs from, nowadays we would map the memory in better ways - using EMM 4.0 for instance, or (with some chipsets) remapped physical memory even in CPU /real mode/. You never had a problem... precisely because you were using MS-DOS 3.3 and 5.0 at the time, giving you an uninterrupted 640+96=736 k bytes of '(un)conventional' memory ! With FreeCom's environment (and/or an XBDA) in the way, you'd have been much less happy. Although you'd still got that extra memory, it would've been fragmented hence much less appealing. COMMAND.COM putting the master environment at the top of conventional memory It didn't ! While it might be nice to relocate the master environment block elsewhere, like upper memory, it's hardly necessary. This is not what I'm requesting. I'm strongly suggesting that FreeDOS should locate the master environment it creates in a way compatible to MSDOS and thanks to your kind reply I do understand the reason it is not compatible, currently, is rather a misunderstanding than any legitimate design decision. Apologies if this sounds rude, it's not meant to be ! Kind regards -- Ninho -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
I've seemed to notice Command.com locates its master environment block at the top of conventional memory Is this behaviour user-controllable with some switch while loading FreeCOM ? what would be the purpose to change this ? whee would you like to have it ? Or otherwise, depending on the global FDConfig ? I could not find a way to change this - which is not a good design decision why is this not a good design decision ? I'm surprised you have to question this! after ~12 years without anybody complaining, I'm surprised about you complaining. Tis bad because the block in question exceedingly ill-placed, a user who is able, one way or another, to have usable RAM mapped above the 640 k so-called limit into the video memory' segments, up to 736 k (B7FFF), will be forced to use the added memory as UMBs instead of an extension of *contiguous* so-called conventional mem. Of course the default placement of an XBDA (in case there is one, that is, almost always nowadays) deserves the same blame but either the kernel or some utility will routinely relocate it down during Config.sys processing. the FreeDOS kernel relocates the XBDA. *then* config.sys processing happens; possibly some driver maps a000-b7ff as conventional memory *then* comes command.com, and maps it's environment as high as possible. if b7ff is available, it will load it's environment there. if ef00 is available, it's loaded there. it looks like you have a particular strange setup thaqt you are disturbed by command's environment. maybe you are mapping memory in/out dynamically ? The why has been explained. In addition, under /some but not all/ BIOSes, it seems the presence of a DOS MCB-covered zone under the 'video' area may perturb conventional memory reporting by the API of int 15/E820. Not confirmed. don't make things up Want more ? OK, additionally, some (admittedly very rude, maybe very old) DOS programs will neglect to check where the memory 'above' them ends, and use any and all BIOS int 12 mem without reservation. sure. execute such programs, and you deserve no better. CtrlAltDelete will clean up ;) for that reason the end of the 'transient program area' should as far as possible coincide with the end of conventional (int 12) memory. To where : by default, or absent DOS-managed UMBs, put it on top of the main FreeDCOM code (this is how MS does it). it was easier to do it the way it is, and so far nobody complained. that's a pretty good design decision. Optionally relocate to an available UMB. already done (in 2001). Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi Tom ! I'm surprised you have to question this! after ~12 years without anybody complaining, I'm surprised about you complaining. How many users do you have ? Of these, how many understands this level of detail, /and/ in addition, will care ? Methinks you were p.ssed off by my remarks, but there is nothing personal to them. Who is , or are, the 'appointed maintainer(s)' for FreeCOM ? Are you one of them ? Tis bad because the block in question exceedingly ill-placed (...) Of course the default placement of an XBDA (...) deserves the same blame but either the kernel or some utility will routinely relocate it down during Config.sys processing. the FreeDOS kernel relocates the XBDA. Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by default. Pray tell how, if there is a way, you tell the kernel to do the down move; despite what some doc says on the FreeDOS site, the switches=/E command does not work (but it does in MS-DOS). Not that I need it, we've written our own EBDA mover. *then* config.sys processing happens; possibly some driver maps a000- b7ff as conventional memory *then* comes command.com, and maps it's environment as high as possible. if b7ff is available, it will load it's environment there. if ef00 is available, it's loaded there. Why these latter limits would be thus hard-coded is beyond me. But never mind for the moment In these posts I am NOT meaning to consider UMBs. I should not have mentioned upper memory even tangentialy. Let's limit ourselves to a DOS on an AT-compatible system which is not capable of supporting UMBs - or that we do not want to configure for UMBs anyway. That is, basic DOS system with 640 k conventional memory. it looks like you have a particular strange setup that you are disturbed by command's environment. maybe you are mapping memory in/out dynamically ? Let the setup be as defined above, a compativle with no 'upper' RAM. under /some but not all/ BIOSes, it seems the presence of a DOS MCB-covered zone under the 'video' area may perturb conventional memory reporting by the API of int 15/E820. Not confirmed. don't make things up I'm not making thins up, you needn't make derogatory comments. Then, that was off-topic and as I did write, unconfirmed. Want more ? OK, additionally, some (admittedly very rude, maybe very old) DOS programs will neglect to check where the memory 'above' them ends, and use any and all BIOS int 12 mem without reservation. sure. execute such programs, and you deserve no better. CtrlAltDelete will clean up ;) LOL. Admittedly the argument was far fetched. None the less, this is how MS does it). it was easier to do it the way it is, and so far nobody complained. HA ! Sincerity itself, at last! Now this I /can/ understand, and even sympathise with :=) Not in line with what Dennis wrote, though... that's a pretty good design decision. Only for so long as no one disputes it :=)... FreeCOM can't claim MS-Command.com compatibility until time it has an option, and I would suggest, the /default/, to allocate the master env block from the bottom, instead of the top of conventional mem. Besides, I hardly see how it was easier, your word, for FreeCOM to do it in the current way. I'd rather suspect whoever made the decision, back when, was confused, similar to how DM Cunney remained somehow apparently confused to this day. Optionally relocate to an available UMB. already done (in 2001). I know, a good thing - but not the question. Regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
... a user who is able, one way or another, to have usable RAM mapped above the 640 k so-called limit into the video memory' segments, up to 736 k (B7FFF), will be forced to use the added memory as UMBs instead of an extension of *contiguous* so-called conventional mem. Is this what you're trying to do (get more than 640k without using UMB's), and why you don't like the XBDA / master environment being at the top of conventional memory? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
That's funny, because I thought that the master environment was controlled by the kernel.sys? Maybe they can add a switch that forces the environment be loaded in upper ram instead of conventional? -Chris Http://digitalatoll.com/ Http://tawhakisoft.com/nxdos.html On Thursday, July 4, 2013, Bertho Grandpied wrote: Hi List ! I've seemed to notice Command.com locates its master environment block at the top of conventional memory, just under the video (and under a BIOS defined extended bios data aka EBDA, if any). Is this behaviour user-controllable with some switch while loading FreeCOM ? Or otherwise, depending on the global FDConfig ? I could not find a way to change this - which is not a good design decision overall IMHO, at least not if it can't be overridden :-( Regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/freedos-user -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
That's funny, because I thought that the master environment was controlled by the kernel.sys? obviously not as it's size is controlled by '/E:512' Maybe they can add a switch that forces the environment be loaded in upper ram instead of conventional? 'they' could do nearly everything at the time the environment was put to ~9f00:0 there simply didn't exist upper memory in FreeDOS (and having a switch to move ~512 byte to upper memory is not s exiting ;) Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi Bertho, I've seemed to notice Command.com locates its master environment block at the top of conventional memory, just under the video (and under a BIOS defined extended bios data aka EBDA, if any). Is this behaviour user-controllable with some switch while loading FreeCOM ? what would be the purpose to change this ? whee would you like to have it ? Or otherwise, depending on the global FDConfig ? I could not find a way to change this - which is not a good design decision why is this not a good design decision ? where would you put it and why ? overall IMHO, at least not if it can't be overridden :-( Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
On Thu, 4 Jul 2013 21:08:12 +0200 Tom Ehlert t...@drivesnapshot.de wrote : I've seemed to notice Command.com locates its master environment block at the top of conventional memory Is this behaviour user-controllable with some switch while loading FreeCOM ? what would be the purpose to change this ? whee would you like to have it ? Or otherwise, depending on the global FDConfig ? I could not find a way to change this - which is not a good design decision why is this not a good design decision ? I'm surprised you have to question this! Tis bad because the block in question exceedingly ill-placed, a user who is able, one way or another, to have usable RAM mapped above the 640 k so-called limit into the video memory' segments, up to 736 k (B7FFF), will be forced to use the added memory as UMBs instead of an extension of *contiguous* so-called conventional mem. Of course the default placement of an XBDA (in case there is one, that is, almost always nowadays) deserves the same blame but either the kernel or some utility will routinely relocate it down during Config.sys processing. We could have a separate utility for relocating Freecom's primary env, but, frankly, the command processor shoud be able take care of it itself. where would you put it and why ? The why has been explained. In addition, under /some but not all/ BIOSes, it seems the presence of a DOS MCB-covered zone under the 'video' area may perturb conventional memory reporting by the API of int 15/E820. Not confirmed. Want more ? OK, additionally, some (admittedly very rude, maybe very old) DOS programs will neglect to check where the memory 'above' them ends, and use any and all BIOS int 12 mem without reservation. for that reason the end of the 'transient program area' should as far as possible coincide with the end of conventional (int 12) memory. To where : by default, or absent DOS-managed UMBs, put it on top of the main FreeDCOM code (this is how MS does it). Optionally relocate to an available UMB. overall IMHO, at least not if it can't be overridden :-( Re-iterating ! -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
On Thu, Jul 4, 2013 at 4:17 PM, Bertho Grandpied y31415926...@yahoo.fr wrote: On Thu, 4 Jul 2013 21:08:12 +0200 Tom Ehlert t...@drivesnapshot.de wrote : where would you put it and why ? The why has been explained. In addition, under /some but not all/ BIOSes, it seems the presence of a DOS MCB-covered zone under the 'video' area may perturb conventional memory reporting by the API of int 15/E820. Not confirmed. Want more ? OK, additionally, some (admittedly very rude, maybe very old) DOS programs will neglect to check where the memory 'above' them ends, and use any and all BIOS int 12 mem without reservation. for that reason the end of the 'transient program area' should as far as possible coincide with the end of conventional (int 12) memory. Placing the environment at the top of conventional memory is what MS-DOS COMMAND.COM did, and FreeDOS tries to be DOS compatible. I never had a problem because of it. One thing I used to run on my old PC XT clone under MS-DOS 3.3 and 5.0 was a freeware utility form Chris (CED) Dunford. It could map unused video memory in the segment above 640K to DOS conventional memory. With a CGA card you could get 96K of additional RAM. With my Hercules card, I could get 64K. so I booted to a system that had 704K of conventional memory. COMMAND.COM putting the master environment at the top of conventional memory did not cause a problem. While it might be nice to relocate the master environment block elsewhere, like upper memory, it's hardly necessary. People lived without being able to do so for decades without problems. I don't ever recall hearing about the sort of problems you raise as possibilities, and I'd call the chances of them happening rare enough to not be worth worrying about. If you insist on this behavior, feel free to submit a patch that adds it. __ Dennis https://plus.google.com/u/0/105128793974319004519 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
So command.com controller the allocating of dos env ? I still always thought it was a kernel level thing , as the way I coded it in nxbio.sys That reminds me that I need to make a dosenv.asm -Chris Http://digitalatoll.com Http://tawhakisoft.com/nxdos.html On Thursday, July 4, 2013, Tom Ehlert wrote: That's funny, because I thought that the master environment was controlled by the kernel.sys? obviously not as it's size is controlled by '/E:512' Maybe they can add a switch that forces the environment be loaded in upper ram instead of conventional? 'they' could do nearly everything at the time the environment was put to ~9f00:0 there simply didn't exist upper memory in FreeDOS (and having a switch to move ~512 byte to upper memory is not s exiting ;) Tom -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/freedos-user -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
On Thu, Jul 4, 2013 at 5:55 PM, Chris Evans aaxiomfin...@gmail.com wrote: So command.com controller the allocating of dos env ? I still always thought it was a kernel level thing , as the way I coded it in nxbio.sys I misspoke. It's more correct to say that placing it at the top of conventional memory is what MS-DOS did, and where COMMAND.COM expected to see it. Same difference - it's what MS-DOS did, and what FreeDOS does to be compatible. I never saw it cause a problem in MS-DOS, and I don't see it's a problem that needs to be fixed. -Chris __ Dennis https://plus.google.com/u/0/105128793974319004519 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
I just wrote a dosenv.asm for nxbio I'll write it up to a int21 call so user app and resize dos environment at will. On Thursday, July 4, 2013, dmccunney wrote: On Thu, Jul 4, 2013 at 5:55 PM, Chris Evans aaxiomfin...@gmail.comjavascript:; wrote: So command.com controller the allocating of dos env ? I still always thought it was a kernel level thing , as the way I coded it in nxbio.sys I misspoke. It's more correct to say that placing it at the top of conventional memory is what MS-DOS did, and where COMMAND.COM expected to see it. Same difference - it's what MS-DOS did, and what FreeDOS does to be compatible. I never saw it cause a problem in MS-DOS, and I don't see it's a problem that needs to be fixed. -Chris __ Dennis https://plus.google.com/u/0/105128793974319004519 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/freedos-user -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
