Re: [Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS

[Tom Ehlert]

> the FreeDOS kernel is seriously slower then MSDOS when doing
> larger copy/xcopy operations.

> the cause: the disk I/O code avoids transfers that cross a 64K
> boundary, and splits these transfers into 3 (smaller) transfers.

> this was needed for floppy controllers in the 1980's, but is certainly
> not necessary for harddisks after the IBM XT.


> just skip


>   /* avoid overflowing 64K DMA boundary */
> count = DMA_max_transfer(buffer, totaltodo);

> for harddisks, and everything should be *much* faster (at least on
> rotating media in a non-emulated machine)

investigating in this a bit more, the 64K boundary was/is a problem
with ISA DMA, used only for floppies (and sometimes serial/parallel
ports), but is no problem for UDMA.

skipping this test for drives with 0x80 set should be save, and result
in a significant speedup of large disk transfers.

Tom



___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Checking NUL directory/drive is broken in 2042

[Tom Ehlert]

   if exist K:\NUL echo K: is present

is broken in kernel 2042


the bug is caused by a change in TrueName(), where code was changed
from

  cdsEntry = get_cds(result);
  if (cdsEntry == NULL)
return DE_PATHNOTFND;


to

  dhp = IsDevice(src);

  cdsEntry = get_cds(result);
  if (cdsEntry == NULL)
  {
/* workaround for a device prefixed with invalid drive (e.g. "@:NUL") */
/* (MS-DOS always return drive P: for invalid drive. Why P:?) */
if (dhp)
{
  result = default_drive;
  cdsEntry = get_cds(result);
  if (cdsEntry == NULL)
return DE_PATHNOTFND;
}
else
  return DE_PATHNOTFND;
  }


now truename("e:\NUL") returns not 'path not found', but 'isDevice'


probably by fixing one bug, another bug was introduced.
Unfortunately I don't know what bug the changed is supposed to fix...

who introduced this change and why?

comments?

Tom



___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Checking NUL directory/drive is broken in 2042

[Tom Ehlert]

Hi,

> Was using FreeDOS 1.1 2040 kernel? previously and could check for
> drive or directory existence with the NUL device:


> If exist c:\nul echo C: exists
> If exist c:\mydir\nul echo C:\mydir exists


> This behavior is broken with 2042, no longer being able to identify if a 
> drive/dir exists anymore.

I tried to reproduce this here, and I think that it behaves exactly as
it should.

can you be more specific how it fails ?


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Can the Kernel start my program instead of command.com?

[Tom Ehlert]

>>From the point of view of protecting this system from counterfeiting &
> unauthorised access, is it possible to interrupt processing config.sys? I
> had read about pressing F5 to bypass config.sys and autoexec.bat. Also that
> this can be disabled in config.sys.

modify kernel.sys by using

 sys config kernel.sys SKIPCONFIGSECONDS=-1

to disable F5/F8 completely.

OTOH, removing command.com will also completely disable tinkering with
the system.

> Another thought I have - what would the behaviour of the kernel be if my
> program (as the command processor) does terminate? Does it reboot, restart
> the command processor, or just hang?

most likely just hang. test yourself.

Tom



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] BUG: problems with INSTALL=, reported by Bret Johnson

[Tom Ehlert]

the problem, brought up by Bret:

during config.sys processing,

INSTALL= \freedos\MEM.EXE /F

will report ~24 K used at 99f0:0

however the kernel will crash if memory below this is overwritten.

source for the bug:


CONFIG.C, DoInstall() sets up a memory arena, and releases memory
below the INIT CODE segment, based on the assumption that 'normal' code
is no longer needed. this is *almost* true.

unfortunately

   STATIC void kernel()
   {
 CommandTail Cmd;

 strcpy(master_env, "PATH=.");
 fmemcpy(MK_FP(DOS_PSP + 8, 0), master_env, sizeof(master_env));

 memset(Cmd.ctBuffer, 0, sizeof(Cmd.ctBuffer));
 strcpy(Cmd.ctBuffer, Config.cfgInitTail);



will use strcpy() and memset(), located at CS:11ee and freed by
DoInstall, and potentially overwritten.


probably the easiest solution: write some quick

   init_memcpy() ...

to be used at *this* location by Kernel().

I'm away for a week; will continue work when back.




Tom




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] [Freedos-user] INTERLINK

[Tom Ehlert]

Hi,

https://sourceforge.net/p/freedos/bugs/147/

located the bug in freedos kernel. this the first driver *at all* that
uses dos_alloc (int 21 ah=48)



INTERLNK.EXE does (pseudocode)


is running at

426:2951

   if (dos_version < 5)// try load high to UMB
  goto continue_load;

426:2965
   seg = dos_alloc(driversize);// driversize ~= 2f0 para

   JC continue_load

   //
   // move driver up to UMB
   // relocate interrupt vectors, driver list, ...

continue_load:


unfortunately  dos_alloc(driversize) succeeds, but returns 425 -
the very segment the driver is currently running at. OUCH!
MCB looks like

2D3:0  'M' -->
4d3:0  'Z'





2 problems:

the space for the driver is not allocated while the driver is loaded

INTERLNK does tries to get some UMB memory, but has not called
INT21 AH=58. why would MSDOS return MCB memory?


while this is a real bug, I'm not certain this should be fixed as
rethinking the driver load and memory allocation at init time is far
from trivial.

Tom



























am 5. Februar 2016 um 18:05 schrieben Sie:

> Have tried with latest* kernel, there is a fixed bug in int 25/26 that may 
> effect it.
>  You may want to try RIFS as well, it has source, but I don't
> recall if it used serial, parallel, or either but did work with
> FreeDOS kernel as well as it did with PCDOS.
>  * I'm releasing updated version this weekend if time permits after I commit 
> changes from git to svn.
>  On Feb 5, 2016 11:04 AM, "Tom Ehlert" <t...@drivesnapshot.de> wrote:

> Bret,
>  
 >> Eric/Tom:
>  
 >> I used to use INTERxxx a lot many years ago using the special
 >> parallel cables designed for that purpose (I think I still have a
 >> couple of those cables in my "spare cable box").  Parallel is MUCH
 >> faster than serial (null modem) cables.
>  I also used it *A LOT*. in times when there were no network cards a
>  commodity. (the times they are a changing ...)
>  
 >> I believe Eric is correct when he says INTERxxx is sector-based
 >> rather than file-based as Tom states.  I do know that the client
 >> (INTERLNK) must be capable of "understanding" the file system of the
 >> server (INTERSVR).  For example, if the client is MS-DOS 6.2 (which
 >> doesn't understand FAT32) and the server is MS-DOS 7.x (which does
 >> understand FAT32) and you're trying to access a FAT32 disk on the
 >> server, it doesn't work.  I know this for sure because I've tried
 >> it.  If INTERxxx was file-based, it wouldn't matter which version of
 >> FAT was on either computer (and could even work on non-FAT drives
 >> the server had mounted, like CD's and network drives).
>  
>  you are right, my memory was plain wrong on this.
>  
>  and - while debugging the crashing problem - I also saw that it
>  installs itself as handler for INT 25/26 'DOS DISK READ/WRITE'
>  
>  Tom
>  
>  
> 
> --
>  Site24x7 APM Insight: Get Deep Visibility into Application Performance
>  APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>  Monitor end-to-end web transactions and take corrective actions now
>  Troubleshoot faster and improve end-user experience. Signup Now!
>  http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>  ___
>  Freedos-user mailing list
>  freedos-u...@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/freedos-user
>  



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] FreeDOS and redirectors

[Tom Ehlert]

> I wanted to ask: to what degree does FreeDOS implement the redirector
> interface?  Are there any known incompatibilities?
it should right work.

all known redirectors

   CD/DVD drivers
   MS Lan Manager
   NTFSDOS
   NTFS4DOS
   VMSMOUNT (with source)

for DOS work without (known) problems

> This also requires that any protected mode memory manager (EMM386 etc)
> implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API.
VDS is supported.

Tom


--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] hmmmm

[Tom Ehlert]

 Sorry for the link I haven't used thus machine to send emails in a long
 time.  The antivirus tags it with it.  I had suspected that I wouldn't
 be able to kernel merge, but it's nice to have thoughts. The multiuser
 will have to wait whilst I wait on the response from Caldera,  They have
 an open source codebase that is not gpl compatible.

the Caldera DRDOS is not very open at all; they published the source
for the kernel exactly once, with no source release before or after.

 Maybe they would
 change the licensing or discuss possibilities since I asked.
extremely unlikely; other people tried this (~10 years ago)

 I could
 ask for the DOS 4.0 codebase instead.  Seems reasonable.

good luck, but don't hold your breath

Tom


--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] EXT3 support

[Tom Ehlert]

 I am interested in writing a new driver, one that would allow you to
 boot and run dos on a EXT3 partition.

booting from EXT3 would require to make EXT3 part of the kernel.
not going to happen.

otoh there is virtually no disadvantage to have a loadable TSR to make
EXT3 available as a redirector.

 In your other message you said
 that ETX3 was a multithreaded fs.  In that case it would be wiser to
 first add multithreaded support to the FreeDOS kernel.  It will be
 hard, but well worth the time I believe.

don't wait for multithreading support from kernel.

in the good old times, when DOS was still active, disk caching
software implemented 'multithreading' by chaining into
TIMER and IDLE interrupts.

just because so far no FreeDOS disk cache supports write caching
doesn't mean it doesn't exist


Tom


--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Questions about Kernel editions

[Tom Ehlert]

 I am an E.E./Comp. Sci. student, but I want to contribute to the FreeDOS
 Kernel.  Would it be fine if I began setting up a multiuser/multitasking
 system like Digital Research's DOS 5, and begin the work to get Forth 
 into the kernel?

the kernel is definitively not the right place
to integrate Forth into, be it multiuser or not.

there is zero disadvantage to have FORTH.EXE doing all the magic

of course feel free to experiment (thats one of the reasons open
source exists), but the the probablity that this would ever get
integrated into the FreeDOS kernel has 8 leading zero's

 This email has been checked for viruses by Avast antivirus software.
 https://www.avast.com/antivirus
whenever I read emails like this, I wonder what prevents a virus from
adding such a line to its malicious postings ;)



Tom


--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

[Tom Ehlert]

 I'm not sure how you can say the FreeDOS project isn't interested in a BC5
 kernel.
because I was around when the kernel was ported to MSVC, BC5, OW (in
that order)

 The BC5 makefiles I found in the kernel sources I didn't write.
  Bart last worked on them 9 years ago.
right. an since OW became an *free* option, MSVC and BC were dropped

Bit rotten for sure
the last time I checked bits don't rot

and OW became
 usable in that time.  So yes, priorities change, but I'm taking the posted
 FreeDOS Roadmap, as goals and stretch goals for the project.  I read
 (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit
  64-bit support, device driver imports, automated regression testing.
all great - and so far off reality that is isn't even funny.
is was never even discussed, let alone agreed upon.

 I've
 done a couple of simple tests and I am getting 32-bit register code from my
 copy of BC5.
of course this is a huge step towards 'built in USB, 64 bit, bla'

 The Roadmap is reason enough for me, personally, to continue
 to 'experiment' as you say.  There's no way of getting 32-bit real mode
 code from OW.
OW outputs enough 32-bit real mode code to get the job done.
is the BC5 code smaller/faster in a significant way ?


 Again, I'm not doing any porting.  And I do intend to work this issue.
  However, software development, like many human endeavors, is best done
 collaboratively  socially, IMO.  If someone in the last 9 years has
 compiled the kernel with BC5, they might have tips for me.  Heck, I
 remember when the kernel was TASM/BC only, and only a select few could
 afford to contribute.  I advocated back then (almost 15 years ago) for
 porting to open tools.  I'm glad the early FreeCOM/Kernel developers had
 made the effort to port to open tools.
it was a pleasure ;)


tom


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Tom Ehlert]

 Kernels with FAT32:

 086: 68358 bytes
 186: 67180 bytes (286 same)
 386: 66044 bytes
 486: 65948 bytes (586 and 686 same)



 It is interesting that even 186 instructions do make a
 quite big difference and that there is a difference at
 all between 386 and 486. With 186, you get pusha and
 popa, shift/rotate by fixed numbers of bits.
ENTER
LEAVE

 In the past, we compiled kernels for 8086, 186 and
 386 separately afair. I guess we got lazy and have
 dropped 186 because very few users have 186/286 as
 their CPU? They either have modern or REALLY old.
this is not about 'lazy'
it's easier for the user to select between 2 choices then between
4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.

there's not much use for a 186 kernel as NOBODY has 186/286 machines
these days,

 Also, we keep offering 8086 compiles for the sake
 of good old times and for people with emulators.



 The 386 optimization is useful and we already used
 it: Having 32 bit computations helps even for DOS.
 There are also some new bit string opcodes, SETCC
 (conditional set a byte)
nothing of this is used by the compiler

  JCXZ
was always supported

  and near conditional
 jumps and loops that are supported starting at 386.
