Re: [Freedos-devel] EMM386 with VCPI for testing

On Tue, 9 Mar 2004, Michael Devore wrote: What we need people to do is try EMM386 with any DOS extended program they may have available and see how well it works, or not, with interactive feedback either way. NOEMS and NOVCPI may be tried for the venturesome. Looks very promising! -- it

Re: [Freedos-devel] EMM386 with VCPI for testing

little high) but what is the real size of your BIOS? 256k that's very big -- it's probably not all visible then within DOS or everything between C000 and would be occupied with no rooms for UMBs. I should have said VGA BIOS. Please check: c:\debug -dc820:0 2 It reads FF FF FF

Re: [Freedos-devel] mKEYB 0.40

On Wed, 17 Mar 2004, Luchezar Georgiev wrote: On Wed, 17 Mar 2004 10:54:16 +0100, tom ehlert wrote: MKEYB 0.40 released website http://www.drivesnapshot.de/freedos/mkeyb.htm download http://www.drivesnapshot.de/freedos/mkeyb.zip changes: now uses APACK for 200 byte smaller

Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements

On Tue, 16 Mar 2004, Michael Devore wrote: Latest test version of EMM386 is at ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and EMMSRC.ZIP, as executable and source. These version corrects a problem with memory corruption in UMB's using VCPI, particularly notable with MCB

Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements

On Wed, 17 Mar 2004, Michael Devore wrote: I suppose I could break up the ZIP to floppy sized units, but I'm not real thrilled about trying it. I'd very much rather get the CD problem fixed. don't you have an old ISA network card you can put in the DOS machine? Then you could copy via a

Re: [Freedos-devel] mKEYB 0.40

On Thu, 18 Mar 2004, tom ehlert wrote: Neither are most compilers in use for FreeDOS (with the exception of watcom). LG ...and the Borland Museum compilers. AFAIR, the Borland museum compilers have a license similar to 'free for personal use. if you want to distribute compiled

Re: [Freedos-devel] mKEYB 0.40

On Thu, 18 Mar 2004, tom ehlert wrote: JH What about Pat Villani, who wrote prf.c and portab.h? this prf.c was written by the author of mkeyb, NOT pat villani. yes, prf.c was completely recoded in the early days I started maintaining the kernel. It's had some more updates from me in the kernel

Re: [Freedos-devel] UPX/UCL Hell

On Mon, 22 Mar 2004, Aitor Santamaría Merino wrote: I'd like to ask if someone has successfully compiled UPX/UCL. yes, but only on Linux. of those that I have corrected where due to things such as using SYSLIMITS.H not being present (it was SYSLIMIT.H, I guess that to follow DOS 8.3

Re: [Freedos-devel] UPX/UCL Hell

On Mon, 22 Mar 2004, tom ehlert wrote: ASM But anyway, and in order to avoid discrepancies, I'd like to use UPX/UCL ASM if available Seems GPL forces you to use second best choice (similar to choosing LINUX) Hmm. What's the best choice then? Solaris? FreeBSD? FreeDOS? For whom? :) But then

Re: [Freedos-devel] http://freedos.sourceforge.net/ (fwd)

On Tue, 23 Mar 2004, Jim Hall wrote: However, there's the issue of placement on the FreeDOS.org page. If I include these on the FreeDOS.org main page, I'm afraid the page will become *huge*. I can create a sample index page if you'd like to see it - actually, that's something I'd like to

Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)

On Thu, 25 Mar 2004, Luchezar Georgiev wrote: Thanks, Aitor! 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm As far as I know, APPEND is considered dangerous and incompatible. It had better stay missing. I think that SCANDISK is the most important missing program. it may

Re: [Freedos-devel] DOSFSCK 2G FAT32 bugs fixed!

On Wed, 31 Mar 2004, Luchezar Georgiev wrote: Oops! VolumeSeek() should be loff_t(loff_t offset) instead of off_t VolumeSeek(off_t offset)! But there must be yet another bug, because when I changed it, the bug was still there, although the code generated for VolumeSeek() became correct.

