> EA> Nice. Before that, you can help to bug-hunt FreeCOM 0.84, which > EA> is pretty important at the moment.
> Blair asks help in adding INT2E support, but he not answers, what he > does and what (precisely) doesn't work. If you precisely explains, what > should be hunted, I may try to do this. Oh well. This has absolutely zero priority. FreeCOM 0.84 is so shaky, I still recommend to use 0.82pl3 for production systems. Yet 0.84 has so many added features (well, mostly one feature in many commands: long file names, LFN) that it would be worth the effort to get it stable for FreeDOS 1.0! The int2e thing is an API to which you can pass a string which is then processed as if you had typed it at the prompt. Useful for example for setting variables in the master environment. This is also the test case: While a proper int2e implementation might have several evil caveats to be dealt with, an initial version which can do ECHO and SET without crashing would already be fun to play with. Hm. Now that I think about it, one could even write a special int2e handler which does SET in it's own way, just using some global variables of FreeCOM, without swapping in the core FreeCOM engine and stuff ;-). It could display an error message for all other commands. Basically int2e is hardly used for other things anyway. A full int2e implementation for FreeCOM would be similar to the main XMS swap engine. You run a command, FreeCOM swaps itself out to XMS, the command calls int2e, the handler swaps FreeCOM back in from XMS, possibly taking care to bring FreeCOM in a suitable state first (pretend that the command had exited, but not quite), then pass the string to the command line parser of FreeCOM. When FreeCOM is done, the int2e wrapper would swap FreeCOM back out to XMS. Then the command continues. When the command is done, XMS swap swaps FreeCOM back into memory and things continue as normal. As you can see, this allows some partial reentrancy for FreeCOM. And it is complex as heck, because the XMS swap engine is very fragile code. Blair tried to write an int2e handler himself, but it is nowhere near what the handler actually should do. In short, int 2e support is a very good example of a thing which we should not even THINK about while FreeDOS version 1.0 is waiting for some critical bugfixes at totally different places. First things first. PLEASE. If you would like to help to debug FreeCOM, I can forward you a longish list of comments / diffs. What I did was to check all recent updates via the CVS http web interface and look which of them looked fishy. Those should be reviewed. Proof-readers wanted. Note that Blair also introduced a few completely new files in the source code of FreeCOM. I did not check those, as that would have been too much work for me. They are files like lfnfuncs.c and myperror.c and related. And of course the int2e things, most of which are ifdef-ed out for now, luckily. You should be able to find them by checking the cvs logs for files where version 1.1 already is by Blair :-). Eric ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