*far* conditional jumps started with 386.

however what *IS* used by wcc is
   the additional FS and GS register
some (few)
 push DWORD constant

what would be useful, but is not used by WCC
 dword arithmetic
filesystem code uses long variables everywhere



 Your 486 to 686 kernels are the same size and 486s
 only XADD and BSWAP (and CMPXCHG). It is impressive
 that those actually make any (100 byte) difference!

strange enough, compiling here with -3 and -6 makes exactly no
difference. using watcom 1.9

could you post the compiled files, or even

  for %i in (*.obj) do wdis -l -a -s %i

for -3 and -6 and show us the differences ?


 Maybe your compiles assume that 486 does and 386
 does not have FPU? That would not be very accurate.
pointless as the kernel doesn't use any FPU code



 As with 286, the news in 586 is mostly protected
 mode related (simply speaking). Neither CMPXCHG8B
 nor the time stamp counter nor CPUID bothers DOS.


 The main news in 686 would be CMOV, a conditional
 MOV, but looking only at kernel sizes, it is likely
 that the compiler just does not use CMOV for 686.
 It is odd to get exactly the same size otherwise.
it doesn't use cmov


 For even newer CPU, you could use FPU and vector
 (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+,
 SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions
 but it is highly unlikely that those make any DOS
 difference. At most they could speed up memmove.
as the kernel doesn't much memcpy/memmove, you can't accelerate it
by any significant amount.otherwise we *would* have
  rep movsD

tom


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Tom Ehlert]

 What's the difference between wcc  wcc386?
code generation for 16 bit (DOS) or 32 bit (windows)

  Does wcc386 generate code that could be used in the kernel?
no

  Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
 in the kernel now and possibly the string functions.  But just an idea
 right now.
the kernel doesn't copy (much). nothing to be gained.

tom


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Kernel 2041 and Singlestepping the FDCONFIG.SYS.

[Tom Ehlert]

 I use the Kernel 2041 and found follow strange:

 If I press the F8 key for singlestepping and then the ESC key to skip a 
 command, the
 singlestepping-process of the FDCONFIG.SYS is skipped.
I implemented it this way because AFAICT MSDOS 6.2 behaves this way

 Under MS-DOS the ESC key skips only the current command and
 doesn't skip the singlestepping-process.
I may be wrong (it's a lonnng time ago), but I'm fairly sure that ESC finishes
config.sys single stepping for MSDOS 6.2

 Under the commando-processor (I use the FreeCOM) the ESC key
 skips only the current command, too.
that's a completely different thing

 I think to skip the singlestepping-process is a good thing, but its better to 
 do this with another
 key, like the SPACE key.
better: use the same key that MSDOS uses. what is the MSDOS key for
that ?

Tom


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)

[Tom Ehlert]

 Dear PerditionC,

    UBYTE DiskTransferBuffer[MAX_SEC_SIZE];

 wastes 3,5 KB low memory for *everybody*, not only when it's needed.
 regarding how much time we have spend until we had 64 byte free
 I think this is a bad idea


 please see my previous messages, I know exactly how much space is
 wasted and clearly stated this along with statement 512 will be
 default (and was already changed to such earlier)


 I also think that these experiments should NOT be in the stable
 branch.

 fork it, and make another 'unstable' branch if you want to experiment,
 but don't experiment with code that is supposed to be stable.

 Regards, Tom


 These are not experiments,
these are - in the current state - even useless experiments.

 this is me working to improve compatibility
 with MSDOS and existing though rare disks.

a) the only problematic disks have a 4K sectors. your fix doesn't work
with them.

b) these disks don't exist, as there is currently no USB stack that
supports 4K sectors

I don't mind if you work on an unstable branch, or on your own local
copy of the freedos kernel.

however generating AGAIN an unstable kernel 2041 is a real bad idea.

and tagging current state (after the questionable 1705) '2041' without
further discussion is shit.

Tom


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)

[Tom Ehlert]

Dear PerditionC,

UBYTE DiskTransferBuffer[MAX_SEC_SIZE];

wastes 3,5 KB low memory for *everybody*, not only when it's needed.
regarding how much time we have spend until we had 64 byte free
I think this is a bad idea

I also think that these experiments should NOT be in the stable
branch.

fork it, and make another 'unstable' branch if you want to experiment,
but don't experiment with code that is supposed to be stable.

Regards, Tom


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] USB-HDD booting and LBA-to-CHS conversion

[Tom Ehlert]

Hi Ranieri,

try

   SYS CONFIG KERNEL.SYS FORCELBA=1

after that
   SYS CONFIG KERNEL.SYS
to list current option

this will force the freedos kernel.sys to always use LBA
and ignore CHS completely.

Tom





am 7. Juli 2011 um 15:41 schrieben Sie:

 I'm really sorry, I admit my description was quite confusing. All of
 this is not exactly a problem to me, I could just format the pendrive
 with the desktop BIOS geometry 974/128/63 and be done with it. I am
 just being stubborn, trying to understand if there is a technical
 reason that FreeDOS refuses this convoluted setup, while the other
 loaders accept it, even MS-DOS. The following is not in chronological
 order.

 I have created a tiny 8 MB partition in the end of the desktop's hard
 disk. I can boot FreeDOS from there and I also have copied Grub4dos
 files to this partition.

 My pendrive has syslinux in the partition boot sector. I have copied
 FreeDOS files to its root and tried to chainload into it. Only on the
 notebook everything works fine, because it sees the same geometry as
 in the MBR. On the desktop syslinux boots, I can chainload FreeDOS
 kernel, there is the expected WARNING about geometry, but COMMAND.COM
 cannot be found on the pendrive partition. I must point it to the copy
 of COMMAND.COM on the hard drive partition.

 When I load FreeDOS from the hard drive, the pendrive partition gets a
 drive letter but I cannot list its contents correctly. From here I can
 run Grub4dos on the hard disk, then in its command line I can list the
 contents of the pendrive. I can also:
 - chainload the pendrive boot sector to get syslinux boot prompt. Then
 I use the chain.c32 module to
 - load FreeDOS from the pendrive
 - or chainload back into the hard drive partition.
   Except for swapped partition letters and drive numbers, it is the
 same as booting from the pendrive.
 - memory-map a floppy image with FreeDOS. Same thing, pendrive inaccessible.
 - memory-map a MS-DOS 7.1 floppy image. It can see the pendrive correctly.

 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Kernel 2040 released

[Tom Ehlert]

 More tests: http://jafile.com/uploads/dos386/perftest.txt
 unless dos386 describes what program(s) he used on what hardware
 to produce these results, the data are useless :(

 ...you can try first writing some dummy data at where the file
 will end, then close it and re-open (without truncate of course)
 and do the actual copy. That should bundle the FAT updates and
 increase performance significantly :-)
 just did exactly this (for command.com) COPY.
 unfortunately performance remains the same.

 for a single drive (that is able to read ~43 MB/sec), using
 a copy buffer of 60K (Freecom default), copy performs
 roughly identical, even if the file is pre-created.

 Please explain. You compiled a modified version of the built-in
 COPY command of command.com?
I inserted

static int BIGcopy(FILE *fout, FILE *fin)
{
   ...
startTime = *(unsigned far *)MK_FP(0x40,0x6c);

 /* allocate destination file at start
a) might make copy faster because fat entries
   can be allocated once
b) if destination is full no need to copy
   many megabyte
 */
   
currentPos = lseek(fdout, 0, SEEK_CUR);


if (currentPos == -1l)
{

// can't seek
dprintf((can't seek errno %d\n,errno);)
}  
else {  
if ( currentPos  0xl - toCopy) // currentPos + 
toCopy  0xl   
{   // outfile 
too large  (  4GB )
retval = 2;
goto _exit;
}

dprintf((change size %lu\n,currentPos + toCopy);)

if (lseek(fdout, currentPos + toCopy-1,SEEK_SET) == currentPos + 
toCopy - 1)
{
if(DOSwrite(fdout,  , 1) != 1) 
{
retval = 2;
goto _exit;
}
}   

lseek(fdout, currentPos, SEEK_SET);
}
// end of preallocation code


while((rd = DOSread(fdin, buffer, size)) != 0) {


into copy. c


 My suggestion was to pre-grow the
 file, not only pre-create it. Something like, ca 2 GB example:
I would prefer code to suggestions.
use your keyboard to write code, not emails ;)

Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Kernel 2040 released

[Tom Ehlert]

 More tests: http://jafile.com/uploads/dos386/perftest.txt
unless dos386 describes what program(s) he used on what hardware
to produce these results, the data are useless :(


 ...you can try first writing some dummy data at where the file
 will end, then close it and re-open (without truncate of course)
 and do the actual copy. That should bundle the FAT updates and
 increase performance significantly :-)
just did exactly this (for command.com) COPY.
unfortunately performance remains the same.

for a single drive (that is able to read ~43 MB/sec), using
a copy buffer of 60K (Freecom default), copy performs
roughly identical, even if the filr is pre-created.

Tom



--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Kernel working, not SYS

[Tom Ehlert]

Hallo Herr Ibidem,

am 1. April 2011 um 07:56 schrieben Sie:

 I tried building svn revision 1560 with Turbo C 2 and a 16-bit nasm
 0.9x (FAT32/186).  It started building, but then when build.bat hit
 SYS, I got this:

 Error sys.c 629: Expression syntax in function initOptions

 I REM'd out SYS (I have a working install and grub4dos), built the
 kernel, rebooted, loaded the kernel via grub4dos, and ran a few tests:
 SELFOWNT.COM (succeeds, with both messages).
 No significant regressions in functionality (VDE/TC/TCC/EDIT/Arachne
 work).
 HX untested.

 SHARE still compiles fine.
 The relevant lines in sys.c (starting at 629):

   if (!argv[drivearg][1] || (argv[drivearg][1]==':'
 !argv[drivearg][2]))
 // if 1st arg drive 
 {
 if (!argv[argno][1] || (argv[argno][1]==':'
  !argv[argno][2])) // if 2nd arg drive {

most likely
   !argv[argno][2])) // if 2nd arg drive
{


Tom


--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Boot sector LBA detection error

[Tom Ehlert]

of course you are right. but maybe you are missing the point why the
original author (m2) wrote it exactly as it is: to save precious 2 bytes in
the boot sector code

Tom



am 6. Dezember 2009 um 00:32 schrieben Sie:

 Hi,

 the LBA detection of the FAT12/FAT16 boot sectors (both for the FreeDOS
 and OEM kernels) could misdetect that a BIOS does support LBA if it
 doesn't really. This is the used code (after calling Int13.41 for the boot
 unit):

 shr cx, 1
 ; CX must have 1 bit set
 sbb bx, 0aa55h - 1
 ; tests for carry (from shr) too!
 jne read_normal_BIOS

 This test succeeds if (cx1)  (bx==AA55h) as intended but also succeeds
 if (!(cx1))  (bx==AA54h). This is a highly unlikely case but  
 nonetheless an error which should be corrected. Example:

 sub bx, 0AA55h
 jne read_normal_BIOS
 shr cx, 1
 jnc read_normal_BIOS

 Note that the code after this expects bx to be zero, so sub must be used
 here instead of cmp. I exchanged the order of the test for cx bit 0 (disk
 access support) and the correct signature in bx since it's easier to  
 understand the code this way. (It would work the other way around as well.)

 Regards,
 Christian



--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] new kernel released

[Tom Ehlert]

 b) why there isn't a 386-fat32 binary available (hardly anyone even
 knows where he might see a real 8086 machine), and the 386 resident code is
 ~1,5 KB smaller

 Point out the file(s) that were missed and I'll do an update.

IMO the most useful kernel configuratiion is FAT32, compiled for 386
this is missing

Tom


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] new kernel released

[Tom Ehlert]

The kernel developers have just finished up 2039 for release a
few days ago (mostly bugfixes), so you can download it at ibiblio (
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2039/
or at sourceforge (
http://sourceforge.net/projects/freedos )


just wondering, why

a) this wasn't advertised on this list and

b) why there isn't a 386-fat32 binary available (hardly anyone even
knows where he might see a real 8086 machine), and the 386 resident code is
~1,5 KB smaller

Tom



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Potential issues with FAR printf

[Tom Ehlert]

 The FAR printf is probably good for 16-bit builds with DEBUG defined.
 However, there are at least two potential issues (NOT YET VERIFIED).
 1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past
 4GB.  I don't know how the compilers treat FAR in these builds.
exactly as the 16 bit builds. this is REAL mode.

Tom


--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] kernel 2038 discussion stuck? history.txt changes

[Tom Ehlert]

 * Windows 3.1x support
seriously: is ANYBODY using Windows 3.x ?

IMHO Windows 3.x is 100% obsolete, so why would anybody want windows
3.x support ?

  WfW support in stable, these might be handy.

 Windows for Workgroups , which is a flavor of Microsoft Windows 3.11
