Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
On Thu, 26 Feb 2004, Luchezar Georgiev wrote: On Thu, 26 Feb 2004 08:48:17 +0100 (CET), Steffen Kaiser wrote: As you showed, the reloading of the shell is performed by the kernel in MS DOS. I do not suggest to copy this behaviour Neither do I. ROM-DOS expects the user to type a new shell name. But even this is not mandatory. Well, you miss the point: The kernel asks the user about the file name, in order to (re-) load the shell. MS DOS always displays the same (exact phrasing of the words and behaviour) text when to load the shell initially and when to reload the shell on demand. I actually believe (without testing, because it's not really interesting how MS COMMAND performs internally) that both processes are really the same (inital loading and reloading), but the loaded fragment decides whether to create a new instance or to pick up an already running one. but to have a the computer has shutdown. I think that shutdown is a term related to multi-tasking systems like Unix, VMS, NT, OS/2... IMHO the term has shutdown simply means that it is no longer running. It is not the question or action to shutdown the computer. Now power off or reboot message. Or simply reboot without waiting for the user! It's the only thing he can do at this point anyway. Nope; then you do not see any error messages on the screen or have the computer endlessly rebooting or ... . Bye, -- Steffen Kaiser --- 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=1356alloc_id=3438op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reference compiler (was Re: [Freedos-kernel] Re: patch: inthndlr.c)
On Mon, 10 May 2004, Bart Oldeman wrote: Hi Tom, You don't remember correctly. the kernel reference compiler has been for a long time TC 2.01 (which is free), and has been changed to OW because it generates better (smaller) code, and because it's free and open. Aitor remembers correctly -- he simply goes a few years further back than you and me. Before August '99 TC 2.01 couldn't be used. Watcom's been used as reference since Feb 2002. http://fd-doc.sourceforge.net/spec/spec.html Section Programming Tools To Be Used Our reference standard for a C compiler will be Borland C 3.1. Our reference standard for Assembly will be Microsoft MASM. Borland C 3.1 was chosen as the reference standard because this is the compiler used to build the FreeDOS kernel. Microsoft MASM was chosen as the reference standard because of the free availability of MASM-compatible assemblers. The existing code base was also a deciding factor in choosing a reference standard. How about to change the reference compiler not only for the kernel, but for all the project? There had been a movement from MASM to NASM already, so this can be reflected here as well. This is missing some documentation as well, right? It would be helpful to have some port MASM -- NASM document. I know Jim can phrase the change of the reference tools so that Turbo C becomes a backup-solution, not to be turned down immediately. Arkady, how is your progress toward OW going? Did have you assembled a Mini-DOS-OW development environment, for instance? I just unpacked any ZIP, except that ones specifically marked as Fortran. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: nls.c
On Fri, 25 Jun 2004, Eduardo Casino wrote:
Trivial patch. Pass correct values for codepage and country from DOS-38
and DOS-65-XX functions to MUX-14 functions.
I would actually suggest the following function, as searchPackage is to
resolve the default values as well; otherwise your patch breaks the
possibility of non-direct (MUX-only) country data, which in turn breaks
the whole current NLS design, which would make it better to replace all
the code. Latter would be better, I guess, anyway.
COUNT DosGetData(int subfct, UWORD cp, UWORD cntry, UWORD bufsize,
VOID FAR * buf)
{
struct nlsPackage FAR *nls; /* NLS package to use to return the info
from */
log((NLS: GetData(): subfct=%x, cp=%u, cntry=%u, bufsize=%u\n,
subfct, cp, cntry, bufsize));
if (!buf || !bufsize)
return DE_INVLDDATA;
if (subfct == 0) /* Currently not supported */
return DE_INVLDFUNC;
/* nls := NLS package of cntry/codepage */
if ((nls = searchPackage(cp, cntry)) != NULL) {
/* matching NLS package found */
if((nls-flags NLS_FLAG_DIRECT_GETDATA) != 0)
/* Direct access to the data */
return nlsGetData(nls, subfct, buf, bufsize);
cp = nls-cp;
cntry = nls-cntry;
}
/* If the NLS pkg is not loaded into memory or the
direct-access flag is disabled, the request must
be passed through MUX */
return (subfct == NLS_DOS_38)
? mux38(cp, cntry, bufsize, buf)
: mux65(subfct, cp, cntry, bufsize, buf);
}
--
Steffen Kaiser
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: nls.c
On Fri, 25 Jun 2004, Eduardo Casino wrote: Hallo Eduardo, Sorry it took so long. Honestly, I would like to: a) either get my whole distribution off the kernel or b) get in touch with you about the internals and the design decissions. BTW: I had changed your name in the CHANGED history file. Bye, -- Steffen Kaiser --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel progress
On Tue, 6 Jul 2004, Arkady V.Belousov wrote: Hello, config.c - config now parsed in 5 passes: te that's fine IF config.c fit's into buffers or you boot from disk. te else (if boot from floppy) that might become *SLOW* There was 3 passes, now 5. Not a big change, especially because on some passes there will be other disk accesses (drivers, installs, shell). When I test config.sys working (on floppy), for me this is enoughly fast. Of course, my config.sys-es are much lesser than 10k (20 buffers are preallocated before processing config.sys), but I don't think that you will notice *SLOW* even on bigger config.sys. But what you propose else? 5 passes are _required_. What I still wonder about this topic -- I remember that I had a CONFIG.SYS size problem with Win95 (when its size grew past some point, DOS 7 did't start) -- aren't device drivers allowed to mangle with drive mappings? I mean there is (was?) a DSWAP.EXE or SWAP.EXE or whatever from stacker that allowed to compress the boot drive by swapping C: with the drive letter the compress-on-the-fly drive got. This was before MS came up with the DRVSpace.BIN approach. I actually believed that CONFIG.SYS is to be kept in memory because of this stuff. Is this handled silently by the buffers? Bye, -- Steffen Kaiser --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel progress
On Tue, 6 Jul 2004, Arkady V.Belousov wrote: PS: Steffer, when you answer to my letter in the freedos-freecom about issues with environment in FreeCOM? That depends on which mail you mean: a) about LAST_FIT: I said all what I have to say: I do not currently change the behaviour. b) about the env bug: There has been sent a patch by Tom already (actually, it's in Bugtrack, but I didn't got no notification by it). b) about the search for FreeCOM in certain places: suggestion has been noted. c) I had to test it, it seems that FreeCOM prompt the user once, but never again. This is strange. Bye, -- Steffen Kaiser FH Bonn-Rhein-Sieg| e-mail: [EMAIL PROTECTED] FB Informatik | Grantham-Allee 20 | phone : +49 2241/865-203 53757 Sankt Augustin | Germany - Deutschland | fax : +49 2241/865-8203 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel progress
On Fri, 9 Jul 2004, Arkady V.Belousov wrote: Hello, SK That depends on which mail you mean: SK b) about the env bug: There has been sent a patch by Tom already SK (actually, it's in Bugtrack, but I didn't got no notification by it). ^ Bugzilla, of course :) I see neither answers to my letter, nor patches in freedos-cvs. Also, I Yes, because I do not process posts when the mail flows in, but when I have time. I guess there are two or so threads in the archive discussing this topic that I do not timely act on submissions. wish to know URL of fixed FreeCOM executable, which I may use to replace one from 2035. I have several patches and suggestions pending, therefore I don't spent time to make yet another test release, but applying them. Pending before next release are: + search for executables with single findfirst, + filename completion rewrite, + FreeCOM executable search [#1773], + upd italian strings, + redesign of SUPPL integration [#1794], + automated localized pre-compiled FreeCOMs, + (and two things I don't have in my memory and on this mail server). SK b) about the search for FreeCOM in certain places: suggestion has been SK noted. I not see your confirms to my letter with explanations what you plan. Bugzilla #1773. Really, guys, I'd wish everybody would use Bugzilla for both to report and query bug reports and wishes. It would make my live easier. At least an entry in Bugzilla and, in order you don't want to make confidential information or an URL or such public, a private mail. SK c) I had to test it, it seems that FreeCOM prompt the user once, but never SK again. This is strange. What strange? Your results strange or I report something wrong? Details, please. The behaviour of FreeCOM is strange as it should ask for its location any time it unsuccessfully searches for a resource, not only once it its livetime. Bye, -- Steffen Kaiser --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeCOM bug reporting (was: kernel progress)
On Tue, 13 Jul 2004, Eric Auer wrote: Hello Eric, thanks for the list. What is it to tell me? Reporting bugs is nice, but fixing them is better. I already spend far too Yes, and reporting via Bugzilla is better than sending mails. This is what I wanted to say. And sending already reported bug reports again won't raise my interest, but annoys me. Bye, -- Steffen Kaiser --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
On Sat, 17 Jul 2004, Arkady V.Belousov wrote: Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks like Steffen fixes (at least, one) bug, related to environment, but up to now I don't know where to download fixed version. (May be, now you remind for Steffen to make fixed version available for download?) Arkady, FreeCOM _never_ had a problem with an _empty_ environment, but: + with a missing '.' in PATH, long fixed, and + with the MS-DOS-style of an empty environment, you've called broken yourself. That's also fixed in CVS. No other problems are aware to me. BTW: To add PATH or COMSPEC won't hurt any shell. I may ADD adding any variable (including PATH=.) to (empty) environment, but better, if Steffen at last makes fixed FreeCOM available for download. Steffen?! When? May be, now you see that fixed programs should be available to download? I do not have no service contract about FreeCOM with anyone, so I will handle my resources at own will. I WILL NEVER DISCUSS THIS ISSUE AGAIN. If this topic comes up again, simply search the archives for my side of the thread. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
On Mon, 19 Jul 2004, Arkady V.Belousov wrote: Hello, Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks ^^ like Steffen fixes (at least, one) bug, related to environment, but up to now I don't know where to download fixed version. (May be, now you remind for Steffen to make fixed version available for download?) SK Arkady, FreeCOM _never_ had a problem with an _empty_ environment, but: See underlined words above. With empty environment FreeCOM (whic is currently available for use) _is_ buggy. SK + with a missing '.' in PATH, long fixed, and SK + with the MS-DOS-style of an empty environment, you've called broken SK yourself. 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 So, you've fixed the FreeDOS kernel to issue the broken MS-DOS empty environment to programs, did I understood it correctly? Actually, it would be cleaner to never issue an empty environment. You will, for instance, find a reply in the archives from yourself, stating that the end of the environment is _not_ marked by '\0\0' (two bytes zero) as the poster stated, but by an empty string, hence, when the environment is completely empty, there is a single '\0'. To have a good and working work-around for any program and your own advices, it would be best to never pass on an empty environment. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: NLSFUNC and callbacks into kernal (was Re: [Freedos-kernel] Strange bug in kernel 2035)
On Tue, 27 Jul 2004, Bart Oldeman wrote: On Mon, 26 Jul 2004, Steffen Kaiser wrote: DOS has three internal stacks, how about switching to the Critical Error stack and defer any calls when the stack is in use? You'd automatically overflow into the Critical Error stack anyway. I So you can set DOS's Critical Error flag and be happy? wonder about defer though -- how do you defer a critical error handler, when say, you try to find a:COUNTRY.SYS without a floppy in the drive? At first sight a delayed critical error handler seems more difficult than switching stacks OK, defer is not the right word, how about autofail. Or, re-enter DOS as like in case of a Critical Error. I never tested (or used) NLSFUNC in conjunction with floppies and I certainly never considered this an option. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Tue, 10 Aug 2004, Bart Oldeman wrote: I don't think other DOSes route things through int25/int26 either, I tested that a few years ago. It would be a major headache anyway as int25/26 would reset the DOS stack pointer! RBIL explicitly mentions There is yet another thing why DOS cannot use the plain INT-25/26 (maybe some internal counter function): ASSIGN hooks all three INT-21/25/26, hence, rewriting would take place twice. Bye, -- Steffen Kaiser --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