Re: [Freedos-devel] MUF (Microsoft's Undocumented Features)

On Thu, 1 Apr 2004, Luchezar Georgiev wrote: Things like that are Megalo$0ft's favourite trick! Here's what Pat Villani (the author of DOS/C on which our kernel is based) wrote about the Microsoft's love to undocumented features: there is constant debate over Microsoft's use of undocumented

Re: [Freedos-devel] Kernel version

On Fri, 2 Apr 2004, Arkady V.Belousov wrote: 1-áÐÒ-2004 20:55 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Adding *strings* just for information purposes in the precious resident LG space is a bad idea. Lucho, you blindly skip all my mentions about os_release.

Re: [Freedos-devel] Kernel version

On Fri, 2 Apr 2004, Arkady V.Belousov wrote: PS: Why you not answer for previous time? because at this point it seems to interest more people than just you. I just cannot answer every question, or I wouldn't have any social life left... PPS: Do you report bugs in RBIL (eg, D-216C00) to Ralf?

Re: [Freedos-devel] HIMEM64 testing info/requests

On Wed, 14 Apr 2004, tom ehlert wrote: Hello Michael, MD Additionally, if any port 92h related MD lockups happen, I'll move always-on to top the A20 test list, MD see if they go away. *** PRO 'always-on' *** I think always on here refers to machines that *boot* with A20 enabled. In that

[Freedos-devel] [announce] mem 1.5

MEM 1.5 is up for grabs at http://freedos.sf.net/mem/mem15.zip User visible changes are: * implemented mem /c at popular request * detect EMS memory if an EMS driver is present without a page frame (with FreeDOS EMM386 NOEMS), no longer reporing EMS Internal Error. * made output more MS

Re: [Freedos-devel] Recent Bugzilla entries

On Mon, 19 Apr 2004, Eric Auer wrote: Hi, as FreeDOS 2034 is out, does it make attempts to fix http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1745 ? renaming dir with trailing backslash makes it vanish which could be blamed on shell, kernel or both? [...] Eric, anyone can look through

Re: Re: [Freedos-devel] Recent Bugzilla entries

On Mon, 19 Apr 2004, Eric Auer wrote: Hi, I could check SOME of the problems, but I assume that you already KNOW which of them you have addressed and can give a comment about that question on the list first. Don't assume. Any comments will end up in Bugzilla itself. If there aren't any it

Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released

On Tue, 20 Apr 2004, Eric Auer wrote: This reminds me of the 386 question: How much bigger than the FAT16 kernel is the FAT32 kernel in RAM (low, umb, hma) and how much of this would be saved by optimizing for 386, experiences? Low: the drive data tables take 32 bytes more per drive (depends

Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel blockio.c,1.30,1.31 dosfns.c,1.61,1.62 int2f.asm,1.27,1.28 proto.h,1.61,1.62 task.c,1.41,1.42

On Tue, 20 Apr 2004, Arkady V.Belousov wrote: Isn't better for Watcom declare call_int2f through #pragma aux and do #define network_redirector call_int2f? Like this: %ifndef WATCOM global NETWORK_REDIRECTOR NETWORK_REDIRECTOR: ... ret 2 %endif

Re: [Freedos-devel] Re: Re: [Freedos-cvs] kernel/kernel

On Wed, 21 Apr 2004, Eric Auer wrote: 2034_16 and 2034_32 are both 8086 kernels. 2034_16 supports FAT12 and FAT16 2034_32 supports FAT12, FAT16 and FAT32 yes, it's here: http://sourceforge.net/project/shownotes.php?release_id=231835 also if you run the kernel it will say so in the beginning

Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released

On Sun, 25 Apr 2004, Aitor Santamaría Merino wrote: Bernd Blaauw escribió: right now on updated ODIN bootdisk the CPI files take almost 600KB (10 * 60KB), which is nearly half the disk! (and makes creating 720KB more difficult). Perhaps it's a question to check the CPI files, perhaps

Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.30,1.31 fatfs.c,1.66,1.67

On Sun, 9 May 2004, James Tabor wrote: Hi Bart! Bart Oldeman wrote: On Tue, 4 May 2004, Steve Nickolas - Using Windoze wrote: don't pay too much notice. This is just standard ritual. Scary thing is that it's being going on pretty much the same way for three years now. Time for me

Re: [Freedos-devel] EBDA

On Mon, 26 Apr 2004, tom ehlert wrote: BO MSDOS 7.10 does move the EBDA though. What MSDOS are we looking at now -- BO the FAT16 kernel says 5.0, and the FAT32 says 7.10 ? MSDOS 7.1 doesn't move it on F5 (or ctrl-F5 ? should this depend on the kernel version ?), but seems to move in himem.

Re: [Freedos-devel] Re: EBDA

On Tue, 27 Apr 2004, Eric Auer wrote: if you use SWITCHES=/E:value, what will happen if you select a value which is smaller than the EBDA? Here's an experiment: put switches=/e:800 in config.sys boot FreeDOS, then run MEM (1.6) with /f. and see for yourself. PS: I experienced EBDA sizes of

Re: [Freedos-devel] FreeDOS MODE: UPXing CPIs?

On Tue, 27 Apr 2004, Bernd Blaauw wrote: Eric Auer schreef: Hi, I found that a very small way to decompress CPI files would be using UPX to compress them and then patch the decompression process. Here is a sketch. I think this should work with both open source and NRV versions of UPX.

Re: [Freedos-devel] Bug/enhancement development questions

On Tue, 27 Apr 2004, Michael Devore wrote: While idly browsing FreeDOS sites, I see that Tracker in SourceForge has development requests going back to 2001. Several requests have since come to fruition without any notice or follow-ups there. Can (or should) the Tracker tab be turned off so

Re: [Freedos-devel] Edit 0.6 to 0.8

On Sat, 1 May 2004, BAHCL wrote: FreeDOS Edit takes more than 25 seconds to load a file with 800 lines (28k) in DOSEMU while M$ Edit is just a split of a second. This is a bit of a problem between DOSEMU and FD Edit: edit reads the file in 512-byte chunks and for every 512 bytes it checks the

Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS

On Sat, 1 May 2004, tom ehlert wrote: Problem: Intel PRO1000 network driver E1000.DOS does Int21/IoControl XYZ -- driver -- Int21/GetVect, Setvect this will reuse the same DOS stack and crash immediately. this issue might be also closed by making GetVect/SetVect true

Re: [Freedos-devel] Re: [Freedos-cvs] kernel/hdr device.h,1.21,1.22

On Sat, 29 May 2004, Arkady V.Belousov wrote: +++ ioctl.c 28 May 2004 12:57:41 - 1.30 @@ -59,13 +59,25 @@ + /* commonly used, shouldn't harm to do front up */ + if (al == 0x0C || al == 0x0D || al = 0x10) /* generic or query */ + { +CharReqHdr.r_cat = r-CH;

Re: [Freedos-devel] Re: [Freedos-cvs] kernel/hdr device.h,1.21,1.22

On Sat, 29 May 2004, Arkady V.Belousov wrote: No, all right: r_catfun is a xreg.x and r_cat is a xreg.h. Mistake is in my comment: I was should say difference is that r_cat comes _after_ r_fun to make consistent with CX. No, it can't be. See Table 02597 in RBIL at int2f/ax=0802,

Re: [Freedos-devel] command.com should be compilable from source

On Sun, 30 May 2004, tom ehlert wrote: well it is. even the published suppl source is. unfortunately, it's incomplete; the available suppl.lib contains functions where the source doesn't exist on the net. see bug #1794 it does exist, it's just not at the obvious place. As far as I know the

[Freedos-devel] [announce] kernel 2035 and bye

Hi, I've uploaded kernel 2035 to http://sourceforge.net/project/showfiles.php?group_id=5109 important fixes: Fix problems with USBASPI.SYS, DI1000DD.SYS Fixed invalid opcode with debug foo.txt, same with netware redirected logins. Don't move the EBDA by default. Use switches=/e:-1 if you want

Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console

Hi Steffen, 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

Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console

On Thu, 5 Aug 2004, Steffen Kaiser wrote: 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 ***). True. And now my opinion is that you can only assume that a VT100-style terminal is in place

Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console

Hi Tom, The only reliable way is to trap int10, write a character using int21 and see if it gets trapped. I've seen (N)ANSI.SYS implementations doing direct screen IO. You're quite right about that so this is not good. however: talking about CLS, why not 1'st) write ESC J (or

[Freedos-devel] HIMEM/EMM386

Tom has of course every reason to be pissed -- and in the latest emm386 he released there *is* an lsm file. The problem really stems from this I think: on www.freedos.org you can read: Michael Devore wrote: Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emm386.zip and

RE: [Freedos-devel] Extracting filesystem from freeDOS

On Thu, 21 Oct 2004, Daniel Gustafsson wrote: If we take a look at for example fat.h it uses some data structures like time but does not include the definitions for time (located in time.h). This is only one of many similar examples. How does this work. My compiler gets crazy and doesn't

Re: [Freedos-devel] Extracting filesystem from freeDOS

On Thu, 21 Oct 2004, tom ehlert wrote: pretty straight forward. * Port DosEmu from Linux to SUN SOLARIS this is (unfortunately) not so easy. For one thing DOSEMU relies on a vm86 system call, that is most likely not present on SPARC CPUs. Having the thing available as a network drive to the

Re: [Freedos-devel] New COUNTRY.SYS

On Thu, 4 Nov 2004, tom ehlert wrote: BTW: I'm not sure, if translated yes/no's make much sense at all, unless the program (int24 handler, command,...) is translated as well, and then the yes/no should be translated at that stage. [...] are you really sure you want to continue ? expecting

Re: [Freedos-devel] Compiling XMS-SWAP FreeCOM: almost ...

On Fri, 5 Nov 2004, Erwin Veermans wrote: I run build.bat and it halts almost immediately in .\suppl suppl.tgz: bad compression data yes, suppl.tgz is corrupted. I tried to tar xzvf it and that doesn't help either. The one in CVS is also corrupted, for one things it lacks the cvs kb tag. (I

Re: [Freedos-devel] Compiling XMS-SWAP FreeCOM: almost ...

On Sat, 6 Nov 2004, Bart Oldeman wrote: You're doing nothing wrong here as far as I can see. The source is too big now to fit in 64k. Large model is a work around but then you'd need a suppl_l.lib. The simplest workaround is to use CC = $(BINPATH)\TCC +$(CFG) -1 in config.mak. It makes

Re: [Freedos-devel] Compiling XMS-SWAP FreeCOM: almost ...

On Sat, 6 Nov 2004, Erwin Veermans wrote: You're doing nothing wrong here as far as I can see. The source is too big now to fit in 64k. Large model is a work around but then you'd need a suppl_l.lib. The simplest workaround is to use CC = $(BINPATH)\TCC +$(CFG) -1 in config.mak.

Re: [Freedos-devel] LH /L: someprog sets errorlevel 95 (on success)

Hi Tom, Ok - I'm pretty advanced with batch programming ;) here's a testcase for you. It should print hello. Freecom tries to cd to \hello. Bart @echo off if \%1 == \finish goto finish md cd echo echo hello cd\hello.bat echo cdtest finish cd\hello.bat cd\hello :finish del cd\hello.bat rd cd

Re: [Freedos-devel] LH /L: someprog sets errorlevel 95 (on success)

Hi Tom, however typing *manually* c:md cd c:echo echo hello cd\hello.bat c:cd\hello says 'the system cannot find the path specified' (\hello doesn't exist) Even stranger: typing cd\hello manually executes cd\hello.bat in MS command.com in FreeDOS but tries to cd to \hello in the same MS

Re: [Freedos-devel] Spammy viruses again...

Hi, if it helps anyone, here's my .procmailrc. Most of it is freedos nonsense filtering so it may actually help someone else here. Guess I need to add the MAILER-DAEMON from unc.edu as well now... Bart PATH=/bin:/usr/bin:/opt/local/bin MAILDIR=$HOME/mail #you'd better make sure it exists

Re: [Freedos-devel] re: 8086 xmsswap

On Tue, 12 Jul 2005, tom ehlert wrote: The XMS swap feature means: Copy most of FreeCOM to XMS while a program is running, and mark the memory as free. So FreeCOM LOOKS as if it would be only 3 kilobytes small in RAM. ... Having a version which is 8086 compatible but uses XMS Swap is a very

[Freedos-devel] copyrights (debug, comp, shsucdx, du, rerror)

Hi, as I'm dealing with the dosemu-freedos package I went through the list of copyrights and found some inconsistencies, and one clarification. I looked at the lsm's on http://freedos.sourceforge.net/cgi-bin/freedos-lsm.cgi?q=da=base etc. DEBUG Copying-policy Free / open source This

[Freedos-devel] packages for dosemu-freedos.

Hi, I'm looking again into upgrading the freedos package for dosemu, and use freedos 1.0 versions obviously. There is a nice list in ftp://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs but I'm only going to provide a small subset of that obviously. There are a few

Re: [Freedos-devel] [Freedos-cvs] kernel build.bat, 1.17, 1.18 buildall.bat, 1.6, 1.7 default.bat, 1.5, 1.6 filelist, 1.9, 1.10 makefile, 1.2, 1.3

On 10/31/06, Arkady V.Belousov [EMAIL PROTECTED] wrote: 31-Окт-2006 21:13 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO --- makefile18 Jun 2003 19:40:32 - 1.2 BO +++ makefile31 Oct 2006 21:13:02 - 1.3 BO +BINLIST1 = doc bin/kernel.sys bin

Re: [Freedos-devel] [Freedos-cvs] kernel build.bat, 1.17, 1.18 buildall.bat, 1.6, 1.7 default.bat, 1.5, 1.6 filelist, 1.9, 1.10 makefile, 1.2, 1.3

Looks like this change wasn't tested. It looks like Eric has magic powers to produce .zip files anyway! actually i do not use makefiles or batchfiles to create zip files. I wonder why those changes were made then. but i have a question about the cvs kernels: which branch are you

Re: [Freedos-devel] Insight Debugger

On 1/16/07, HCL BA [EMAIL PROTECTED] wrote: Thanks for the reply. Sorry for so late to follow up of my request. I should have made it clear that 1. the function keys works with DOSEMU Alt-F2 program reset, Alt-F5 user screen not work in X windows dosemu That's a common DOSEMU issue, nothing

Re: [Freedos-devel] Porting the FAT filesystem

On 4/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Please, correct me if I'm wrong: The starting point of my port should be the following set of functions: DosOpen(), DosClose(), DosRead, DosWrite,... And not the following set: dos_open(), dos_close(), dos_read, dos_write,... it's the

[Freedos-devel] Subversion instead of CVS?

Hi, would people here support a conversion of the FreeDOS CVS repository (kernel, freecom, install, mem) to Subversion (SVN)? One big plus is that CRLF problems would be mostly a thing of the past... what has happened a lot is that people check out CVS files on *nix, get LF line endings, correct

Re: [Freedos-devel] Subversion instead of CVS?

On 5/15/07, Aitor Santamaría [EMAIL PROTECTED] wrote: I'm just curious, as I have never used much of cvs and none of SVN (just MS Sourcesafe, pvcs and other commercial solutions), what would be the main advantages of SVN to CVS? Losing the line-ending annoyance for one... there are other

Re: [Freedos-devel] Subversion instead of CVS?

On 5/15/07, Jim Hall [EMAIL PROTECTED] wrote: I have no objection to SVN, but I haven't edited any sources in a while so maybe I'm not a good person to chime in. :-) If we do decide to migrate to Subversion, we should use the SVN repository on SourceForge (it's not activated yet, but it's

Re: [Freedos-devel] Subversion instead of CVS?

On 5/16/07, Jim Hall [EMAIL PROTECTED] wrote: I haven't seen any replies in this thread that argue Subversion is a bad idea, but let's make this a FINAL CALL before we go ahead. If no one speaks up by this time tomorrow, I think Bart gets the go-ahead to convert the FreeDOS CVS to Subversion

Re: [Freedos-devel] Porting the FAT filesystem (15)

On 5/29/07, Eric Auer [EMAIL PROTECTED] wrote: there are no toupper or similar function calls from dos_open() down to exechr(). This is because the case (in) sensitivity handling happens in DosOpenSft which in turn calls dos_open. So dos_open is one step too lowlevel to be case

Re: [Freedos-devel] Calling a software interrupt from hardware interrupt

On 6/13/07, Ladislav Lacina [EMAIL PROTECTED] wrote: Thank you, I'll try these possibilities. Support for 4th and 5th mouse button might be useful for someone but I don't have such mouse and don't remember if I have ever seen it . But very interresting would be some mouse protect mode

Re: [Freedos-devel] Distro, Kernel, Sys and Freecom flavours

On 8/27/07, Eric Auer [EMAIL PROTECTED] wrote: - SYS OpenWatcom farmalloc I see you worked around that now in SVN. But I wonder, since you use allocmem() already for Turbo C, why not also use _dos_allocmem() for OW, and just get rid of any farmalloc and inline assembly for this? It works the

Re: [Freedos-devel] Distro, Kernel, Sys and Freecom flavours

On 8/28/07, Eric Auer [EMAIL PROTECTED] wrote: Bart wrote: I see you worked around that now in SVN. But I wonder, since you use allocmem() already for Turbo C, why not also use _dos_allocmem() Feel free to add this, as long as it does actually work :-) It seems to work here now (SVN 1354).

Re: [Freedos-devel] A Poll of sorts

On 10/26/07, Johnson Lam [EMAIL PROTECTED] wrote: IMO, a smaller, solid and flexable kernel is highest priority. stability is most important of course. Kernel grows bigger each release ??? Where have you been? Any numbers to back it up? Or were you looking at the sizes of the source .zips,

Re: [Freedos-devel] A Poll of sorts

On 10/25/07, Pat Villani [EMAIL PROTECTED] wrote: Interestingly enough, a lot of responses seem not care about new development. Some even go as far as saying that whatever we have for dos extenders, memory managers, etc., is good enough. Does this mean that there is no new development

Re: [Freedos-devel] A Poll of sorts

On 10/29/07, Johnson Lam [EMAIL PROTECTED] wrote: On Mon, 29 Oct 2007 04:53:26 +, you wrote: Hi BAHCL, Recently, I compiled the 2036 kernel and copied to a hard disk but found it was a FAT16 kernel in a FAT32 partition, I ought to be more careful, but it is a pitfall. Can DOS in the

Re: [Freedos-devel] lbacache stack space too small

Hi Kevin, On Sun, Apr 06, 2008 at 01:34:11PM +0200, Tom Ehlert wrote: a) freedos *always* calls int13 on the block device stack with stack bottom DOS DS:aa0 and top DOS DS:ee2 (384 byte); DOS DS is usually 0x00D0 or 0x00d1 I don't understand: 0xee2 - 0xaa0 is 1090 bytes.

Re: [Freedos-devel] building freedos

2009/3/24 Japheth m...@japheth.de: I'm not a lawyer. But I used my brain and asked myself the following questions: 1. What is Open Watcom, is it a part of Sybase? 2. If OW is NOT a part of Sybase, is it a - juristic - person which probably could have a - disclosed - contract with Sybase

Re: [Freedos-devel] Closed: FIXED

2009/6/18 dos386 dos...@gmail.com I possibly know what the problem is (re-confirmed with FD 2038 and EDR 2009-03-28) : 2. UIP seems to do a very strange thing: it brews a temp file (AH=$5A, regrettably not visible above, but there was ONE call to it per attempt), throws away the handle

Re: [Freedos-devel] kernel SVN build availability

2009/6/23 Tom Ehlert t...@drivesnapshot.de one thing, though: there MUST be the possibility to keep the dates of the source files to the last change, not the last checkout. with all files having a date of 22.06.2008 the date is meaningless. Jeremy, did you try svn export to another

Re: [Freedos-devel] FreeDOS 1.1 (again)

On 5 May 2011 10:52, Rugxulo rugx...@gmail.com wrote: On Wed, May 4, 2011 at 3:03 PM, Alain Mouette ala...@pobox.com wrote: Em 04-05-2011 16:45, Bart Oldeman escreveu: I had to use some of the kernel build infrastructure to be able to still also build with Turbo C(++). Writing portable DOS

Re: [Freedos-devel] Severe bug in kernel 2040

On 19 May 2011 06:50, Rugxulo rugx...@gmail.com wrote: But honestly, this is a weird bug, surely LD itself (from GNU) didn't explicitly do this, did it? (I mean, why would it?) Mustn't it be a DJGPP libc bug? But 2.9.1 is old old old (latest is 2.21 !!) from May 1998, apparently, which

Re: [Freedos-devel] Severe bug in kernel 2040

Hi, I updated the source in SVN and the binary at http://dosemu.org/bart/kernel.sys with your bug (below) fixed. Thanks for the report. I made 4 adjustments: 1. If there is no FSINFO sector, don't use it. 2. Range check the FSINFO values to make sure they are usable (that fixes the bug -- the

Re: [Freedos-devel] Compiling with gcc

Hi, I finally uploaded a draft (not to be merged yet -- the patch needs to be split in nicer chunks!): https://github.com/bartoldeman/fdkernel/commits/ia16-elf-gcc-draft patch can be seen here: https://github.com/bartoldeman/fdkernel/commit/f873f2052e83fedadfd10b04d79d07246da30bbd Rugxulo wrote:

[Freedos-devel] FreeCOM 0.84-pre3 prerelease

Hi, as some of you know I spent some time fixing various bugs in FreeCOM. We've had the awkward situation of still having an old 2006 version in distributions but the newer versions had too many bugs (e.g. loadhigh, ren "myfile myfile.txt", strange dir output depending on the country setting).

Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease

Hi Matej, thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN. It doesn't happen with the GCC compiled version either. I'll need to debug this a bit. OW has heap after stack unlike the other compilers, which have stack after heap. Stack after heap allows a bit of flexibility as

Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease

down to heap I think the compiler's stack checking / malloc returning NULL should take care of that.. Bart On 5 February 2018 at 10:47, Tom Ehlert <t...@drivesnapshot.de> wrote: > Hallo Herr Bart Oldeman, > > am 5. Februar 2018 um 11:06 schrieben Sie: > >> Hi Matej, > >&g

Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease

Hi Matej, can you post your exact config.sys and which kernel.sys you are using? I cannot reproduce your issue with a plain FD 1.2 installation in QEMU with this: DOS=UMB,HIGH DEVICE=C:\FDOS\BIN\JEMMEX.EXE SHELLHIGH=C:\COMMANDW.COM DEVICEHIGH=c:\srdxms.sys where srdxms.sys comes from

[Freedos-devel] FreeCOM 0.84-pre4 prerelease

Hi, thanks everybody for the feedback. I now updated the prerelease to pre4 with just a few changes: * stabilized the ia16-elf-gcc version further * fixed "Out of memory" with the Open Watcom version * fixed build with Windows CMD (Tom Ehlert) * spelling fixes and Swedish translation updates

[Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hi, thanks again everybody for the feedback. I now updated the prerelease to pre5 with a few changes and bug fixes, most importantly: * Update translations (Serbian/Slovene/Turkish/French) * fixed: FOR %i IN (*.*) do @ECHO %i does not work * fixed: The shell doesn't display any error if exec

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

in the way and may be out of bounds some where. On Mon, 20 Aug 2018 at 22:23, Bart Oldeman wrote: > > This change seems to be the cause (which was motivated by the fact > that otherwise with large memory model regular malloc's would fail as > they bumped into the allocated memory block)

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

This change seems to be the cause (which was motivated by the fact that otherwise with large memory model regular malloc's would fail as they bumped into the allocated memory block) --- a/cmd/dir.c +++ b/cmd/dir.c @@ -1010,7 +1010,8 @@ static int dir_list(int pathlen error_out_of_memory();

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hi TK, > However, both the intr ( ) implementation in Open Watcom, and the intr ( > ) implementation in suppl/src/intr.asm used when compiling with > gcc-ia16, will _not_ try to load any flags --- including CF --- from > reg.x.flags, so int 0x21 basically gets called with CF in an undefined >

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello Tom, On Sun, 26 Aug 2018 at 13:03, Tom Ehlert wrote: > I think I found the cause for command crashing: > > the size to swap out, and back in, is only calculated once in >XMSinit() { >... >mcb = MK_SEG_PTR (struct MCB, SEG2MCB (_psp)); >xms_block_size = SwapTransientSize =

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hi Eric, On Thu, 16 Aug 2018 at 04:24, Eric Auer wrote: > Could you tell more about the comResFile > memory leak? Does it fix an old, elusive > bug which has been on the list repeatedly? no, it's not an old bug, it's related to getEnv("COMSPEC") using dynamic pointers (since pre3) and the

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hi Tom, > can we please have a new version number please. > > instead of >FreeCOM 0.84-pre5 prerelease beta 1 > > FreeCOM 0.85 prerelease That does not make much sense to me since 0.84 has not yet been released yet. there is no beta1 (not sure where you read that, if it's there by accident

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

I fixed this issue now. There were issues with #pragma aux for OW and for GCC inline asm. The si parameter for XMScopy was not passed correctly for OW (likewise for DS for GCC), which meant that most XMScopy calls failed. However it would work by accident because the strings usually simply stayed

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Even simpler: a:\system\sleep 1 dir /od/b the first command is just to trigger one xms swap, and then after swapping in "dir /od/b" (both flags are necessary) causes trouble. Bart -- Check out the vibrant tech

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Ok, I am getting a bit closer after pruning fdauto.bat as much as possible: this two-line fdauto.bat causes "String #" errors when typing dir in metados for the OW command.com: a:\system\shsurdrv /qq /d60M$SCRATCH,g set /e FINDDO=dir /od/s/a-d/b a:\stubs.zip looks like an issue with "set /e" so

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, > is there any reason why the source code version control system trashes > file modification dates? the underlying reason is to play well with "make" so that say if you check out a file as it was two years ago and then use "make", make will compile it because the timestamp of the file

Re: [Freedos-devel] FreeCOM 0.84-pre4 prerelease

Hi, On 26 February 2018 at 18:21, Rugxulo wrote: > There's another valid .BAT (P5.BAT) that says "Syntax error" and > hangs. I haven't looked into exactly why yet. > > So then I temporarily switched to the Watcom build, but when I type > "cls", it says this (and then prompts

Re: [Freedos-devel] Translations for FreeCOM 0.84-pre4

Hi, I'll have a look on that website and see which translations are more up to date, then replace/add them. Bart -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org!

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, > when I replace freecomW as compiled by Bart by a > watcom compiled by me, the bugs vanish. > compiled by wcc 1.9 > barts freecom has length 84756 > myfreecom has length 82758 (without UPX) > should this not be identical? yes they should be identical, as I also used wcc 1.9. I'll

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, interestingly picoc is still buggy after I disable XMSinit() and XMSexec() in the xms-swap build. This makes debugging a bit easier now that that code is eliminated. On Tue, 23 Oct 2018 at 19:12, Bart Oldeman wrote: > > Hi Tom, > > the big one is built with xms-swap, yours wi

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, the issue is that OW strtok() detects characters in the set using a bitmask and uses an 8 char lookup table called _Bits (__Bits in the mapfile) which normally has this 01 02 04 08 10 20 40 80 (in hex) A printf confirms that this table is overwritten, so there is a buffer overflow

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, strtok's source can be browsed here: http://perforce.openwatcom.org:4000/@md=d=//depot/openwatcom/bld/clib/string/c/=//depot/openwatcom/bld/clib/string/c/strtok.c=33595=sgp@//depot/openwatcom/bld/clib/string/c/strtok.c Bart ___ Freedos-devel

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, so in the end the issue is a stack overflow: filenames on the stack overflow into a const buffer used by strtok. I had raised it from 2K to 4K back in January but that is not enough. Since Blair Campbell's LFN work in 2006 cmd_rename() which calls fillFnam() together use at least 13

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, the big one is built with xms-swap, yours without. I get 82758 also without xms-swap. So it looks like something in the swap code is still buggy then ... Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net

[Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi, thanks again everybody for the feedback. I now updated the prerelease to pre6 with mostly bug fixes and one build system change, most importantly: * Enable reporting of directory sizes up to 2TB (with Tom Ehlert) * Enable cross-compilation from 64-bit Windows using Open Watcom * Fix swapping

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hi Tom, sbrk is a little deceiving here since it just administrates a high-water mark and does not allocate memory from DOS: old: https://github.com/tkchia/newlib-ia16/blob/e7c08882834a41d848698a19deae49089c2dab17/libgloss/ia16/dos-sbrk.c which only returned NULL if heap ptr went beyond 64K (the

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Tom, you are (in your words) 110% right. At the time I had fixed the stack offenders but got lost in debugging adapting your stack-checking patch to other compilers (it actually checks the heap too, if heap grows to stack). The OW version looked reasonably stable, the GCC version still ran into

  1   2   >