WfW support will probably never come; WfW was tighly coupled to the
kernel (at least according to Schulman et. al., WfW is MUCH more then
just a flavour of Windows 3.11)


 And SHSUCDX with UDF support does seem higher priority.
 UDF-CDEX would be separate from kernel development
 What does UDF support do? Enable copying video DVD? or enable packetwriting?
being able to read UDF formatted DVD's, in particular all packet
writing DVD software

Tom


--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Hello again

[Tom Ehlert]

 It won't help FreeDOS of course because it still uses fnodes for these
 things instead of SFTs.

 Those are ancient relics that should be done away with.  There is no
 need for them anymore.  I'd like to put that high on the priority list
 for kernel development.

in theory you are right. in praxis fnodes are everywhere throughout
the file system (as you probably know), and there's a reason we left
them in the kernel the last few years. it's probably fairly easy
to convert a stable kernel into unstable by trying to convert this.

not that I wouldn't like to get rid of the fnodes (it would be
a very good thing), but it's probably a non-trivial amount of work
(and risk) involved with that. dont start it if you are not prepared
to finish it.

Tom



--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] state of kernel 2038

[Tom Ehlert]

 - int 21.1c should report invalid drives via AL (keep other regs?)
   News here: DR-DOS modifies BX/CX/DX but not DS for inv drives.

  /* Get Drive Data   */
case 0x1c:
  {
BYTE FAR *p;

if (p = FatGetDrvData(lr.DL, lr.AL, lr.CX, lr.DX) != NULL)
   {
   lr.DS = FP_SEG(p);
   lr.BX = FP_OFF(p);
   }
else
   lr.AL = 0xff;
  }
  break;


should get the job done

 Unfortunately I do not know to what value DR DOS sets BX/CX/DX,
 only got the information that they looked kind of random...

MS-DOS is the king, and it lets all registers unchanged. more a DR-DOS
bug then anything else

 In any case AL has to be set to -1 to flag invalid drives :-)
right.



 - CHS calculations are off by 1 and overflowing (thanks Rayer)
   If your BIOS has no LBA, this was probably a real pain for you.
 
 any details about this ? like the original email ('thanks Rayer' is
 not enough of a description)

 The discussion is spread over mail and chat,

but this is certainly in the kernel mailing list, isn't it ?



 - the BSS_INIT macro is bogus (thanks Rayer)
 any details about this ? like the original email ('thanks Rayer' is
 not enough of a description)

 Here is the relevant part of RayeR's kernel:

 diff -bur freedos/kernel/init-mod.h rayer/kernel/init-mod.h
 --- freedos/kernel/init-mod.h   2007-09-07 14:32:05.0 +0200
 +++ rayer/kernel/init-mod.h 2008-11-30 20:55:58.0 +0100
 @@ -32,8 +32,9 @@

 These guys are marked BSS_INIT to mark that they really should be BSS
 but can't be because of MS
 +   Seems to be needed also for Watcom C 11.x
  */
 -#ifdef _MSC_VER
 +#if ((defined _MSC_VER) || (defined __WATCOMC__))
  #define BSS_INIT(x) = x
  #else
  #define BSS_INIT(x)

 I personally would suggest to always have BSS_INIT(x) = x and
 not only for certain compilers. After all, the kernel is not
 a normal program so compiler-specific BSS clearing code is
 usually not triggered...

 Thanks for commenting :-)

some comment is necessary; introduction into the crazy memory model ;)

it shouldn't matter if

   int SomeVariable;
or
   int SomeVariable = 0;

is declared. in the former case it is put into the BSS segment, and
initialized by the runtime libray. As we don't have the normal runtime
library, we do it in main.c
 /* clear the Init BSS area (what normally the RTL does */
 memset(_ib_start, 0, _ib_end - _ib_start);

(I verified that this at least seems to do something reasonable)

in the latter case it is put into the DATA segment, and initialized
with static data.

in both cases the variable ends up as 0

if this makes any difference, either
  the memset() memset above doesn't work
or
  the error relates to the actual placement of the variable in the
  DATA segment. usually an overwriting problem or similar.

good luck hunting if it's the latter


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Suggestion: Int 0x21, AX=0x7305, CX=0xFFFF handler

[Tom Ehlert]

Hi Eric,

how about compiling this for Christian ?
not everybody likes to download watcom, find out how to get kernel
sources compiled ...

and after he verified this private version, may be even put it on
ibiblio to be used by others ?

Tom




-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] roadmap for freedos kernel 2038

[Tom Ehlert]

 Hopefully someone can found the bug and fix it, my pathetic knowledge
 forbid me to help.

to fix any bug, it must be reproduced first.

As noone has ghost 5, 'the bug' can't be reproduced, and so can't be fixed.

end of story.

Tom


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] roadmap for freedos kernel 2038

[Tom Ehlert]

 1658 Ghost 5.1 fails: Needs somebody with Ghost 5.1 to fix

 Maybe true, but I do not have ANY version of Ghost to test :-(
 If a newer version of Ghost works, then we could indeed set
 the bug status to wontfix and mention that newer versions
 do work fine. Or we could lower bug priority to wish.

this bug was reported for 2.20.29 and 2.20.31

'stable' kernels started with 2.20.35, so reported bugs
should reference 2.20.35 at least

 1956 extending JFT (FILES=...) fails: Fixed in SVN :-)

that doesn't help if the famous FreeDOS 1.0 distributes something from
2006 :(

Tom


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] [Freedos-devel] flaws in user HMA memory allocation?

[Tom Ehlert]

 2. It is way slower in file copy/compare than other DOSes.
   (maybe we should make FAT and DIR data access smarter?)

depends on a couple of factors; the huge threat on 
http://www.drdosprojects.de/forum
about FreeDOS is slow was less then scientific

a) COPY
   FreeDOS allocates always the lowest unused cluster, even if
   the file should be enlarged by a large (  1 cluster) amount.
   this potentially searches a big part of the FAT to find place
   and writes the file fairly fragmented

   search for a bunch of clusters that are able to fit this request
   could accelerate this

   MSDOS 5 has been reported to allocate buffers on a 'round the disk'
   alghorithm (continue to search instead of restart from zero); has
   been reported to slow fragmentation
 
b) COMPARE
   if enough (small) files in large enough directories with enough
   directory depth are compared, it might matter that fastopen isn't
   implemented. Anybody ?


 I would like to comment on 1, please correct me if I am wrong...
 Experts should be Bart, Arkady, Lucho and Tom :-). 

 - you can say BUFFERS=-5 if you want 5 and not more than 5
   (as opposed to BUFFERS=5 which is at least 5 in FreeDOS)

 - HMA allocation (int 2f.4a0n) in FreeDOS should allow apps (such
   as Jack's drivers) to use the free HMA space beyond the user-
   selected BUFFERS. So even if we fill all space with extra buffers
   while the space is unused, we free that space for more useful
   things as soon as some app asks for it.

 Maybe there is a bug in int 2f.4a0n handling and/or config.c?

yes and no; see
http://www.bttr-software.de/forum/forum_entry.php?id=867


 - Arkady and Bart in 2004
 - Bart in 2001
 - Bart in 2004 (moved fnodes into HMA)
 - Lucho in 2004
 - Tom in 2001 (created inithma.c)
the HMA buffer logic came much later ;)



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886




-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel

[tom ehlert]

NOTE that both versions have a typo: ... the any key ...
 It's not a typo! Damnit! Still haven't found the any key?

see http://www.computergear.com/pressanykey4.html
and http://www.gadgetizer.com/2006/04/03/any-key-mistery-solved/

or just google for the any key ;)

Tom


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Tom's kernel changes vs. CVS

[tom ehlert]

Hi Bart,

nice to see you're still alive :)

 Tom, can you explain?

 1. config.c. Why use  instead of =? Is there a corner case with equality?

IMO = is correct (timeout 0 should exit immediately)


 2. initoem.c:
 + if (ramsize == peek(0, RAMSIZE))
 if (ramsize * 64 == ebdaseg  ramsize  640  peek(0, RAMSIZE) == ramsize)
the extra double check looks strange to me, why check twice?
 Something strange with short-circuit boolean evaluation?

looks strange, and I have no idea why exactly this is there.

But since I put it in after ke2035, I just assume I did that
intentionally. (this was changed on or before 11.07.2004)

I'd leave it under 'it doesn't hurt'

 3. int21/ax=3301. The comment and the code are out of sync.

 By falling
 through it reports the new state of break_ena in DL (not AL).
right

besides that, the code should do the same in both cases (DL should be
00 or 01)

I don't mind much

Tom

 Moreover, RBIL tells us that Novell DOS 7 report the *old* state
 (instead of the new state) in DL. What is the intended logic here?

 Thanks,
 Bart

 --- ke2035/kernel/config.c  2004-05-25 01:02:46.0 -0400
 +++ ke2035ctom/kernel/config.c  2007-05-14 12:43:46.0 -0400
 @@ -753,8 +753,8 @@
   if (timeout = 0) do
{

  r.a.x = 0x0100; /* are there keys available ? */

  init_call_intr(0x16, r);

 -if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u)

 +if ((unsigned)(GetBiosTime() - startTime)  timeout * 18u)

return 0x;

}

while (r.flags  FLG_ZERO);

 diff -urb ke2035/kernel/dsk.c ke2035ctom/kernel/dsk.c
 +++ ke2035ctom/kernel/initoem.c   2007-05-14 12:43:46.0 -0400
 @@ -58,7 +59,8 @@
unsigned ebdaseg = peek(0, EBDASEG);

unsigned ramsize = ram_top;



 +  if (ramsize == peek(0, RAMSIZE))

if (ramsize * 64 == ebdaseg  ramsize  640  peek(0, RAMSIZE) == 
 ramsize)

{

  unsigned ebdasz = peekb(ebdaseg, 0);

 diff -urb ke2035/kernel/inthndlr.c ke2035ctom/kernel/inthndlr.c
 --- ke2035/kernel/inthndlr.c2004-05-30 20:31:06.0 -0400
 +++ ke2035ctom/kernel/inthndlr.c2007-05-14 12:43:46.0 -0400
 @@ -78,17 +78,17 @@
  case 0x33:

switch (irp-AL)

{

 +  /* Set Ctrl-C flag; returns al = break_ena  */

 +case 0x01:

 +  break_ena = irp-DL  1;

 +  /* fall through */

 +

/* Get Ctrl-C flag  */

  case 0x00:

irp-DL = break_ena;

break;



 -  /* Set Ctrl-C flag  */

 -case 0x01:

 -  break_ena = irp-DL  1;

 -  break;

 -

  case 0x02: /* andrew schulman: get/set extended
 control break  */

{

  UBYTE tmp = break_ena;

 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel


Mit freundlichen Grüßen / Kind regards,
Tom Ehlert
+49-241-79886


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] FreeDOS MS DOS 3 last missing APIs, was: INT 21h, AX=43FFh

[tom ehlert]

 - int 2f.4a00.cx=0 the kernel has to call this before it displays
the Insert diskette for drive B: (or A:...) message, to let
Win3 and the like show a GUI dialog instead of the message, DOS 5.0

seems to have been lost; should be


STATIC WORD play_dj(ddt * pddt)
{
  /* play the DJ ... */
  if ((pddt-ddt_descflags  (DF_MULTLOG | DF_CURLOG)) == DF_MULTLOG)
  {
int i;
ddt *pddt2 = getddt(0);
for (i = 0; i  blk_dev.dh_name[0]; i++, pddt2++)
{
  if (pddt-ddt_driveno == pddt2-ddt_driveno 
  (pddt2-ddt_descflags  (DF_MULTLOG | DF_CURLOG)) ==
  (DF_MULTLOG | DF_CURLOG))
break;
}
if (i == blk_dev.dh_name[0])
{
  put_string(Error in the DJ mechanism!\n);   /* should not happen! */
}
else
{ 
/* according to RBIL (te 22 jul 04) */
  iregs r;
  
  r.a.x = 0x4a00;
  r.c.x = 0x;
  r.d.b.l = pddt-ddt_logdriveno;
  r.d.b.h = pddt2-ddt_logdriveno;
  
  intr(0x2f,r);
  
  if (r.c.x == 0x) 
{
/* someone else makes a nice dialog */
}
  else
{   
  template_string[DRIVE_POS] = 'A' + pddt2-ddt_logdriveno;
  put_string(template_string);
  put_string(Insert);
  template_string[DRIVE_POS] = 'A' + pddt-ddt_logdriveno;
  put_string(template_string + 6);
  put_string(Press the any key to continue ... \n);
  fl_readkey();
}  
  pddt2-ddt_descflags = ~DF_CURLOG;
  pddt-ddt_descflags |= DF_CURLOG;
  pokeb(0, 0x504, pddt-ddt_logdriveno);
}
return M_CHANGED;
  }
  return M_NOT_CHANGED;
}



-
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.phpp=sourceforgeCID=DEVDEV
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] please change the default freecom and increasethe kernel version

[tom ehlert]

Hello Bart,

 well, we have:
 kernel 2034, 2035 released by Bart
 kernel 2035A released by Jeremy
 kernel 2035B by Jeremy (2035A + stable features backported from 2035W)
 kernel 2035W by Jeremy, experimental/development line

 isn't there also still a kernel 2035-Tom somewhere (drivesnapshot.de)?
Yes.

 Or did 2035A supersede that as far as Tom is concerned?
No. there were some changes in ke2035-Tom (mailed to the list), which -
as fas as I know - went also in the stable branch.

Drive Snapshot relies on a stable kernel, so I use one
that I understand. At least I can't complain about possible bugs introduced
by some experimental feature ;)



