Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
Arkady V.Belousov wrote: Hello, 19-Июл-2004 13:59 [EMAIL PROTECTED] (Steffen Kaiser) wrote to "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>: You mean "Arkady called MS-DOS-style empty environment broken"? Yes, I call this. But this is MS-DOS and all its bugs become standard and called SK> So, you've "fixed" the FreeDOS kernel to issue the broken MS-DOS "empty SK> environment" to programs, did I understood it correctly? No. I fix the task.c:ChildEnv(), which was wrongly scans empty environment with non-MS-DOS-style layout (only one empty ASCIIZ string). And yes, currently ChildEnv() for empty environment uses MS-DOS layout. SK> Huh? So I did understood it correctly!? No. SK> What does the kernel do now, when the "originally correct empty SK> environment layout" arrives there? "Originally correct" - with one empty ASCIIZ string? Currently prepared MS-DOS-style empty environment. (DO WE SAY ABOUT BRAND NEW OS OR ABOUT MS-DOS CLONE?!) We talk about FreeDOS, usually. SK> Does it care at all, well, it shouldn't? ? "Task.c:ChildEnv(), which was wrongly scans empty environment with non-MS-DOS-style layout" For me this phrase means "ChildEnv() is analyzing an existing environment passed into the function and will now honor only the MS-DOS format of an empty environment". So I wondered why ChildEnv() cares about the second '\0' of the MS-DOS-style empty env at all. When the function needs to prepare such environment, there is a diffenerence, of course. What you have against? SK> You've broke the compatibly with existing FreeDOS-near programs. Have you Please, name "existing FreeDOS-near programs", which works under MS-DOS and not works under (patched by me) FreeDOS. SK> What bugs me is: You've intentionally broke the compatibly with existing SK> implementations for no good reason, WHICH COMPATABILITY I BROKE?! The compatibly between the FreeDOS kernel and the FreeDOS shell. And, because you've mentioned yourself that the knowledge of the MS-DOS style empty environment is damn brand-new, any other FreeDOS program probably used in INSTALL=. SK> Actually, it would be cleaner to never issue an empty environment. You MS-DOS may. Also, "not issue empty environment" anyway mean "don't make availabel startup path" (what makes FreeCOM unhappy). SK> To pass a non-empty environment to a programs means that it is not able to SK> get argv[0]?? How you read?! "Not pass empty environment" mean putting zero valie into PSP[2C] word (as MS-DOS does, BTW). Or you mean, that someone should ADD into ChildEnv() adding of some garbage into environment to make it _look_ like non-empty?! For me an empty environment is an existing environment with no variable defined; and "no environment" when PSP[2C] contains zero. And yes, instead of rushing out and "fix" something you claim is a bug (because it is not so as in MS-DOS), have a work-around in place to let existing programs work. And, that way, instead of to bend other people to your willing, give them the freedom to decide themselves and, probably, have a remark about the issue. In this particular case: It would be as easy as to pass at least one env variable to the program. SK> How can that be? How got programs, e.g. FreeCOM, aquire its SK> start path from argv[0] during the time, the default environment included SK> the PATH=. variable? MS-DOS (neither kernel, nor MS-command.com) NEVER INCLUDES SUCH VARIABLE INTO ENVIRONMENT (empty or not). If in config.sys not present menu or some SETs, then for INSTALL= MS-DOS passes empty environment into program (in its style), for SHELL= it places zero into PSP[2C]. _My_ difference with MS-DOS in this respect is that I always pass (empty) environment (but with startup path), both for INSTALL= and SHELL=. I don't care about MS-DOS, and you as well. Why else would you pass non-zero to SHELL=? To gain a feature, to gain FreeDOS rather than another MS DOS. Utilities, unhappy). Also, MS-DOS _passes_ empty environment, why we shouldn't? SK> Because this introduces known incompatibly with existing implementations, Blame "existing implementations", which doesn't work under MS-DOS (and why they should work in FreeDOS, if they written for MS-DOS?!). Hmm, I thought we implement FreeDOS. SK> and I expect that such stuff is discussed in advance among all affected SK> people. I TRY TO DISCUSS, BUT SILENCE IS ANSWER. You mailed a bugreport, no word about to immediately release a kernel that breaks compatibly with FreeCOM. Here it is: "FreeCOM incorrectly handles empty environment, _as this understanded by MS-DOS_. Trouble is that for empty environment MS-DOS places before 16-bit counter not _one_, but _two_ zero bytes. This
Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
Bart Oldeman wrote: Why not use the I/O stack (char_api_tos)? When process0 terminates & the this may be possible but tricky in C. As the code must make sure it doesn't use any stack that it relies from before int21/ah=4b after int21/ah=4b. I don't understand: When process0 is about to be spawned, no other stack is in use. The only stack that can be activated is in case of a Critical Error. When DOS-4C jumps to the termination address, which lays in the resident kernel space, it runs on the disk_api or user stack I haven't checked, so no conflict. But before DOS-4C jumps there, it restores SS:SP, pokes the return address there, then pops all the registers and iret's <-> from this point on no other stack, no other values are of interest, because all that counts is that the process0's termination handler is activated. Why would that be tricky? The framework uses more or less the same mechanism as entry.asm and the usual DOS-4B/4C functions with faked entries for SS:SP,& int22/23/24 in the system PSP. (OK, DOS_PSP->SS:SP := char_api_tos - sizeof(user registers), I forgot about the restoring of the registers by return_user()). All that needs to be done is to have to right values in the system PSP, when process0 is spawned by the DOS-4B routine -- hence, setup by the init code? And because those values are not modified by DOS-4B/4C, once setup you can re-use them for every load-again attempt. (DOS_PSP->SS:SP is not changed, because this is done by entry.asm, which is bypassed when spawning process0 via the internal DOS-4B rather than an INT-21 system call.) Once return_user() has been performed, I see no difference as when the kernel had been activated through entry.asm? Because you have no caller, you won't return and, hence, need not preserve the registers. All that's not equal is the DS frame and the InDOS flag, but both can be handled right at the top of the termination handler. Bye, -- Steffen Kaiser The current maintainer of [EMAIL PROTECTED] http://freedos.sourceforge.net/freecom/FreeCOM.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re3: Primary shell EXIT crashes with invalid opcode
Arkady V.Belousov wrote: Hello, EA> So it is POSSIBLE that the user next wants to use the same shell again. Or EA> a typo in the SHELL= line threw him out of the shell. In both cases it would EA> be nice to be able to use the old shell line as default for the prompt Yes, good idea. Though, kernel should store somewhere full (up to 128 bytes) command line after shell[high]= in config.sys. :( During the initial load of the shell, OK, but when the kernel successfully spawned the SHELL= I do not see no real gain in order to waste 128 bytes of memory. Bye, -- Steffen Kaiser The current maintainer of [EMAIL PROTECTED] http://freedos.sourceforge.net/freecom/FreeCOM.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
* init_call_p_0() will need to (in a .asm file): set SS and DS to the DOS data segment (DGROUP, cs:[_DGROUP_]) set SP to the top of a special p_0 stack (how many bytes for that stack?) Why not use the I/O stack (char_api_tos)? When process0 terminates & the InDOS flag is set, this stack should be free for use, because no other system call can take place and TSRs and the like are hold off by the InDOS flag. And this stack should not be in use when DOS-4C is initiated. Bye, -- Steffen Kaiser The current maintainer of [EMAIL PROTECTED] http://freedos.sourceforge.net/freecom/FreeCOM.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
Luchezar Georgiev wrote: I tried to change user_r->CS and user_r->IP, but the linker complained. Well, but because those two are assigned to the terminate address of process0, you must initialize them. Regardless from where you start the Load-Process0 function. Um, BTW: process0 must also have a nice ParentPSP, because return_user() takes the SS/SP from there and happily pokes the termination address there. (Well, I did reported this as security hazard years back, e.g. debuggers and TSR might do PSP switching and, hence, destroy there own SS/SP fields - but I never read that you have to preserve these fields). Also, You have to deal with a reset INT-24, hence, restoring it to the internal autofail routine is a good idea; same as INT-23. Bye, -- Steffen Kaiser The current maintainer of [EMAIL PROTECTED] http://freedos.sourceforge.net/freecom/FreeCOM.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
Luchezar Georgiev wrote: Eureka! Just found a way to do it! Just before executing the shell, "setvec(0x22, shutdown)". In new_psp(), after "p->ps_isv22 = getvec(0x22);", compare the vector to shutdown and if it matches, "setvec(0x22, int22_handler);". Voila! Expect the patch in a couple of hours ;-) Hi Lucho, maybe I totally misinterpreted the stuff, but Init_DosExec() from within kernel() loads process0, right?? Init_DosExec eventually ends up in DosExec() -- or at least in a function identical to it?? DosExec() spawns for example DosComLoader(), which does: /* point to the PSP so we can build it */ setvec(0x22, MK_FP(user_r->CS, user_r->IP)); new_psp(mem, mem + asize); So, within kernel() when Init_DosExec() is called, will the function know where the persistent "shutdown()" is located? If so, fake up an user_r structure before calling Init_DosExec and place the address therein. Bye, -- Steffen Kaiser The current maintainer of [EMAIL PROTECTED] http://freedos.sourceforge.net/freecom/FreeCOM.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
