Re: [Freedos-user] command.com (Freecom) main environment
> I was giving this as one example of why FreeDOS having > relegated the master environment copy to the top of conventional > mem /can/ break things >From my perspective, whether the XBDA, master environment, or anything else is >at the top of memory instead of the bottom shouldn't make any difference, as >long as there's an MCB to identify and "protect" it. If your project doesn't >like it, it sounds like it may be taking "shortcuts" or making assumptions >that aren't necessarily true. I know FreeDOS doesn't (or at least didn't) create MCB's like it should when using the INSTALL= option in CONFIG.SYS, which has caused me some grief in the past. FreeDOS installs its code to operate the INSTALL= option at the top of conventional memory, but doesn't create an MCB to "protect" it. My workaround doesn't specifically check for FreeDOS (since I have a feeling other DOS's could have a same/similar problem), but instead check for the presence of an MCB that includes the address my program will return to when it exits. If an MCB doesn't exist, I create one (temporarily) to keep FreeDOS from obliterating its own memory as I allocate memory for my program to use. MS-DOS doesn't need the workaround. I don't know if a workaround for your project could do something similar or not. -- 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
Hi Eric, > this thread seems to mix two topics: Yep, things got mixed, I suppose it's my fault. Consequently I'll try to leavo out - not quote - the bits which, though they may be interesting, I think irrelevant herein (snip...) > As Tom already pointed out, the location of the > master env in FreeCOM is "near the end of the free DOS RAM", > but only AFTER you get the chance to load e.g. UMB drivers. And as I must stress once again, I am considering the /alternate/ case, when no UMBs will be provided for DOS use. I have been suggesting that in this case, FreeCOM ought to allocate the block that it reserves for storing the main (1st level) environment area. Similar to what other reference DOSes have done forever (well, starting since MS-DOS 2, I think DOS 1 did not have the concept of "environment variables" later "borrowed" from Unix... > Also, the FreeDOS kernel allows you to control whether the > BIOS XBDA data should be relocated. This was a lateral question, but still : how ? the kernel we use doesn't seem to obey a 'Switches=/E' directive in Config.sys, that is the MS-DOS way. > So FreeCOM might differ from MS DOS, but still behave in a good way. I beg to differ vigorously - it behaves in a bad (tm) way. >> ...this bizarre, unmotivated, design of FreeCOM definitely interferes >> negatively with some aspects of the project. It isn't ruining all, > Bizarre yes, unmotivated no. For example XMS swapping is one > very useful feature of the complex FreeCOM memory handling. Like 4DOS by the way. I fail to see what XMS swapping (nice to have) is to do with my critique, though... >> Back to FreeCOM : of course we, app programmers, could devise a utility >> for the purpose of moving that darned environment back to where it >> belongs, i.e., low contiguous DOS-managed memory. > It is still obscure to me why that "darned" environment is so > much in the way for your project where it is with FreeCOM...? Suffice it to say it is an impediment to that project, plus a non conformance that will break other DOS apps for no real reason (that I can perceive) >> Leaving apart the fact that doing so from a transient DOS program and >> without leaving holes is not absolutely a trivial programming task, we >> would be still faced with the problem that, how are we supposed to >> reliably /find/ and adjust the pointer(s) that... FreeCOM internally keeps > I may be mistaken, but should not just the PSP point to the environment? You are mistaken indeed. Command's, or FreeCOM's own PSP would point to /its/ initial environment (if there was any established by Config.sys command, as has been possible in /MS/DOS since DOS 6, I know not whether FreeDOS has a similar concept. Let's not digress again!). Thus, the environment pointer inside the command processor's (shell's) PSP is either NUL, else pointing to an initial environment of no significance nor use.(Digressing again, I have been known to free that useless initial environement). /The/ "master environment" is a brand new one built by Command while it initialises things, and sized according to Command's command line parameters (if this is the primary shell, in turn lifted from the SHELL line in config.sys). Command / FreeCOM has to ask a block from DOS using the usual allocation functions 48h etc, with appropriate choices of "strategy". To sum up, repairing FreeCOM may be as simple as it passing the proper allocation strategy, i.e., don't include UMBs + find lowest suitable block as part of its DOS calls reserving that block. to the shell from DOS System initialisation.) >> Clearly IMHO it is Freecom's responsibility (i.e., of whoever is tasked with >> debugging, maintaining and enhancing FreeCOM) to provide the solution, >> be it a command line option, a permanent fix, or even an API. >See above. Also, nobody is "tasked" with FreeCOM, as this is >not a commercial product. I meant tasked in the sense of being the official maintainers, not as in paid for doing it. > Unfortunately, very few people who > are FreeCOM experts are around here recently... On the other > hand, maintenance is so slow because there was so little left to improve. Understood. Maybe if whoever is familiar with FreeCOM sources would consider the elements I have tried to provide, they would not find it unsurmountable to repair (or diplomatically, revise) this aspect. 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
On Fri, 05 Jul 2013 19:44:45 +0200, Eric Auer wrote: > As mentioned earlier in this thread, there could > be some regressions between 0.82, 0.83 and 0.84, so you might > find an older version to be more of your taste. Not regarding > the master environment, but in general. > > PS: I totally agree that the tab completion beep should be > disable-able and/or switchable to DOS console or BIOS BEL > char output, as it can be annoying and even cause hangs. Wrong thread/list? -- 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
Hi Bertho, this thread seems to mix two topics: MS DOS command.com keeps transient data in non-MCB areas. When, after running commands, that area is found damaged, contents are dropped and reloaded or recreated. As Tom already pointed out, the location of the master env in FreeCOM is "near the end of the free DOS RAM", but only AFTER you get the chance to load e.g. UMB drivers. Also, the FreeDOS kernel allows you to control whether the BIOS XBDA data should be relocated. So FreeCOM might differ from MS DOS, but still behave in a good way. > ...this bizarre, unmotivated, design of FreeCOM definitely interferes > negatively with some aspects of the project. It isn't ruining all, Bizarre yes, unmotivated no. For example XMS swapping is one very useful feature of the complex FreeCOM memory handling. > and we could well use another shell than FreeCOM - in fact, I think > the project will be its own shell for a self-contained diskette or > USB-stick of sorts. Sounds like a nice project. > Back to FreeCOM : of course we, app programmers, could devise a utility > for the purpose of moving that darned environment back to where it > belongs, i.e., low contiguous DOS-managed memory. It is still obscure to me why that "darned" environment is so much in the way for your project where it is with FreeCOM...? > Leaving apart the fact that doing so from a transient DOS program and > without leaving holes is not absolutely a trivial programming task, we > would be still faced with the problem that, how are we supposed to > reliably /find/ and adjust the pointer(s) that... FreeCOM internally keeps I may be mistaken, but should not just the PSP point to the environment? > Clearly IMHO it is Freecom's responsibility (i.e., of whoever is tasked with > debugging, maintaining and enhancing FreeCOM) to provide the solution, > be it a command line option, a permanent fix, or even an API. See above. Also, nobody is "tasked" with FreeCOM, as this is not a commercial product. Unfortunately, very few people who are FreeCOM experts are around here recently... On the other hand, maintenance is so slow because there was so little left to improve. As mentioned earlier in this thread, there could be some regressions between 0.82, 0.83 and 0.84, so you might find an older version to be more of your taste. Not regarding the master environment, but in general. Regards, Eric PS: I totally agree that the tab completion beep should be disable-able and/or switchable to DOS console or BIOS BEL char output, as it can be annoying and even cause hangs. -- 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
On Fri, 5 Jul 2013 15:45:34 GMT "Bret Johnson" Hi Bret ! (long time, no see...) >> ... 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 "UMB"s 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? I was giving this as one example of why FreeDOS having relegated the master environment copy to the top of conventional mem /can/ break things. I could have given quite different examples, nor exaples I could name old programs still available which were written as early as the times of MS DOS 2 (!) with the implied assumption that Command's env block follows immediately above its PSP's block. The exact reason which made me stumble on this non-conformity of FreeCOM's does not need to be discussed in detail, it is complex and would derail the discussion. Fact is, some project someone else is building has elected to use a FreeDOS boot disk for a basis, and this bizarre, unmotivated, design of FreeCOM definitely interferes negatively with some aspects of the project. It isn't ruining all, and we could well use another shell than FreeCOM - in fact, I think the project will be its own shell for a self-contained diskette or USB-stick of sorts. Now see! you've driven me into digressing from my initial purpose here again ;=) Back to FreeCOM : of course we, app programmers, could devise a utility for the purpose of moving that darned environment back to where it belongs, i.e., low contiguous DOS-managed memory. Leaving apart the fact that doing so from a transient DOS program and without leaving holes is not absolutely a trivial programming task, we would be still faced with the problem that, how are we supposed to reliably /find/ and adjust the pointer(s) that of necessity FreeCOM internally keeps to the environment ! Clearly IMHO it is Freecom's responsibility (i.e., of whoever is tasked with debugging, maintaining and enhancing FreeCOM) to provide the solution, be it a command line option, a permanent fix, or even an API. Hoping this could be at least some food for thought, and Taking the leave for now -- 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 "UMB"s 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
[Freedos-user] Fw : (Q) recommended way to reliably check for FreeDOS vs. AnyDOS ?
Dear List, I'm forwarding a new copy of a programmer's question I sent yesterday to Freedos-devel but for some reason apparently didn't reach to the list server - maybe stalled somewhere, or awaiting processing by the US NSA ? Of course there is a risk that you guys will suffer receiving 2 or more copies, in advance of which I send my most sincere apology. --- On Thursday, 7.4.13, Bertho Grandpied a wrote : > Objet: (Q) recommended way to reliably check for FreeDOS vs. AnyDOS ? > Programmers, Kernel people, hi ! > > What is (are) the recommended way(s) to assert > programmatically one is running under FreeDOS, versus other > common DOS brands and versions ? > Precisions : > - I am going for the simplest, yet reliable identification > method. The problem posed here is to /reliably/ single out > FreeDOS from foreign DOSes, NOT necessarily to get at > FreeDOS (sub)version numbers (real or faked!). > > - Method should work in any reasonably current versions of > FreeDOS - say 0.9, 1.0 and 1.1, whatever compilation > options, and also be future proof w/ respect to FreeDOS, if > possible. > > - Must be available at system initialisation time (callable > from a device driver's 'init' routine, that is). > > Requirement 1 - simplicity - suggests that we should use a > FreeDOS-kernel-specific API, if such exists. But reliability > of the detection is /primordial/, so, if reliabity means we > have to 'peek' into the kernel and 'walk' binary structures, > so be it. > > Of course we can't trust blandly the general documented DOS API > calls for "version" or even "true ver", can we ? I believe > true ver /should/ not lie but I also think (may be wrongly) > that FreeDOS truever /does/ lie in certain circumstances, > unfortunately. > > Obviously I could hack-and-design something by myself, > however I would much much preffer to do things in the > sanctionned way whenever possible. > > Thanks in advance. If this is documented well somewhere, a > pointer will do for an answer. > -- 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 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
>>> 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 "UMB"s 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
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 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