Mit freundlichen Grüßen / Kind regards,
Tom Ehlert
+49-241-79886



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: reload partition table and reassign drive letters

[tom ehlert]

Hello Kenneth,

 The main issue with FreeCom would be the location of its resources
 changing.

under normal circumstances, FreeCom-xmsswap will have it's resources
loaded at startup and touch them never again.

Tom



---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: Analysis: Support for sector sizes != 512 bytes

[tom ehlert]

Hello Eric,

 While we are at it, I would suggest a new category not planned at all
 unless you tell us why it is useful or alternatively send us patches
 for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm

 Candidates are: drivparm / driver sys / 3rd floppy support (kernel, sys...),
 himem cpuclock and eisa options, graphics lcd option (for old CGA
 640x200 handhelds with widescreen display), emm386 Weitek FPU MMIO support...
 Let me know if I forgot something.

add sectorsize != 512


 PS: Eg. FASTOPEN can, imho, be useful, as scanning large directories
 causes big load for CPU and BUFFERS / cache which can be reduced by a
 specialized FASTOPEN directory entry cache. But thats just my 2 cents.

send us patches

tom



---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes

[tom ehlert]

Hello Eric,

 Comments about useful sector sizes would be welcome:
 Smaller (64, 128, 256), normal 512, Bigger (1024, 2048, others).

512.

 Thanks for your comments! Trying to wake up the kernel list a bit :-)).

add code to support dynamic disks.

Tom




---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] freedos

[tom ehlert]

Hello Geraldo,

 is possible to implement a virtualfilesystem layer on
 freedos kernel?
it has already: the network redirector interface.

 what do you think about create a hardware abstraction layer
 on freedos kernel?
 it is interesting to make freedos portable to others
 architectures
it has already: it's called BIOS ;)

tom



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel entry.asm,1.27.2.1,1.27.2.2

[tom ehlert]

Hello Alain,



Tuesday, January 11, 2005, 1:24:48 PM, you wrote:



 Arkady V.Belousov escreveu:
 Hi!
 
 4--2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
 [EMAIL PROTECTED]:
 
 
Fix divide error message text
+++ entry.asm 4 Jan 2005 19:05:08 -   1.27.2.2
-; print a message 'Interrupt divide by zero'
+; print a message 'Interrupt divide error'
 
 
  This is not fix, this is change - though division by zero interrupt
 INT0 hapens not only in case of real division by zero, but this (Divide by
 Zero) is a standard name. On the other side, Interrupt divide error I
 read as error in dividing the interrupt, so, if you wish to give more
 meaningful name, there should be something like Interrupt: division error.
 
 I agree :)

I disagree :(

tom




---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13

[tom ehlert]

Hello Eric,

 Hi guys, interesting anecdote from Pat, but:

yes, it was interesting to see Pat watching this list at all.
and while I agree completely with what he wrote, IMO he slightly
missed the point (and you -eric- miss it completely)

 The whole point is that if you remove the break; completely, then
 somebody who later reads or changes the code might be mislead into
 thinking that the code SHOULD fall through ...

the whole point is that in a shared programming effort (as the freedos
kernel still should be) it's a waste of resources to change ANYTHING
without a certain payback.
in this case, removing 'break;' may have saved 5 bytes in the early
90ties, but is irrelevant (or even contraproductive) with optimizing
compilers, and leads only to such irrelevant 'why was this changed'
threads.

even if this WOULD save 3,5, or even 10 byte: it's completly
irrelevant. the kernel has more then enough space in HMA, = 40 buffers
ARE enough, and fighting lengthy email threads to free possibly
another 512 byte (with exactly zero performance increase) is simply
a waste of developers time, ethernet and my barins bandwidth.
Besides that, this byte fiddeling attitude is the
IMO the reason for the developement kernels name - 'unstable'.

tom












 after the return_user,
 or that it would be OKAY to fall through - in both cases, he will
 either not UNDERSTAND the code properly or will even add BUGS by
 erroneously adding the possibility of returning to the caller to
 return_user().

 So: OKAY, remove break; if you want, BUT add a comment instead of the
 break;, to let people know that return_user() never returns. You should
 even add such a comment to return_user() itself actually.

 By the way, you probably save even more bytes - and a bit of stack
 space - by using an evil GOTO for the return_user(), unless it already
 is an inlined macro or similar already anyway.

 OLD: break;
 BAD: (nothing)
 BETTER: /* return_user never returns, no break needed */
 EVIL: use goto instead of call for return_user ;-).

 Eric

 PS: Which kernels contain the DOSLFN compatibility patch (improved
 xBPB/DPB initialization and set extended error code implemented),
 did somebody contact GRUB people about 0.0.35 vs. 1.0.35 version ID,
 does anybody remember why FreeCOM has if XMS swap version, then
 disable LOADFIX in #if, and why old CATS of HTMLHELP required LOADFIX
 to work with DOS=HIGH (I seem to remember that recompiling with either
 Toms or my KITTEN version or recompiling ZLIB or both was what Bob did
 to fix the bug... maybe there are OTHER programs with CATS affected?
 Which programs still use CATS instead of KITTEN? Symptom was a CRASH
 when using HTMLHELP several times on SOME systems if DOS=HIGH...) ...?
 And did Arkady re-add the seemingly but not actually unneeded BPB/...
 initialization at boot time which he had removed at some point?



 ---
 The SF.Net email is sponsored by: Beat the post-holiday blues
 Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
 It's fun and FREE -- well,
 almosthttp://www.thinkgeek.com/sfshirt
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel


-- 
Kind regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886



---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

[tom ehlert]

Hello Arkady,

  Small optimization: because BC doesn't knows, that exit() doesn't
BO I don't think optimizing exeflat.exe's size is very important though ;)

  Sure. :) But why not make more optimal code from scratch in any case,
 without thinking will this code often used?
And why not leave *existing* code as is - without wasting mental and
ethernet bandwidth on it ?

 LG +  qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc);
  Why to spend extra time for sorting relocations?
BO I think it's easier to read the output that way. Tom's idea.
BO Does qsort() really take a long time for you in exeflat? I find that hard
BO to believe, for just ~70 relocations.

  Of course, qsort() if very fast algo (except some specific cases, when
 it is O(N^2)), but why to do _any_ extra action, when unnecessary? :)
it's not unnecessary - else I wouldn't have written it.

 Especially, I suggest, (most) linkers do own sorting anyway?
I call people who 'suggest' somethintg that is plain wrong (and they could
have seen that themself) idiots.

  Ok, ok, above questions are not critical and mostly rhetorical.
but give some insight.

  Hm. I think for simplicity and safety, exeflat should itself move
 relocation table from executable's header inside executable itself, so that
 it may be reused by MoveKernel(). This allows to eliminate manual table at
 kernel.asm:__HMARelocationTableStart.


  (Yes, I know __HMARelocationTableStart is not plain relocation table,
 but jump/code table, with jmps and calls to EnableA20. But table from header
 may be copied (after fixing) into secondary table. This allows to make
 code, which is more relocatable and may make cross-segments calls and
 accesses. This also solves issues with standard library routines, which may
 be used both from non-relocatable low code and from relocatable code.)

if you can write down a simpler and saver method to do that - fine.
else - see my bandwidth comment...

tom




---
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] some exeflat changes

[tom ehlert]

Hi Bart,

good to see you alive and around :)

 http://freedos.sourceforge.net/kernel/exeflat.c
 (the file is smaller than the diff would be)

there are probably a couple of changes to makefiles  batches ?

 To use it you need to change the makefile to remove the explicit UPX call:
 this call is done via system() in exeflat.c now.
didn't test yet - that's all ?

this might, should and will be recoded by some sort of

  system(getenv(XUPX, ...)

tom




---
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Fwd: FreeDOS kernel disk routines

[tom ehlert]

This is a forwarded message
From: Jose Antonio Senna
Subject: FreeDOS kernel disk routines

===8==Original message text===
 Excuse me for sending this directly to you, but I am still unable to post
on Freedos lists.
 I do not know who (if anyone) mantains the FreeDOS kernel disk routines.
If it is not you, please pass this mail to the appropriate person.
 The problem I found is:
 My computer BIOS INT 13 is able to access up to 4096 cylinders in a hard disk,
by using bits 6 -7 of DH in INT 13 requests as bits 10-11 of cylinder number.
This BIOS variant is documented in Brown and Kyle interrupts list.
 However,FreeDOS hooks INT 13 and,in doing so,rolls over any cylinder 
number modulo 1024,that is,if I make a request to access cylinder 1024,it does
not report any error,but I get cylinder 0, and so on.
 FreeDOS is not the only DOS to have this problem. Is it too difficult to 
solve ?
I thank you for your attention
JAS

===8===End of original message text===

my comment:

how are these disks/BIOS variants detected ?

I have a faint memory of these translating BIOS's, but can't find it
in RBIL.

IMO the kernel shouldn't touch partitions that are to big to handle
(1024 cylinders), unless LBA is detected.

tom




---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Floppy boot config read broken in 2034/32+

[tom ehlert]

Hello Eric,

 Hi, Steve reports that while things were fine in kernels
 2030 ... 2033 (both with and without FAT32 support), kernel
 2034 WITH FAT32 support and all 2035 kernels fail to read
 the (fd) config sys file when booting from floppy.

*ALL* kernels 2023..2035BTom boot from 1.44 floppy, and have no problem
reading config.sys, and never had.

That's how I work (booting from floppy), and this got tested a few
thousand times.

So probably something different is wrong. Maybe the floppy itself is
simply unreadable.

 PPS: Very interesting question is why for 2034 only the FAT32 kernel hurts.
because the kernel was written to a different place on the floppy ?

tom




---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] FreeDOS, DR DOS and Win386 compatibility (shorter)

[tom ehlert]

Hello Eric,

 Hi, I exchanged some mails with Udo from DR DOS improvement project,
 and the conclusion might be that FreeDOS is not missing much for 386Enh
 compatibility - it only has one thing too much: fnodes.

From what follows, it real seems to be easy to make FreeDOS Win3.1
compatible.

So there's just one major problem tot mentioned:

How to interest a kernel developer enough, that he throws his time at
such a waste-of-time project ?

tom



N¬HY޵隊X¬²š'²ŠÞu¼ˆLúèvç-èz‰ÈLƧj«°š.®v¥RLjNšèvç-²)ò¢êۺȧzËzYn³Z·*.¶§’‡í…醊÷®±Š.¬êbž*'°g­·žN§gžhŸ´'«¶'âq«^°)brKh~)Ý¢ëf¢·¡¶Úþšèvç-‚èz+fjv z»#¢êçjW(›ø.‰×©®‰¨¶je·žv‹$z¹Þ–f¢–)à–+-·žv‹$z¹Þ–X¬¶Ë(º·~Šàzw­†Ûi³ÿåŠËl²‹«qç讧zßåŠËlþX¬¶)ߣ÷ëyçh²G«é

Re: [Freedos-kernel] Re: question about the kernel with

[tom ehlert]

Hi Jeffrey,

actually the kernel tries to finish CD harddisk emulation
before booting from HD (main.c, EmulatedDriveStatus)

unfortunately this doesn't seem to work (in your case, with your CD
burning software,...)

tom




---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Broken VERSION= in 2035 etc. - too many kernels

[tom ehlert]

Hello Eric,

 - Tom has added only the best few lines of the Lucho / Arkady patches,
   those which OBVIOUSLY fix bugs, but will have missed several bugfixes
   which were hidden between optimizations
that might have happened.
But for sure I missed some bew bugs hidden between optimizations.

 - Lucho / Arkady produced a big amount of patches which mainly contain
   optimizations (hopefully not too compiler specific), but also important
   bugfixes,
which ones ?

 Tom, are you planning to publish your kernel variant?
www.drivesnapshot.de/freedos/ke2035bt.zip as of today

 In either case,
 could you help us to discuss the feature / bugfix differences between
 your and Jeremies kernel?

bugfixes - yes.

 There must be a lot of useful stuff in all those patches, but we might
 lose overview and miss all the goodies if the patch authors and kernel
 maintainers do not start to help mortal programmers like me to catch up
 with development
why should kernel programmers care if mortal programmers can't follow?
you won't follow anyway.

tom




---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Tom's patch dated 5 July

[tom ehlert]

Hello Luchezar,

 Do you mean
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html
yes

 (It doesn't contain other comments but those in the patch.) If you 
 confirm, I can apply it.
yes.

 it happens if a int24 handler returns to itself directly, instead of the
 'normal' way to return to DOS with some error code.

 But an Int 24h handler returns with an IRET, so to return to itself means
 that it's re-entrant!

has nothing to do with reentrancy.

a) program installs it's own int24handler.

