Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
On Thu, 5 Aug 2004, Bart Oldeman wrote: Hello Bart, But back to the question: HOW DOES FREECOM KNOW THAT THE CURRENT STANDARD OUTPUT IS THE DEVICE DRIVEN BY THE BIOS? Is it save / useful to use BIOS functions. Or how can FreeCOM ensure the human sitting on the other side of the line is seeing the results. The only reliable way is to trap int10, write a character using int21 and Yeah, that's what I thought of. And there is also some nice try for stdin ;-). That said. In practice a console driver will have the FAST int29 bit set, and a COM driver won't. As int29 will surely write a character to the console. This isn't waterproof in theory but ... I simply don't know of When I saw your mail I had this deja vu feeling we get here on this list much more often ;) Well, this thread deals with CLS in particular. However, my reasoning goes further than that, e.g. the enhanced input needs to position the cursor all over the line, which probably spans multiple physical lines. And Cursor_Left (ASCII 0x08) does not necessarily wrap to the previous (physical) line. Matthias once wrote a long mail saying how other DOSes deal with this. Hmm. I'm curious. He writes that DR DOS issues ANSI escape sequences. Actually they are fine, as long as you have a VT100 provider installed, as I wrote. But it is impossible to detect such provider across a line on another computer. Also, in http://marc.theaimsgroup.com/?l=freedos-devm=101717593306186w=2 he writes /If/ an ANSI (or another extended console) driver is installed and detected (which is not trivial, if it should work with all known ANSI drivers), the command processor will send an ANSI-ED sequence [2J to STDOUT (whereby stands for ESC (1Bh) here). Then: Only if no such driver is around and the console is attached to the physical screen (not redirected, no CTTY), in http://marc.theaimsgroup.com/?l=freedos-devm=101742333130155w=2 If STDOUT does correspond with a device (bit 7) which does *not* supporting INT 29h (bit 3 cleared), it will use a method partially similar to the DR-DOS INT 10h/AH=00h method to clear the screen, in all other cases it will simply issue the ANSI ED-sequence. The INT 10h method used appears to work more So, if STDOUT == COM3 (no Fast Output bit) and the shell does not know about a CTTY COM3 (where should it get the info about it unless the CTTY command was invoked in the shell itself?). it uses the BIOS. My claim is: a) you cannot detect an ANSI driver across the line **), and b) you do not know for sure what CTTY is in place, except the shell itself has invoked it ***). So, what is described there means: if the server computer has ANSI installed locally, it will send ANSI tokens to your client, regardless if your client has ANSI or not; if the shell on the server has not executed the CTTY command itself, it will clear the server's screen through the BIOS. This is what I wrote and what I asked about. When I now move the issue away from CLS toward the enhanced input, I have the problem to freely position the cursor in a long line wrapping upon several physical lines. Actually I seem to be stuck in a problem that cannot be solved automatically, but by the user only, e.g. by setting environment variables or some flags as it is common in Unix shells (TERM=, ROWS=, LINES=, setterm). If one could assume that a VT100 parser is present, the problems would be less. just follow the whole thread (prev and next), there's nothing I can add here, but I assumed you had already looked this up? No, I have no luck using any search engine in conjunction with any FreeDOS archive. Bye, === **) No sample in the messages list a possibility to detect an ANSI driver on the other end of a COM line. ***) Only the hint about device/stdout/fastput. -- Steffen Kaiser --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] How to detect if fd #0/#1 are the local console (was Re: [Freedos-devel] BEEP)
On Sat, 31 Jul 2004, Bart Oldeman wrote: OK, I had already promised that BEEP can: + be silent, + print \a, + do some PC speaker sounding. And the user decide, what to do. The default would be '\a', as it is the most compatible beep at all. no BIOS, no int29, no delay timing, no direct hardware, just keep it simple -- the ASCII beep goes to STDOUT, redirected to STDAUX and beeps at the right place. [[Please substitude COM3 with any name of a driver that is suitable for CTTY.]] It would be, also for other stuff, very helpful to know, if it is save to use local interrupts (video, keyboard) to perform certain actions. For instance: CLS over COM3 may issue a ^L (Form(ular) Feed) or ESC2J (VT100 clear screen), but neither of them work in a WinXP DOSbox (not sure about plain DOS/BIOS). [So one would have to do both, funny ways.] Til this time there had be no suggestion to overcome the requirement about how to detect if: 1) FreeCOM's input comes from the local keyboard (in opposite to FreeCOM MUST use the file descriptor #0 or the read from stdin DOS APIs) and 2) FreeCOM's output goes to the local screen (in opposite to FreeCOM MUST use the file descriptor #2 or the write to stdout DOS APIs). There are two obvious indicators that the console is NOT the local hardware: 1) when fd #0 (or #1 respectively) is NOT connected to a device, and 2) when fd #0 (or #1 respectively) is connected to a device, which has the NUL or CLOCK$ bit set. How can FreeCOM detect a CTTY COM3 situation _without_ FreeCOM had carried out the CTTY command itself, e.g. when you boot the system with another shell or when a special setup (embedded system or maybe a CONFIG.SYS patch making CTTY= available) is used. There had been a discussion that the LoL field last loaded CON: driver is not suitable. Also, the name of the driver itself CON is not suitable, as one can name a driver like that, that is not driving a console at all. Are the stdin/stdout bits of any value? There are destructive tests to determine whether a read originates from or a write targetted the local console (e.g. compare INT-16-01 with a nice combination of DOS-0B/01 -or- INT-10-03 before/after DOS-02). But what are the non-destructive tests that work with COM3? Also: There is the probability that only one of stdin and stdout is connected to the local hardware. Also: Consider this scenario: ===AUTOEXEC.BAT CTTY NUL %COMSPEC% CON CON === funny, huh? Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Format 0.91r and FreeCOM sound tests
On Fri, 30 Jul 2004, Eric Auer wrote: You can HLT between every two 40[6c] readouts - if you know that there is no CLI state. However, why is it a problem to have CPU-heavy beep? For example boot menu delay in kernel does not HLT either and nobody except me ever mentioned the HLT energy saving possibility there. The boot menu is used in a DOS session one time at maximum. I do not care about energy saving, but about DOSboxes. E.g. the while(poll_data); will consume any CPU it gets for nothing, playing nonsense with the scheduler of both Win32 (DOSbox) and Unix (DOSemu). For embedded systems energy saving might be interesting, but I guess one would better disable BEEP there. INT 15 - BIOS - WAIT (AT,PS) AH = 86h CX:DX = interval in microseconds Return: CF clear if successful (wait interval elapsed) CF set on error or AH=83h wait already in progress AH = status (see #00496) Cool! So, what's wrong with this one? One can fall back to the timer ticks for XTs, then?? What's this Hunter/16 conflicting with INT-15? Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
to delay() or not delay() (was Re: [Freedos-devel] Re: Re: Re: Kernel 2035/2035a versus FreeCOM)
On Sat, 24 Jul 2004, Eric Auer wrote: Hello Eric, easy doing: post the code*) to replace delay() and please document, when and on which PC models, hardware and DOS emulators (oh, and the DOSbox of course) the code won't work. And it's easy doing. *) Preferly to Bugzilla. 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] GRC and FreeDOS
On Thu, 8 Jul 2004, Gregory Pietsch wrote: do you know that Steve Gibson(www.grc.com) is Considering spending $20,000 for DR DOS? There is a thread about this in news.grc.com/grc.spinrite.dev. They have a web interface as well: http://news.grc.com/news.exe?cmd=xovergroup=grc.spinrite.devutag= Hmm, I wonder why they use MS IIS while talking about security. 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] GRC and FreeDOS
On Fri, 9 Jul 2004, Alain wrote: I believe this is a very typical representation of FreeDOS development. Some people are optimizing it while critical problems (for some people) remain unsolved. Did they filed bug reports? 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeCOM environment
On Wed, 30 Jun 2004, Arkady V.Belousov wrote: F It is currently not possible to use FIRST_FIT (and therefore BEST_FIT F neither) and I do not hassle with the XMS code to move the environment F segment around. Look at memory map above again. And look at FreeCOM map: -0FA7 2.01k STACKS= 0FA7 64--free-- 0FAB 2.87k COMMAND 1063 574k --free-- 9FEF 272COMMAND environment -A000- SK But what do I see here in conjunction that It is currently not possible SK to use FIRST_FIT (and therefore BEST_FIT neither) for FreeCOM? PS: I understand, that _currently_ you may wish not to bother with FreeCOM code relocation (I think, if there are no UMBs, better if it will place its new environment right before itself, over old environment segment), but which _other_ contras you have against this? I have nothing against to place the environment somewhere else, in general; but it is _currently_ not possible to even consider to have environment right behind the process image. In order to ensure that, I will not touch the LAST_FIT setting. But offered you, or anybody how needs to squeeze the last byte, a way to relocate the environment. Actually, it would be even OK for an external program to move the environment to 0x1063, but to have FreeCOM do this - I have to change too many stuff that must be changed later on again, which would mean to waste my time usefully spent for other stuff. BTW: I actually reworked to code to load the stub anywhere and, which in turn, loads the worker anywhere, too. Unfortunately I failed til today because of things the RTL relys on. That's why the current development branch and the main branch are way off. 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: FreeCOM environment
Hallo Arkady, actually many of your posts makes me to wonder puzzled what you really _mean_. This thread is one of them. On Sun, 27 Jun 2004, Arkady V.Belousov wrote: 26-éÀÎ-2004 20:35 [EMAIL PROTECTED] (FreeCOM) wrote to [EMAIL PROTECTED]: Yes, but who know, may be command.com not starts, but loads executable, corrects its environment, then starts it. So, I ask to be sure, because earlier was never think about this. This option I had never imagined to be the real meaning behind the question: I mean, how this options affects environment? Is it _limits_ size of internal buffer, which later used to make environment of new applications? Of course, but, for example, NDOS does itself permanent even without /p. BTW, I see no ways to differ INSTALL= and SHELL=. F Then please tell me, how 4dos is to detect that no other shell is active F currently, or, to put it into other words, that FreeCOM had been started F by the kernel's process-0 loader. Well, I made some tests. 1. MS-command.com never assumes itself primary without /P. 2. without SHELL=, MS-DOS starts command.com with /P option. 3. when SHELL= line wrong or shell exits, MS-DOS tries to automatically run (searched in root, \msdos and \dos directories) command.com with /p and says Bad or missing Command Interpreter only when it not finds it. The kernel also validates the found file that it matches the COMMAND.COM corresponding to the kernel running. (At least before MS DOS 7.) 4. when program runs through INSTALL= and SHELL= in MS-DOS, then parent PSP in env_seg (2C) and parent_PSP (16) contains both zero. So, with (1) FreeCOM currently is consistent and, probably, may not be changed. Other relate to FreeDOS kernel: (2) is same, (4) I plan to change, Please don't gallop so fast, how about to make some thinking first. So, when the environment segment of the primary shell is zero, how are the environment variables passed to it? Could we please discover this fist, before making any changes? 5. MS-command.com places its (resized) segment with environment right after itself (original segment preserved not freed), FreeCOM places environment into UMB, but, as I understand, with LAST_FIT. MS COMMAND is allocating more memory than necessary, when /E is present, then? 6. I don't know where MS-DOS preserves original environment from config.sys: I not found it in memory. I guess there is no need to preserve the original environment, is it? I think, (5) should be changed (LAST_FIT to BEST_FIT). Why? F BTW: Please refer to Undoc DOS's section about to find the master shell F environment, so we need not discuss stuff like: How refer it? By reading it. F + INT-2E, F + environment behind PSP, The only process, which environment is located after its PSP. F + first PSP. The first PSP in the memory chain. What there sayed about first PSP and what mean env behind PSP? I think, this should be implemented in any case. F When FreeCOM can determine, if it is or is not the primary shell, it F will be done. I mean not primarity, but too verbose startup screen with long help. Is the following re-wording correct: You wish that no FreeCOM is to issue so many stuff on startup? On Sun, 27 Jun 2004, Arkady V.Belousov wrote: 27-éÀÎ-2004 17:56 _te drivesnapshot.de (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: In this case memory will be allocated in the _best_ segment (shortest, which may fit) or after command.com (as with MS-DOS), if there is no fragmentation. te one more hint: command.com swaps itself into XMS And? command.com remain in memory stub, this stub my defragment its memory (when env segment is adjacent with command.com block). Or, in case of adjacent blocks, command.com may swap them (ie. place env segment before itself). Yes, this requires slightly more work in command.com, but this gives better memory distribution and less holes. Huh? Actually I think you contradict yourself, when the environment is placed far last there is _no_ fragmentation, no holes, and an optimal memory distribution most of the time. Of course, _if_ a block is available that has the exact size of the environment, this would be the best; but how probable is this situation? On Sun, 27 Jun 2004, Arkady V.Belousov wrote: - PSPinit(): DOS_PSP.ps_environ and ps_parent now zero. Has this something to do with the process 0? What impact does this change have for the first process? - kernel(): PATH=. now not placed into empty environment (because bug with copying empty env in task.c:ChildEnv() is fixed). Actually: The path had been set there because of an old bug of FreeCOM that choked on a non-existant PATH. Bye, -- Steffen Kaiser
MUX-AE (Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0)
On Mon, 24 May 2004, Eduardo Casino wrote: Hello Eduardo, Steffen Kaiser wrote: intercepted and executed by this hook. FreeCOM supports this mecanism, although in a slightly different (read incompatible) way than COMMAND.COM. what has to be changed in order to make FreeCOM compatible? I got your post, but I was a bit irritated, because ... FreeCOM blank-pads the command name to 11 chars, which is OK, but expects that the returned command is padded too, and displaces the start of the command line buffer by 11 characters, no matter what the actual length of the command is. This example will make it clearer: Imagine an installable command FOO with arg BAR that wants to execute SET BAR=ThisIsAnExample on return. If you type FOO BAR at the command prompt, FreeCOM will call function 2FAE1 with the command name in DS:SI and the command line in DS:BX in this way: [DS:SI]3 ; Command length [DS:SI+1] FOO ; Blank-padded to 11 chars [DS:BX]80h; Max length of cmd line (actual value may be different) [DS:BX+1] 15 ; Length of cmd line without final 0Dh [DS:BX+2] FOO BAR, 0Dh This is not how FreeCOM behaves: a) Both buffers [DS:SI] and [DS:BX] are 255 bytes in size. By default anyway. b) The command buffer is blank padded fully. (not just to 11 bytes) c) There are no spaces inserted into the argument. (behind FOO) The buffer is exactly as typed. Up to here, no problem, this is perfectly compatible, it just adds a few more spaces. As the installable command wants to execute the SET BAR thing on return, the standard way of doing it would be to update [DS:SI] and [DS:BX] in this way: [DS:SI]3, SET [DS:BX+1] 23, SET BAR=ThisIsAnExample, 0Dh The command interpreter should then compose the new command line with the command name followed by the command line, but skipping the first [DS:SI] characters. But FreeCOM assumes that the command name is blank-padded and ignores the command name length in [DS:SI], so it skips 11 characters of the command line and composes the following: SET sIsAnExample No, see http://cvs.sourceforge.net/viewcvs.py/freedos/freecom/lib/mux_ae.c?rev=1.3only_with_tag=MAINview=auto line #128 The PString is converted back to a CString starting at command + command[-1], hence, the end of the command itself. If there are spaces at the end, they are stripped, that's true. I think I got this blank padding stuff from reading the 4dos technote about quirks with the MUX-AE interface, I will check it. So the fix should be as easy as using the actual command name length in [DS:SI] when skipping the first characters in the command line. This will not break any command that relies in the curent behaviour. What an actual problem might become is the interpretation of RBIL's description of MUX-AE-01: Return: DS:SI buffer updated if length byte is nonzero, the following bytes contain the uppercase internal command to execute and the command line buffer contains the command's parameters (the first DS:[SI] bytes are ignored) FreeCOM uses the [DS:SI] on entry, but the setting on exit. To put in other words: FreeCOM remembers the starting pointer of the arguments and use this pointer without any adjustment when the extension returns, e.g.: The following scenario mapping SET -- DISP: In: CMD: \x3SET ARG: \xaSET 123456 ^ | argument pointer v Out: CMD: \x4DISP ARG: \xbDISP 123456 would be re-constructed when trying to run an external program (because DISP is no internal one) into the command line: DISPP 123456 I tried to ask MS DOS 6 about enlightment and discovered the very problem I had last time, too, I meddled with MUX-AE: Regardless of how I change either the command or argument buffer, DOS 6 always reacts with drive not ready. In fact, what you suggest by the standard way paragraphe above is that FreeCOM resets the argument pointer to argument[strlen(command)]. BTW: Do you have a sample program I can test the MUX-AE interface with, that actually does command re-writing? Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0
On Sat, 22 May 2004, Eduardo Casino Almao wrote: Aitor wrote: (b) If you check RBIL, Int 2F/AX=AE01h it says that APPEND hooks this intercepted and executed by this hook. FreeCOM supports this mecanism, although in a slightly different (read incompatible) way than COMMAND.COM. Hello Eduardo, what has to be changed in order to make FreeCOM compatible? Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bug/enhancement development questions
On Tue, 27 Apr 2004, Michael Devore wrote: Well, I can't really agree that a standard tab in a public SourceForge project is well hidden. Or that 24 requests in an obviously one-way The tracker had been disabled multiple times, in fact, I had disabled it myself at one time. I do not know, why it springs to life now and then. I always thought Bart or Tom did enabled it again. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Recent Bugzilla entries
On Mon, 19 Apr 2004, Bernd Blaauw wrote: Hello Bernd, when you have issues about FreeCOM, please, file them at bugzilla or mail them directly to me ([EMAIL PROTECTED]); I'm likely to miss them in huge mails compiled of many different topics. It is also helpful to mention something eye catching in the Subject line (FreeCOM or FreeDOS for instance) as I get approx. 100 mails of Spam, Virii or Virii notifications per day into each of my publically published mailboxes. Thanks, -- Steffen Kaiser --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel version
On Fri, 2 Apr 2004, Arkady V.Belousov wrote: Hello all, may we end this thread please like so? File a bug report in Bugzilla for FreeCOM, in which you (er, the unpersonal you) explain what information are to display _and_ how to acquire them. Would this be a good suggestion? Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Loading HIGH and the commandline in PSP
On Fri, 2 Apr 2004, Arkady V.Belousov wrote: ASM space was left in the commandline between the program name and the parameters. program/opt also remains no spaces before /opt in PSP. Yup. There are some other characters, that trigger the same behaviour, e.g. '=', '+'. That's because those characters are no valid filename characters, but accepted by MS COMMAND as token delimiters. Eg. you can place ',' and ';' almost anywhere where you can place a space. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] We're criminals (or at least GPL violators)
On Thu, 18 Mar 2004, Jim Hall wrote: Correct - if both modules (the apack stub and the original program) are part of the same exe, they are no longer aggregates. They have become a single executable. That is what Dave Turner (FSF) was trying to communicate. OK, I'm trying to hook into this endless thread once again. ZIP files are OK til now, I understand. So are any other archivers. The exepackers are'nt, because they are clamped together into the same and single executable. Guess one system that make _ZIP_ files themselves runnable; there was such thing in Win3.x (Poor man's online compression -- or something). Put a complete directory tree into a ZIP file, put an AUTORUN.INF in the topdir; add a hook into the shell or at kernel level, even DOS-4B-00 would do: That detects the archive by content (like File::Magic perl module or file Unix command; or first two bytes are PK), unpacks the archives, evaluates AUTORUN.INF and fires off the application, when the application terminates, well either discard the unpacked stuff or fresh/update the archive. And to have the files actually invoked, they get renamed into .EXE, too. Now you have the _same_ functionality as with runtime exe unpackers. Now: Zip files became invalid, too. What am I missing? Again: Who is able to mark us criminals for allowing exe compressors with our programs? As already said by several people, it is a form of interpretation; when we interprete this particular point in another way than others - what's the problem as long as we make it clear, esp. to new contributors. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't you think its better to use Msdos file names?
On Mon, 23 Feb 2004, Jim Hall wrote: I would prefer a C:\DOS directory with all exacutables inside. Users will feel more confortable with it ;-) My thought would be to put them inside C:\DOS as subdirs. Note that the install dir from the install program would need to use C:\DOS as the destdir, and the FreeDOS packages in the next distribution Actually, I would keep the BIN directory for the reasons you mentioned yourself (avoid conflicts installing two DOSes), but offer an options to move (or better hard-link ;-)) the BIN files into compatibly folder. 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] compiling Freedos
On Sun, 15 Feb 2004, Luchezar Georgiev wrote: I'm not sure if this has been answered before, but is it beter to compile the kernel freecom under borland c or djgpp? About FreeCOM: Let its author answer (he knows much better than me ;-) http://cvs.sourceforge.net/viewcvs.py/freedos/freecom/docs/compile.txt?rev=1.11only_with_tag=MAINview=auto -- 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Thu, 12 Feb 2004, Luchezar Georgiev wrote: I argued that coexistence of data, stub and and header is mere aggregation, just like combining files in a ZIP file or in a diskette. No, because you modify the GPL'ed Program prior distribution and not by-pack it. That's why I assume that an un-aPack'er would solve the problem - you then introduce aPack as an archiver, which is entitled to by unarchived by the user. 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Thu, 12 Feb 2004, Arkady V.Belousov wrote: 1. Strictly speaking BC/OW/MSC are not components of MS-DOS/Windows. I Yup. See tom's reply, too. 2. Again: exepackers are non-essential part of program, which adds stub for _existing and working_ code, so they can't be counted as modules, which program contains. This is unlike compilers, from which program contains (uses) RTL. Nope: GPL is generally considered a source-only license, but in fact it plainly says: The user you distribute a Program to must be able to reproduce it. point When the user needs a component to exepack it, in order to reproduce it, you MUST give the user an exepack'er. Again: As I wrote, it is not the stub that matters, but the fact that the exepacker modifies the Program, which is protected under GPL and GPL is the _only_ license that allows you to modify it. (Well, this sentence is more or less a quote from the GPLv2). Therefore, I assume that you have to make clear that the exepack'ed executable is not what is distributed to the user, but merely the delivery method. SK along with the virus effect clause 2b): SK b) You must cause any work that you distribute or publish, that in SK whole or in part contains or is derived from the Program or any SK part thereof, to be licensed as a whole at no charge to all third SK parties under the terms of this License. SK OK - _I_ personally understand an EXEPACKER as a kind of delivery, Exepacker, as standalone application, doesn't contain packed program. Stub (and archive file) doesn't contain program. I think, contain is a Wrong: The compressed result includes the GPL'ed Program in a modifed form. And this compressed result you are distributing to other people - and this is, where the GPL comes into play -- not before and not after. But later user passes Stacker volume (as file) with GPLed software inside. Should it also pass Stacker sources? As I also already wrote: GPL covers the ___distribution___, not the run of the Program. When the user chooses to put a GPL'ed Program onto a Stacker partition, it is the doing of the user, not of the distributor. If the distributor ships a Stacker'ed floppy, the matters differ. However, in this case even the FSF people would hopefully go an easy way to see the equalness to archives, like ZIP. 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom RTL sources
On Sun, 8 Feb 2004, Arkady V.Belousov wrote: Steffen, I found, that for RTL sources also need bld/lib_misc directory. May you prepare (and resend) it too? You will find it here: http://www2.inf.fh-bonn-rhein-sieg.de/~skaise2a/ska/ow/lib_misc.tar.bz2 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
