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&iu=/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&iu=/4140
_______________________________________________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