b) critical error happens, int24() gets called.

*usually* this sets carry flag etc. and returns to DOS (and DOS
gets a chance to free_fnode() etc.)

in the observed case (which probably came from some Turbo Pascal
library, floating in the net), the program instead
pops all (DOS saved) registers from stack, sets some magic
flag in the application, and returns immediately to the
user adress on the stack - no chance for DOS to reset errorlevel,
no chance to free_fnode().

tom




---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors

[tom ehlert]

Hello Luchezar,


 D:==second disk? Second disk is a 81h value.

 Only 0 and 80 are used by MS-DOS. All other values are FreeDOS 
 extensions ;-)

are you SURE ?

I remember a BIOS that had the option to boot from 2'nd drive.
this only makes sense if DOS then boots from 0x81.


tom




---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c

[tom ehlert]

Hello Luchezar,


 and removes (parts? of) tom's patch.

 As you wrote youself, it's better to have the whole patch than parts of
 it. And even better is to solve entirely the problem which this kludge
 solves partially. But we don't know the problem :-(

at least I know the problem - and described it when publishing the
patch.

it happens if a int24 handler returns to itself directly, instead of
the 'normal' way to return to DOS with some error code.
In that case the near f_nodes are never freed (until the program
terminates)

the only real solution that comes to my mind is to undo the
alloc_fnode() change, even if that costs a few byte in low memory;
if you don't have UMB's, it even saves a few byte (the memory used by
the 2 near_fnodes)

tom








---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] NSSI Works!!!

[tom ehlert]

Hello Luchezar,

 In FreeDOS 2035a, NSSI crashed.
 In the newest unstable kernel, NSSI works excellent!
 Get NSSI at http://www.navsoft.cz

 Thanks for the information! Unfortunately if UDMA or CD-ROM driver is
 loaded, it hangs at the checking memory for viruses stage under the
 unstable CVS kernel.
these were my results also - with boring, rock stable 

now DOES IT WORK ON UNSTABLE OR NOT ?

WHICH UNSTABLE ?

  Else it works, but hangs at the Checking NLSFUNC
 stage when creating automatic report. Needless to say everything works
 under MS-DOS 7.10.

but scince NSSI is under active developement, the author can probably
tell us what we are doing wrong.

unfortunately, this las sentence was just a joke.

tom




---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] NSSI Works!!!

[tom ehlert]

 In FreeDOS 2035a, NSSI crashed.

as it works for me (a different 2035a), could you
give some details (like config.sys).

in particular: does it crash with an empty config.sys ?

tom

 In the newest unstable kernel, NSSI works excellent!

 Get NSSI at http://www.navsoft.cz

 Interon




---
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=5047alloc_id=10808op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Announce: COUNTRY.SYS

[tom ehlert]

Hello Eduardo,

 Lucho, Steffen, everybody, we should have some discussion to determine
 which COUNTRY.SYS format we should use in FreeDOS.

1'st let me state that I never used NLSFUNC, so I may be the wrong
person.

2'nd, all I needed for FreeDOS was 24 hour time/european date,
and I implemented it
in the kernel.sys (rather then in some external COUNTRY.SYS),
because it requires only a few bytes (for the current supported
date,time, currency,...) and is hardly worth the requirement of an
extra COUNTRY.SYS.
this changes IMO, if uppercasing tables etc. are supported for many
countries, but not sooner; and I think that moving the date/time
functionality to *require* COUNTRY.SYS is a step in the wrong
direction (even if it suits lucho in his attempts to get a few byte
smaller kernel)


 In fact, I've had a working NLSFUNC for some weeks now. The only thing
 it needs for general availability is a kernel with functions 2f.1226 to
 2f.1229. Actually, it works with the implementation of these functions
 that I posted to this list (I modified NLSFUNC to avoid running out of
 stack as Bart suggested) and it even works calling to the int21
 equivalents (saving the caller stack and switching to a local one before
 calling int21).

Congratulations.
I still don't understand why this should be done from inside DOS;
in real life you'll have an external utility
   NLSFUNC SET LANGUAGE GREEK
or similar that can use any desired method, and doesn't have to rely
on fancy kernel internal calls/IOCTLS/etc.
I may be wrong with that, though.

 Another problem is that it does _not_ uses the MS COUNTRY.SYS format,
 but the one that Steffen Kaiser designed when he was implementing the
 NLS support for the kernel. The advantages are that it was designed with
 the kernel NLS structures in mind and that there are also utilities to
 convert to/from a text (source) format.

IMO that's not a disadvantage.
We can't use MS country.sys anyway, and there are hardly many
third party COUNTRY.SYS's floating around we must be compatible with.

I'd prefer a different country.sys format alltogether, with smaller
size in mind.
It doesn't has to be xxZIP'ed (due to relative large decoding code
size), but you get get a significant amount of compression by some

'this toupper table is almost the same as the table before with the expection
of characters 187-192 and 205-119, differences follow'

not difficult to implement, and worth the effort IMO.



just my 2 cents

tom




















 Regards,
 Eduardo.




 ---
 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


-- 
Best regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886



---
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

Re: [Freedos-kernel] Information wants to be free

[tom ehlert]

Hello Luchezar,


 Not only Bulgarians. 3/4 of the world thinks so. And many Americans and
 Germans too, by the way.

 there is a german saying 'hey guys - eat shit!  Billions of flies can't
 be wrong'

 So we're just billions of flies to you. Very well :) Otherwise it's a
 great anti-fashion proverb.

no. it means 'just because many, many people do X, that doesn't
prove X to be right' (nor does it prove it's wrong)


 information is as much a product as a car or a house, and it costs 
 similar effort.

 I disagree. Building 1000 houses costs one almost 1000 times more than a
 single house. Making 1000 copies of a program costs one much less than
 developing the program itself. It's a false analogy.

but developing just one copy of a program (that is worht to be bought)
is usually more expensive than building a house; after it's finished
it's indeed fairly inexpensive to sell it multiple times.

unfortunately I haven't yet found many customers that pay me the price of a
house for a single copy;)

So I sold the first copy of Drive Snapshot for the same price as
the thousandth, and (of course hope to sell millions).

Do you really think after having sold thousand copies, I'm a good programmer,
who deserves any dollar he makes, and after selling millions copies
(and having charged money for it) I'll be suddenly an immoral man ?

IMO it will (or propably 'would') still be the same thing:
the customer gets some value for some amount of money.

if the product is good enough, that the customer is happy - great.
if not - not so great.

But the customers contentness is probably not related to the fact,
that I'm billionaire or not.

tom




---
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

Re: [Freedos-kernel] Announce: COUNTRY.SYS

[tom ehlert]

Hello Aitor,

 Yes, but as I mentioned, the problem is that, how do we get collating
 tables, etc for other countries than US and Germany? We could rely on
 user's efforts to create those tables, but this can be quite laborious
 (provided that, for copyright issues, the COUNTRY.SYS of the 
 competitors are distributable).

well - we get it the same way that the MS COUNTRY information was
collected - BY MANUAL EFFORT BY HOWEVER DOES IT - paid or not.

using MS COUNTRY.SYS isn't an option
other COUNTRY.SYS's simply don't exist.

and IMO the way that all your 100+ keyboard tables were obtained is -
even if it *might* not be strictly illegal - certainly far beyond any
means of 'fair use'

simply sort of 'disassembling' some work that MS has done, and
pretending this is our work, is hardly anything I appreciate.

so I would really dislike this continued in country.sys.

IMO, if it's important to have south guinean keybors support/collating
tables, some south guinean local should provide these tables.

and if nobody provides these tables - fine.

but ripping of MS(DOS/Windows/WinNT) these tables is really something
I dislike.

BTW: all MKEYB tables were created manually (AFAIK; at least if I did
them)
it would be easy to write a compiler/interpreter to make (X)keyb
tables usable in MKEYB as well; I simply don't like the tables.




tom













---
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

Re: [Freedos-kernel] Information wants to be free

[tom ehlert]

Hello Luchezar,

 It's not worth a penny because it can be freely downloaded from Vietnam
 (I posted the URL here ;-)

 I know bulgarians think that way.

 Not only Bulgarians. 3/4 of the world thinks so. And many Americans and
 Germans too, by the way.

there is a german saying
  'hey guys - eat shit!  Billions of flies can't be wrong'


 It's still theft.

 It would be a theft if I *move* the files. If I copy them, I don't deprive
 anybody form anything. The whole nature of information allows copying

sorry - no.

information is as much a product as a car or a house, and it costs
similar effort.

and the people who made this product must be paid - some way or the
other.

just because you can technically copy it (whithout causing me any
direct harm) does NOT imply you MAY do that.

please accept the fact, that there is FREE information, and for some
other information you have to pay, or you will kill the producer in
the long run (because he will starve to death)

 Quite the contrary, corporations steal our money when they ask us to buy
 their software.
it's simple as that:
they want your money IF you use their software.
they offer you a deal, which you can accept - or deny.
stop using their software, and you don't have to pay them a dime.

 Copyright is dying, long life copyleft! ;-)

I assume your company produces some sort of (hardware) gadget, that it
sells - which in the end ends up as salary in your pockets.

I wonder what happens if I rip off your gadgets design and internal
software, 'reengineer' the gadget, produce it myself (at much lower
cost as I don't have to pay the engineers), and sell it at a price
below your gadget.

probably neither your employer nor you what be very glad in the end.

tom



---
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

Re: [Freedos-kernel] Re: Int 2f.122f already supported?

[tom ehlert]

Hello Luchezar,

 Hallo Eric,

 does FreeDOS already support int 2f.122f, set DOS version number?

 Now it does - see patch below ;-)

according to RBIL:
INT 2F U - DOS 4.x internal - SET DOS VERSION NUMBER TO RETURN

AX = 122Fh
DX = DOS version number (h = return true DOS version)

note the 'internal', 'true version', and '4.x' ( not 4+ )

I'd recommend to implement setver in a reasonable fashion :((

tom










---
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

Re: [Freedos-kernel] More kernel bugs and incompatibilities

[tom ehlert]

Hello Luchezar,

 I use IOCTL every day and that's how I found that the XMSDSK lock bug that
 prevented SCANDISK from checking the XMSDSK drive had come back as Arkady
 moved the lock check too low. Without anger, I wrote a patch for this, he
 accepted it with some minor changes, and - voila! Problem solved :)
well - good to see that someone fixes some of these optimization
induced bugs.

 I don't even know what MS-LANMAN is, and I guess I don't use it ;-)
accessing files on a networked drive on a MS Server.

 Sure, but this can be said for the stable version too. In fact, Arkady
 hasn't touched the file system processing part of the kernel at all. So
 the two kenels don't differ very much internally.
except for 2 changed lines.

 You already wrote this, but (1) I'd prefer the innocent presumption, to
 the guilty presumption towards him,
it's the guilty assumption about *any* change, that I didn't peer
review myself.

 and (2) I think that accusing him
 when he's absent to defend himself is not ethical.
I certainly didn't wait to say this until he's absent

 smartdrv is an entirely different beast, that knows a lot about the
 underlying DOS; expecting compatibility with SMARTDRV is probably beyond
 the requitrements of this project (wouldn't hurt for sure, but not 
 *required* )

 I agree, but as I use it every day with FreeDOS, I think that besides the
 obscure incompatibility with its delayed write feature on FAT32 that I
 reported (which may well be a bug in SMARTDRV itself that doesn't reveal
 in MS-DOS!) I haven't noticed any other problems with it under FreeDOS.

one reason for different behaviour *might* be that smartdrv traps
int25/int26, which is used differently in FreeDOS (not everything is
rooted through it)

 *very* easy to fix if you have softice loaded.

 boot normal.
 softicebpint 13 ah=2
 softicebpr 0:0 a000:0 t
 softiceboot  (which reboots the machine, but leaves s-ice
   softiceactive, and you can step booting !!)

 Yes, the great SoftICE! Sweating on the scene is good, but now I'd prefer
 to be among the public and see if anyone else can sweat instead of me ;-)
 Let's give a chance to the young generation ;-)

I wouldn't hold my breath if I'd like to see this bug fixed.

 It's been a pleasure for me to work with Bart, you and the nearly
 forgotten victor who gave us FAT32 in a very ompressive way.

 Victor Vlasenko? Can you write more about this remarkable achievement of
 his? I'm sure that such people may not be, can not be, and are not 
 forgotten!

a) he implemented FAT32
b) he implemented FAT32 virtually bugfree on first try
   without 25 'please everybody test this' alpha releases.
   he probably tested it himself before publishing.
c) he implemented FAT32 - and virtually every single line he changed
   was necessary to do the job. no additional noise at all.
   he probably optimized for smallest diff.

 It's good enough for what I do, and I take care that it remains that way.

 So this is your role since you stopped active kernel development - to act
 as a kind of Kerberos, and thus prevent the only person who still actively
 works on the kernel from having impact on it!
yes.
and while I see no purpose in what he's doing in general, I look at
his changes, and what makes sense (to me), goes into my branch as well.

 Which means that the kernel development has virtually stopped now. How
 sad...
bug fixing will probably never stop, but squeezing single byte out of
it is IMO a complete waste of time.

you may have seen that while I stopped to work regularily on the
kernel, I probably made Stev Gibson happy with FreeDOS (stacks=9,256),
made FreeDOS load DD1000XX.SYS, made freedos kernel load Intel Pro1000
network driver, and found one reason for panic('too many fnodes in use')

4 serious real world bugs; so I wouldn't call my branch dead.


tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] More kernel bugs and incompatibilities

[tom ehlert]

Hello Luchezar,

 or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main
 stream kernel should concentrate on FIXING bugs, rather then introducing
 new ones.

 100% agreed. Since I use unstable kernel every day in practice, I think
 it has no more bugs than the stable one.

that you use it doesn't mean there are no news bugs.
e.q. the complete ioctl was 100% mixed/changed/...
how many ioctl's are you using - not every day, but at least once per
month?
do you use MS-LANMAN networking  (at least once per month)?
etc...

just because YOU don't find bugs (old or new) doesn't mean there are
no (old or new) bugs.

in particular (by your own finding) the new SYS is buggy ( if loadseg
!= 60), but you only found out after using SYS (at least once).

this shall not imply the arkady introduces new bugs every other day
(although I've seem a couple of OOPS's); it's simply that I can't
verify (perr review) what he changed simply because his stupid 'change
everything' attitude.

and so I won't touch the arkady branch with a 3 meter long stick.


 But during the last few weeks I
 noticed several more bugs and incompatibilities present in both stable
 and unstable branches, most of them extremely difficult to fix, namely:

 1. While copying a directory tree containing many LFNs *without* DOSLFN
 loaded and *with* delayed write of SMARTDRV in a FAT32 directory, many
 invalid directory entries are created, which consist of parts of the
 contents of the copied files. Turning delayed write off makes the bug
 vanish. If FreeDOS ir replaced by MS-DOS or if copying to a FAT16 
 directory under FreeDOS, there is no bug.

if you are using (and distributing) SMARTDRV, you can also distribute
msdos xx.

smartdrv is an entirely different beast, that knows a lot about the
underlying DOS; expecting compatibility with SMARTDRV is probably
beyond the requitrements of this project (wouldn't hurt for sure, but
not *required* )

you didn't report, if the same problem happens with LBACACHE.

 3. If load segment (/L option) was different than 60h, bootstrap causes a
 read error during the loading of the kernel if it's longer than about 62
 KB. The exact value of the load segment doesn't matter, and the bug 
 reveals for *any* value other than 60h.

*very* easy to fix if you have softice loaded.

boot normal.
softicebpint 13 ah=2
softicebpr 0:0 a000:0 t
softiceboot (which reboots the machine, but leaves s-ice
 softiceactive, and you can step booting !!)

 4. SYS hangs up or causes an invalid opcode at the time of reading the
 boot sector of my ATA flash cards, if compiled by anything than Watcom.
 Non-Watcom versions of SYS work on all other drives.
again - softice should be your friend.

 So, as a prospective user of the kernel, after contributing to it for more
 than an year, I can conclude than it's good enough for simpler tasks not
 involving writing a lot of long named files on a FAT32 partition. For more
 complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more
 suitable.
not 'complex tasks'. for tasks involving LFNDOS and creating new
files; creating a lot of them just makes it more probable to happen.

 Thank you for your attention. It's time for me to concentrate on other
 tasks. It's been a pleasure for me to work with you guys. I hope that
 FreeDOS will be THE DOS one day. But hardly real soon now...

It's been a pleasure for me to work with Bart, you and the nearly
forgotten victor who gave us FAT32 in a very ompressive way.
For me, it's THE dos today - and I can affort to
distribute a junk DOS even less then Steve Gibson.

It's good enough for what I do, and I take care that it remains that
way.

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] More kernel bugs and incompatibilities

[tom ehlert]

 Remember that Steve Gibson went round trip back to FreeDOS after
 evaluating several other DOSes so this means that FreeDOS can't be that
 bad :)
a) other DOS's were just too expensive
b) his problems seem to have been entirely related to the 2033 kernel
   default stacksize of 128 byte

c) he uses VERY few DOS functions; IMO Spinrite might even work with
   ke2028 (which had still MANY bugs)

 I just hope that if I ever need spinrite myself Steve can pay
 back by giving me a free copy ;)
I's sure he'll be happy to send you a license; I'm proud owner of it
already.

 ;-) ;-) ;-) You're right. It's not bad at all.
good *enough* for me (at least the part I use)

 You know I like it, but I'm
 afraid the remaining bugs (I don't mean just my bugs of course) may play
 bad jokes on us in the future if not fixed. Besides, Steve can't afford to
 use any DOS illegally. So if I were him, I'd choose FreeDOS too.
it's just the question, if it's good enough for the job at hand.
if 'yes' - use it.
if 'no'  - it's far too expensive, even if free.

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Versions and builds, conservatism

[tom ehlert]

Hello Luchezar,

 OK, long live the holy  conservatism that saves the FreeDOS world
 from the Arkadifying hell ;-G By

100% agreed

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable

[tom ehlert]

Hello Luchezar,

 I didn't know that there are TWO kernel builds called 2035a... Perhaps you
 should call yours 2035b where b = Bart (a = Arkady ;-)


or call the 'optimized' kernel keUNSTABLExxx or keARxxx,
as the main stream kernel should concentrate on FIXING bugs, rather then
introducing new ones.

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs

[tom ehlert]

Hello Arkady,

   For drives beyond lastdrive, get_cds result protects from crashes,
   but in between, access to unformatted disks returns nonsense for
   int 21.36 and even crashes while trying to do critical error dialog
te really ?
te please provide exact code sequence where it DOES return nonsense - and
te I'll fix it. (we are talking about ke2035 !!)

  Bernd and Eric many times report, that WHICHFAT utility behaves wrongly
 under FreeDOS. If you blindly ommit those reports, then this not close the
 fact, that this happens.

and why didn't you fix it long ago ?

 LBA_Get_Drive_Parameters should NOT disable LBA access if heads or
   sectors are  64k
te As I wrote this:

  WHEN

why don't you go to HISTORY.TXT ?

 AND WHERE?!

most probably in aachen, western germany, 3'rd planet in solar system

  but should be mentioned in kernel docs (- DEVICEHIGH/LOADHIGH).
te which kernel docs ?

  config.txt?

this isn't an issue of *additional, non-standard* config.sys sysntax.

tom




---
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] ludivmul.inc

[tom ehlert]

Hello Arkady,

 - may/should be `static dmatch Dmatch;' in fcbfns.c moved to stack in the
   FcbFindFirstNext() (as in other functions in fcbfns.c)?

I' abolutely NOT sure about that.

you are right - it doesn't seem to make much sense.

I have some dark memory, that I changed that (back in the dark ages),
because else the stack would overrun it's 384 byte size, and dmatch is
fairly large. please look up yourself - if that wasn't yet in ~2035,
this was the reason to make it static.


tom




---
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: Smaller tour of 32bit stuff in kernel, optimize, bugs

[tom ehlert]

Hello Eric,

 EA LBA_Transfer should call the appropriate int 2f.xx function before
 EA   calling play_dj - or play_dj should call it itself: This allows
 EA   GUIs to return okay, notified, please suppress DJ text message.

 INT 2F CU - DOS 5+ - FLOPPY-DISK LOGICAL DRIVE CHANGE NOTIFICATION
 AX = 4A00h
 CX = h
 DH = new drive number
 DL = current drive number
 Return: CX = h to skip Insert diskette for drive X: message
 Note:   called by MS-DOS 5.0+ IO.SYS just before displaying the message
   Insert diskette for drive X: on single-floppy systems

these are nearly implementation instructions - I wasn't aware of this
call. you could have posted it the first time.
unfortunately AFAICS RBIL intermixed DH and DL here (it has an
advantage to be proud owner of MSDOS :)

changes needed:

hdr\pcb.h, 691
  unsigned ASMPASCAL intr(int nr, iregs * rp);

INTR.ASM, 136:

no_read_error:
ret

+   global  INTR
+INTR:
+   INTR


segment INIT_TEXT
;
 
 
DSK.C, 231

if (i == blk_dev.dh_name[0])
{
  put_string(Error in the DJ mechanism!\n);   /* should not happen! */
}
else
{ 

+   /* according to RBIL (te 22 jul 04) */
+  iregs r;
+  
+  r.a.x = 0x4a00;
+  r.c.x = 0x;
+  r.d.b.l = pddt-ddt_logdriveno;
+  r.d.b.h = pddt2-ddt_logdriveno;
+  
+  intr(0x2f,r);
+  
+  if (r.c.x == 0x) 
+   {
+   /* someone else makes a nice dialog */
+   }
+ else
+   {   
  template_string[DRIVE_POS] = 'A' + pddt2-ddt_logdriveno;
  put_string(template_string);
  put_string(Insert);
  template_string[DRIVE_POS] = 'A' + pddt-ddt_logdriveno;
  put_string(template_string + 6);
  put_string(Press the any key to continue ... \n);
  fl_readkey();
+   }  
 
tom






---
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] SYS fix

[tom ehlert]

Hello Arkady,

  Some times I report about bugs in SYS. Unfortunately, these reports was
 completely ignored. (tom, what about discussion?)

to make one thing clear - once and for all time:

you post about 10 changes to this list - do you really expect that
everyone reads, tries to understand, and 'discuss' this ?

as I'm not using SYS anyway, my interest in it is fairly reduced; if
it does exist at all; why should I 'discuss' that ?

I AM interested in kernel and freecom, that's enough.


 Currently, I write  completely new SYS
 (tom, and not say later, that I not offer discussion  here!).

you'll write a COMPLETELY NEW sys anyway - what's to be discussed here ?

just go ahead. but don't be surprised if noone is going to use it.

  Before this, Lucho prepares some fixes for current SYS.

I have no opinion in SYS - as long as LUCHO does them.

a) he tends to fix BUGS
b) he tends to fix them by changing 3 lines.
c) he probably tested them as well.

tom




---
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] Smaller tour of 32bit stuff in kernel, optimize, bugs

[tom ehlert]

Hello Eric,


 DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of
   a NULL navc pointer.

If so, please submit some code to make the kernel crash.
if not, shut up.

 I wonder if it is really desirable that the
   current implementation fakes bigger cluster sizes to allow cluster
   counts below 64k
Probably Bart implemented it for sheer fun ?

   Maybe saturation would be better. How do other DOSes handle this?
maybe would be better that YOU check other DOS'es behaviour BEFORE
writing emails, because you are just bored ?

   For drives beyond lastdrive, get_cds result protects from crashes,
   but in between, access to unformatted disks returns nonsense for
   int 21.36 and even crashes while trying to do critical error dialog
really ?
please provide exact code sequence where it DOES return nonsense - and
I'll fix it. (we are talking about ke2035 !!)

   for int 21.1c - probably some 0:xx data or stack got overwritten.
please provide exact code sequence where it DOES overwrite something -
and I'll fix it. (we are talking about ke2035 !!)


 LBA_Get_Drive_Parameters should NOT disable LBA access if heads or
   sectors are  64k

As I wrote this:
if sectors or heads are  64K the LBA BIOS is probably buggy.
and IMO it's better to refuse to work with a buggy BIOS then to
try to trash a users disk.

 or if totalSectHigh is nonzero.
this will be relevant when disk (arrays) are larger then
2 TB (not that far away)

but then we good old partitioning scheme stops to make sense,
and it's better not to touch these disks at all.

there could be some (easy) workarounds for that (my estimate less
then a few hundred resident byte) + understanding dynamic disk
partitioning (non resident code).

until that is done it's a better idea not to touch these disks.


 At several places, ULONG / value and ULONG % value could be
   explicitly marked as ULONG / UWORD and ULONG % UWORD type,
   to allow compiler optimizations (32:32-32 bits is more complex
   on 8086 than 32:16-32 bits).

as was relied before (but you are probably so busy writing emails
rather then reading) :

there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32.
end of story.

 LBA_Transfer should call the appropriate int 2f.xx function before
   calling play_dj - or play_dj should call it itself:
   which 2f.xx functions please ?

   For the latter two, I recommend:
   If buffer is exactly aligned, transfer limit should probably be
   64k, not 64k - 1 sector.
nonsense. you simply cant issue a read request to DOS  0x


 Track wrap protection and DMA wrap
   protection should be turned off (maybe add a SYS CONFIG variable!)
   for harddisks.
nonsense again: there's a specific field in EXT13 functions, if DMA
crossing is allowed or not (and the kernel doesn't care about it)
doesn't make a difference anyway.

 There is also UMB avoidance: If a buffer is in
   UMB or HMA, all access is copied through the low RAM disk transfer
   buffer (which is only 1 sector big). Probably required,
definitively for EMM386 style UMB's (lacking Virtual DMA support)
on some UMBPCI machines

  but should be mentioned in kernel docs (- DEVICEHIGH/LOADHIGH).
which kernel docs ?

tom




---
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: FreeCOM

[tom ehlert]

- BREAKS FreeCOM and possibly also FDAPMs Am I run from INSTALL=?

 1. MS-DOS-style mean two \0 and 2035a produces two \0.

EA So Arkady has optimized away 4 wasted bytes in environment,

  6.

PLONK.

tom




---
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

[tom ehlert]

steffen)

put MSDOS + current distributed FreeCOM on floppy.
boot, and say F5 (skip everything)

and you'll have a load complaining FreeCOM,
although it definitively gets it's startup path.


Arkady)
it's a plain dull idiotic mathematicians braindead idea
to 'improve' freedos kernel, but break all generations
of distributed FreeCOM's

just my 2 EUROS on that issue

tom







---
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] ludivmul.inc

[tom ehlert]

Hi Bart,

 In any case, I appreciate that a bug was found in  ludivmul.inc
so do I

 What I don't like is that the fix from Arkady (for the 1000th time...)
 does 3 things at the same time -- formatting, fixing, and optimizing.
neither do I like that.

 This makes it impossible to see where things are really fixed. See the
 following is enough:

 --- ludivmul.inc.~1.2.~ Sun Jan 27 14:13:07 2002
 +++ ludivmul.incTue Jul 20 00:35:31 2004
 @@ -88,10 +88,12 @@
 pop bx ; get dividend lo-word
 mov cx, ax ; save quotient
  mul di ; quotient * divisor hi-word (low only)
 +   pushdi ; save divisor hi-word
  xchgax, di ; save in di
  mov ax, cx ; ax=quotient
 mul si ; quotient * divisor lo-word
 add dx, di ; dx:ax = quotient * divisor
 +   pop di ; restore divisor hi-word
 sub bx, ax ; dividend-lo - (quot.*divisor)-lo
 mov ax, cx ; get quotient
 pop cx ; restore dividend hi-word

thanks for that.
I was going to analyse it was well to find the REAL difference to
apply to my kernel branch, your effort saves me some time

and it's again remarkable how little changes are needed wrt. the 200+
line diff's arkady sends.


 I'm sorry but I simply don't have the time to go through all the other
 patches.
neither do I - specially if they are 90% completely useless formatting
changes, 9% introcing LPVOID and Cstr data types, with (at most) 1%
hidden gem inside.

 If they were reduced to just bug fixes I'll promise that I'll
 have another look though -- I still monitor the mailing list every now and
 then. Guys *any* project that wants to be close to a 1.0 release must be
 in deep freeze, a stabilation, that means that we should really freeze the
 mainline kernel for anything but bug fixes. No optimizations, no 
 reformatting, no new fancy macros, no nothing but bug fixes with the
 minimal amount of lines changed.
110% agreed.

 Of course feel free to have your own
 branch, but I don't think it's in the interest of the project to 
 use that for a 1.0.

 So I can make a deal, you isolate your bug fixes and I'll return and be
 friendly, or you don't and I'll simply disappear. It's that easy.

well - I maintain such a kernel branch; however not sure if I catch
every hidden gem...
of course source is available on request.

tom




---
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

[tom ehlert]

My dear Mr. Belousov,

  _I_ _report_ bug in FreeCOM. If now FreeDOS is closer to MS-DOS and
 FreeCOM now incorrectly works in both under MS-DOS and FreeDOS (with empty
 environment), who wrong?

do you really think a new kernel that breaks all installed FreeCOM's
in the wild is an improvement ?

Do you really want to force everyone to update to a new freecom?
(people often update only one component)

Do you really want to see all the
  'updated to new kernel, now freecom doesn't work anymore'

being a possibly talented programmer is one thing.

but handling real world issues decently (and silently) seems not
to be one of your virtues.

tom






---
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] ludivmul.inc

[tom ehlert]

BB replace readable by understandable for inexperienced C programmers

  Unimportant.
here I have to agree - kernel programming is nothing for inexperienced
programmers, and will never be.

  Note: this is myth.
well - my private email archives show that 'arkadifying code' is used as
synonym for 'hardly understandable cryptic stuff' - both incoming and
outgoing.

SOMETIMES this may be useful - and we used it: the kernel's memory
model is probably beyond most peoples understanding

using it ALL the time is nonsense.


However, the main kernel programming style was set forth ~10 years ago
by Pat Villani in the kernel original sources.

Both Bart and I didn't agree 100% with it (COUNT is discussable at
least), but agreed to KEEP this style as much as reasonable.








  You often read tom's words about russian magician,
 which makes cryptic code and you trust these words. Yes, sometime I use not
 very common tricks, but I (always) try to comment all such places! If you
 see my code (and, especially compare it with original code), you find this.

  For example, compare original ludivmul.inc and my edition. I think,
 this is light example of what is my changes.

  Another example. Remeber, as you try to comment Umb_State in config.c,
 which was initialized by magic value 0, 1, 2? Compare _now_ with my edition,
 where used (commented) enumerations UMB_NONE, UMB_DONE and UMB_REQ.

  And, if sometime my comments not enough, I alway open and hear, and may
 comment more, if this will be asked.




 ---
 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_idG21alloc_id040oplick
 ___
 Freedos-kernel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel


-- 
Best regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886

Re: [Freedos-kernel] Kernel patch policy, branches, and FreeCOM

[tom ehlert]

Hello Eric,

 I am sure 2035a fixes several bugs of 2035

found the ret_ah bug. if that has real world implications is unknown.

found the Ulong 32%32 bug - impressive, but 100% irrelevant to the
kernel as all real world use will work 100% ok.

claims to have found a bug in umb_link code for a001:
  now it doesn't work either, and is again irrelevant as noone uses
  (for good reasons) /I=a000-afff

possibly made the graphical MENU better - but certainly broke Eric's
and mine non-graphical config.sys

found a bug so now MS Smartdrv loads - unfortunately now FreeCOM
doesn't work any longer (even if that's a bug)

IMO that's less then impressive


just as a OT sidenote, found somewhere on joelonsoftware.com:
the old WIN developers took it *personally* if some old stuff wouldn't
run any longer. this went as far as:
  they found that SIMCITY would run beutiful on DOS, but crash in
  windows. after some lengthy debugging they found that simcity frees
  some memory - and uses it afterwards.
  sure this works in DOS - and fails badly in a multitasking
  environment where this memory is reused by someone else.

now there 2 solutions for that

  solution a) say this code is buggy, ask manufacturer

  solution b) implement 'is the current task simcity ?'
  if so, delay the *real* free for a couple of seconds.

they (the MS developers) took b)

and for me this ends the threat.

tom

















---
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] fixing MOVE

[tom ehlert]

Hello Arkady,

 As I already answer here, to fix bug with MOVE should be prevent moving for
 directories.
te msdos CAN move directories,

  If you reread my posts here (or in freedos-dev?), then you find my
 letter, where I already show (with help of debug scripts), that this is
 _not so_.

You are mostly right.
real MSDOS can't.
WinNT DOSBOX can.

so it shouldn't hurt to reject.


te so the rejection would only change the bug.
te better to implement it correctly.

  Your suggestions?
where the move is done; probably somewhere in FATFS.c,
but after the network redirector.

tom




















---
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 sources - peer review

[tom ehlert]

Hello Bernd,

 be prepared to defend yourself against Tom's and Lucho's comments. I
 believe it's called peer review.

in theory - yes.

in praxis - here are the reasons why
   you won't see a peer review by me
   I started a new branch of the kernel,
   I'll not use any arkady kernel for production

it's simply that to much has changed; far beond the necesary amount.

example:
  config.b :
removed all comments,
  build.bat
   changed MSCL8 to MSC
   changed TC2 to TC
   changed comments :- to ::
   etc.
  etc...

not only that it was MSCL8 for some reason (because it's the MSC V8
compiler), this also makes MANY changes without any useful purpose.

but when reviewing changes, I'd have to review ALL changes and see
if there any new bugs introduced, and thats simply impossible due to
the sheer amount.

there are people, that can add significant to a project, but change
only relevant parts, and leave the rest intact (cheers to michael);
other's are simple unable to do so even if told 100 times.

I'll run my own kernel, as I simply trust it more; I've put
enough time to make it as stable as it is now. Should it
break, it's my fault, noone else to blame; betting on a russian
horse is too risky for me.

tom




---
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 sources - peer review

[tom ehlert]

Hello Arkady,

just an example why I will NOT peer review anything:

just comparing old and new FLOPPY.ASM:

about every 2'nd line has changed - with no useful purpose.
sometimes - if nothing else was changed - 2 lines were simply
switched. empty lines inserted or removed. trivial comment
changes. ...

just to find out if you did something useful or harmful
would require significant work.

tom




---
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

[tom ehlert]

Hello Arkady,

where the hell are thge sources for these changes ??

 config.c

 - config now parsed in 5 passes:

that's fine IF config.c fit's into buffers or you boot from disk.
else (if boot from floppy) that might become *SLOW*

 - screen now cleared (white on black)

well - I IMPLEMENTED THE CONFIG MENU'S FIRTS TIME.

AND I ABSOLUTELY HATE IT IF OTHER ASSHOLES COMPLETELY CHANGE THE
BEHAVIOUR INTO A WIN95 GUI LIKE BEHAVIOUR.


tom




---
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

[Freedos-kernel] inthndlr.c - critical error handler

[tom ehlert]

INTHNDLR.C, 428

if (lr.AH != 0x59)
  CritErrCode = SUCCESS;
  }
  /* Clear carry by default for these functions */

+   /* see PATCH TE 5 jul 04 explanation at end */
+  if (ErrorMode  lr.AH  0x0c  lr.AH != 0x30  lr.AH != 0x59)
+  {
+ ErrorMode = 0;  
+  fnode[0].f_count = 0;/* don't panic - THEY ARE unused !! */
+  fnode[1].f_count = 0;
+  }





INTHNDLR.C:1514


real_exit:;

/* PATCH !!   TE 5 JUL 04
what happened:
Application does FindFirst(I:\*.*);
this fails, and causes Int24
  this sets ErrorMode, and calls Int24
Application decides NOT to return to DOS,
but instead pop the stack and return to itself
  (this is legal; see RBIL/INT 24 description

a) now the alloc()'ed fnode[0] never gets free()'ed
b) errormode NEVER gets set back to 0 unyil exit()

I have NO idea how real DOS handles this;
the appended patch cures the worst symptoms
*/

  if (fnode[0].f_count  != 0 ||
  fnode[1].f_count  != 0 ) 
  {
  if (ErrorMode == 0)
  put_string(near_fnodes not 0); /* panic ?? */
  
  fnode[0].f_count  = 0;/* don't panic - THEY ARE unused !! */
  fnode[1].f_count  = 0;
  }


/* PATCH !! ENDTE 5 JUL 04 */


tom




---
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: kernel progress

[tom ehlert]

Hello Eric,

 AND I ABSOLUTELY HATE IT IF OTHER ASSHOLES COMPLETELY CHANGE THE
 BEHAVIOUR INTO A WIN95 GUI LIKE BEHAVIOUR.

 Pretty asshole-style behaviour to insult each other on the list, mister!

as I said - I implemented it first place;
now someone simply starts to chage THE BEHAVIOUR to his mood
without discussing this (it's not discussable anyway)

AND I HATE THIS.

(I also hate his change every line into arkady-style, but that's a
duifferent story)

if that's asshole-like behaviour - I don't mind.

THE ASSHOLE




---
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] default drive and CDS

[tom ehlert]

Hello Arkady,

  In kernel often used constructions, similar to next:

 if (get_cds(drv ? drv - 1 : default_drive) == NULL)

in which case 'often' is 2

so I think you are wasting our time.

bye







---
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] default drive and CDS

[tom ehlert]

Hello Arkady,

  In kernel often used constructions, similar to next:
 if (get_cds(drv ? drv - 1 : default_drive) == NULL)
te in which case 'often' is 2

  Ok, 2. But non-zero. In any case there will be useful to introduce
 get_cds1(), which will call get_cds(drv ? drv - 1 : default_drive) (because
 there is much more than 2 such instances).

in any case, FreeDOS kernel is GPL, so you may do whatever you want.

just another example of arkady'fying a project.

unfortunately, you drive former developers away - forever.

te so I think you are wasting our time.

  _If_ you don't know the answer, simply don't answer. This your letter
 contains no useful information. :(

only useful questions can get useful answers.





---
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] VERSION= behavior

[tom ehlert]

Hello Arkady,

  BTW, Eric says, that RBIL describes INT2F/122F functions, which (also)
 sets returned DOS version.

INT 2F U - DOS 4.x internal - SET DOS VERSION NUMBER TO RETURN

AX = 122Fh
DX = DOS version number (h = return true DOS version)

have you  ever seen DOS 4.x (not 4.0+) ?

AFAIR, this was a TASK specific value, and it returns some magic field
from PSP.

 Currently FD not implements this functio (says
 error for it on screen), but implements (similar) INT21/33FC. Should I
 _re_define INT21/33FC as INT2F/122F?
no.





 ---
 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


-- 
Best regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886



---
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: inthndlr.c

[tom ehlert]

Hello Eduardo,

 I'm implementing NLSFUNC for FreeDOS and I've found that many (most) of
 the needed MUX functions are missing.

 This patch implements functions 2F1226h to 2F1229h. This, together with
 my previous nls.c patch, allowed me to make a first working
 implementation of NLSFUNC's int 2F1404h, but the patch looks so simple
 that I must have done something wrong :)  so, kernel guys, please, have
 a look at it. It is mainly cut'n'paste from int21_service()

a)
why do you need int2f/12 in the first first place ?
are you really executing this from inside KERNEL ?
do you really need to use internal functions ?

if YES, you will probably greatly overrun the kernels 384 byte stack,
which might become a problem.

if NO, why don't you use int21 functions ?


b) lseek(0x1) will fail due to fall from locng_check into
shortcheck.

tom






 Eduardo.


 diff -uNrp ke2035.orig/kernel/inthndlr.c ke2035/kernel/inthndlr.c
 --- ke2035.orig/kernel/inthndlr.c 2004-06-24 22:41:20.0 +0200
 +++ ke2035/kernel/inthndlr.c  2004-06-24 22:41:09.0 +0200
 @@ -1656,6 +1656,9 @@ struct int2f12regs {
   */
  VOID ASMCFUNC int2F_12_handler(struct int2f12regs r)
  {
 +  COUNT rc;
 +  long lrc;
 +
if (r.AH == 0x4a)
{
  size_t size = 0, offs = 0x;
 @@ -1869,6 +1875,42 @@ VOID ASMCFUNC int2F_12_handler(struct in
r.CX = fstrlen(MK_FP(r.DS, r.SI)) + 1;
break;
 
 +case 0x26: /* open file */
 +  r.FLAGS = ~FLG_CARRY;
 +  CritErrCode = SUCCESS;
 +  lrc = DosOpen(MK_FP(r.DS, r.DX), O_LEGACY | O_OPEN | r.CL, 0);
 +  goto long_check;
 +
 +case 0x27: /* close file */
 +  r.FLAGS = ~FLG_CARRY;
 +  CritErrCode = SUCCESS;
 +  rc = DosClose(r.BX);
 +  goto short_check;
 +
 +case 0x28: /* move file pointer */
 +  r.FLAGS = ~FLG_CARRY;
 +  CritErrCode = SUCCESS;
 +  r.BP = 0x00ff;
+  if (r.BP  2)
 +goto error_invalid;
 +  lrc = DosSeek(r.BX, (LONG)ULONG) (r.CX))  16) | r.DX),
 r.BP);
 +  if (lrc == -1)
 +  {
 +lrc = DE_INVLDHNDL;
 +  }
 +  else
 +  {
 +r.DX = (UWORD)(lrc  16);
 +lrc = (UWORD) lrc;
 +  }
 +  goto long_check;
 +
 +case 0x29: /* read from file */
 +  r.FLAGS = ~FLG_CARRY;
 +  CritErrCode = SUCCESS;
 +  lrc = DosRead(r.BX, r.CX, MK_FP(r.DS, r.DX));
 +  goto long_check;
 +
  case 0x2a: /* Set FastOpen but does nothing. */
 
r.FLAGS = ~FLG_CARRY;
 @@ -1897,6 +1939,26 @@ VOID ASMCFUNC int2F_12_handler(struct in
  r.FLAGS |= FLG_CARRY;
}
}
 +  goto real_exit;
 +long_check:
+  if (lrc = SUCCESS)
 +  {
 +r.AX = (UWORD)lrc;
 +goto real_exit;
 +  }
 +  rc = (int)lrc;
 +short_check:
 +  if (rc  SUCCESS)
 +goto error_exit;
 +  goto real_exit;
 +error_invalid:
 +  rc = DE_INVLDFUNC;
 +error_exit:
 +  r.AX = -rc;
 +  if (CritErrCode == SUCCESS)
 +CritErrCode = r.AX;  /* Maybe set */
 +  r.FLAGS |= FLG_CARRY;
 +real_exit:;
  }
 
  /*




 ---
 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


-- 
Best regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886



---
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] VERSION= issue

[tom ehlert]

Hello Arkady,

  Eric Auer suggests, that VERSION= should change os_setver_m*, not
 os_m*. What you think? Is there is bug in current FD and Eric's suggestion
 is patch for this?

seems to be a bug indeed. seems noone is using
  version=X.Y ;)

tom



---
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

[Freedos-kernel] CONFIG.C ANNOYANCE

[tom ehlert]

RANTMODE

I'M HIGHLY DISAPPOINTED TO FIND THAT SOME FORMERLY
WORKING CODE DOESN'T WORK ANYMORE; 

I'M IN PARTICULAR DISAPPOINTED AS 
THIS CODE WAS ONLY CHANGED TO SAVE SOME 20 BYTE OF 
INIT CODE. WELL - THIS SAVES 20 BYTE, BUT COSTED 
ME A MONTH TO DISCOVER - AND AN ADDITIONAL HOUR TO FIX.

TO ALL OPTIMIZERS: HANDS OFF. GO PLAY SOMEWHERE ELSE.


/RANTMODE


UWORD GetBiosKey(int timeout)
{
  iregs r;

  ULONG startTime = GetBiosTime();

  if (timeout = 0) do
  {
r.a.x = 0x0100; /* are there keys available ? */
init_call_intr(0x16, r);
-if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u)
+if ((unsigned)(GetBiosTime() - startTime)  timeout * 18u)
  return 0x;
  }
  while (r.flags  FLG_ZERO);

  /* key available or blocking wait (timeout  0): fetch it */
  r.a.x = 0x;
  init_call_intr(0x16, r);
  return r.a.x;
}

tom




---
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] bug: floppy.asm

[tom ehlert]

Hello Arkady,

  I found another bug:

 - when fl_lba_ReadWrite() converted to ASMPASCAL (and `ret' replaced by `ret
   8'), ret_AH remains as label for this tail (whereas other functions use
   plain `ret').

then remove the label, compile, and see what happens :((

tom




---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] patch: portab.h, exeflat.c

[tom ehlert]

Hello Arkady,

  In above case at first glance I don't see possibilities to break
 integrity ([] have top most priority over other operations), but this not
 mean, that such case can't be constructed by some smart man, which knows
 language even better.

another 10 points to get plonked.




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.86,1.87

[tom ehlert]

Hello Bart,

 if (GetBiosTime() - startTime  (unsigned)timeout * 18)
break;

 Menu timeout set at 10 seconds. Boot kernel with menu at 23:59:55.
 Timer expires at 00:00:00 (0-1.5M = very large number)
and that's exactly the wanted behaviour.

 instead of  00:00:05.

but it times out, and doesn't wait indefinitively.

and to wait precisely 10 seconds in the case that someone boots
FreeDOS at midnight AND is sitting at the keyboard AND thinks it's a
bug that the timer gotes off early is simply not worth the code to
handle this case.

  +if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u)
and the original code uses long arithmetic on purpose.

tom






---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: Reference compiler / changing the spec

[tom ehlert]

Hello Eric,

 BC xx wouldn't have worked
 after my HMA additions.
 I hope you make that clear somewhere. Otherwise, people try to use BC...
I was talking about history; at these times it simply couldn't compile
with any BC.

 It would be helpful to have some port MASM -- NASM document.
 Two solutions: Use Arrowsoft ASM (freeware). It supports not-too-complex
 MASM/TASM files. Good for the existing code base.
what 'existing' source base ?
there's no MASM sources around.
and noone cares enough to port TASM-NASM, unless you DO IT YOURSELF.


 And I really hope that it will be possible to compile the kernel with Turbo
 C in the near future.
this sentence disqualifies you as an even semi serous contributor to
the kernel list. please go away.

 is it something like the bible, or should it be something
 reflecting (intended) reality ?

 I suggest that it describes reality, but that original intentions are
 not removed but just marked as obsoleted.

I think, that a spec should describe the projects intention.
and it's certainly not the kernels intention to be compilable with any
compiler.
the intention is to build a MSDOS compatible kernel; use the
approriate tools (free if possible)

 Config sys compatibility: For ME, non-menued (DOS 5?) config sys is
 fine, and I am not worried by the fact that our menu language is
 different. Might be a point which is open for discussion.
it's not open for discussion. it's open for PROGRAMMING.

 Are you sure that there can be up to 64 STACKS? I thought only 8..16?
it makes only sense for the number of hardware interrupts (8..16)

 Okay for me to drop SETVER.
because you don't understand it's purpose (your implementation implies
that at least)


 Still GPL is preferred, of course :-).
I'm pissed by GPL - for known reasons.

tom




---
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] Re: Re: Reference compiler / changing the spec

[tom ehlert]

 XYZ=TRUE in config.sys?
THIS WAS INTENDED NOT TO BE DOCUMENTED. THANKS FOR AMKIING IT PUBLIC.

no kind regards
tom




---
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] kernel problems and problem loading high DISPLAY

[tom ehlert]

Hello Aitor,

 If I understood Eric's point, it might be UPX fault, as it would fail
 whenever it tries to enlarge the UMB as required by the uncompressed
 program and silently fails. So I may have to provide uncompressed 64KB
 DISPLAY.COM in the next release (last before DISPLAY.SYS).

make an .EXE file of it, and forget this CPM compatibility clutch of
.COM files.

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] EBDA movement FUD

[tom ehlert]

Hello Michael,

Hi, I would like to spread some fear, uncertainity and distrust
about EBDA movement!

MD Can you give the exact syntax on using that in CONFIG.SYS.
MD Is it a bare SWITCHES=/E line on its own?

Yes, it's a bare

 switches=/E

I had to discover this this morning, too, as running

  device=S-ice.exe /EMM 4000

also nukes the PC. It seems, Softice is moving the EBDA by itself and
in addition to the kernel, to the PC ends up with 641KB, which would
only be nice if it worked.

tom




---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.75,1.76 config.h,1.3,1.4 kernel.asm,1.50,1.51 main.c,1.70,1.71 segs.inc,1.17,1.18 task.c,1.40,1.41

[tom ehlert]

Hello Arkady,

AVB Why? To make code more portable between assemblers.
ROTFL

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.75,1.76 config.h,1.3,1.4 kernel.asm,1.50,1.51 main.c,1.70,1.71 segs.inc,1.17,1.18 task.c,1.40,1.41

[tom ehlert]

Hello Arkady,

AVB Why? To make code more portable between assemblers.
te ROTFL

AVB  ?

Rolling On The Floor Laughing

you really can't keep things untouched?

I would really HATE the kernels assembly sources converted into
GMOUSE cryptographic sources.

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] patch: batch and make files (description)

[tom ehlert]

Hello Arkady,

AVB PS4: repeat for my previous question: why to duplicate clean and
AVB clobber? Another one: who make files status.me, *.cod, *.las?

*.cod are generated by MSC, if compiled with 'generate assembly
listing with source' (very handy when debugging)

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] patch: batch and make files

[tom ehlert]

Hello Arkady,

AVB  I test batch and make files both under OW12 and BC31
would be great if you ewoild test them with TV 2.01 also (this is a
reference compiler, BC31 not)

btw: there is absolutely no need to mess with them - they usually
work.

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28

[tom ehlert]

Hello Arkady,

AVB  Then rename add_far into normalize_ptr and remove misleading.
noone is going to rename functions because you don't like the names.

AVB Also,
AVB I may offer next code to always perform normalization:
It's there for some specific purpose.

AVB (BTW, is protection
AVB from wrapping HMA pointer into IVT by replacing wrapping into start of HMA
AVB worth of code?)
a working kernel is worth a lot of code (even if you don't see the
reason immediately)

HANDS OFF THE KERNEL, please.

tom





---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: editing command line

[tom ehlert]

AVB 1. In kernel present editing code.
yes.
AVB 2. If code presented in command.com, how this affects other programs (say,
AVBDEBUG)?
command.com implements it's own doswedit-style input editor.
it doesn't affect other programs (it's not exported)

tom




---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: Borland C 386 bug

[tom ehlert]

Hello Luchezar,

LG Maybe later I could try it too... but first I must learn
LG Bochs!

try
DEVICE=C:\NUMEGA\S-ICE.EXE /TRA 30 /SYM 400
DEVICE=C:\system\himem.sys /TESTMEM:OFF
DEVICE=C:\NUMEGA\umb.sys
...
installhigh=

UMB.SYS is the s-ice UMB provider, and should work similar to emm386

LG All this just for a tiny refused patch?!
No. but the problem lies somewhere else.
fmemcpy() uses EAX in a very correct way, and the compiler will issue
some
mov EAX,4[bp]

whenever it finds appropriate.
somewhere else, sooner or later, where it will again cause trouble.

thus the proplem is just delayed, not solved.


tom




---
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