Hi :-)

> a) Connection between FreeDOS 1.0 and FAT32 drive in Windows XP:

(works, nice)

> b) Connection between FreeDOS 1.0 and FreeDOS 1.0

You could also try FreeDOS server and Windows client...

> The command "dir" results indeed in:
> "unimplemented internal dos funktion INT2F/120a"

RBIL says about this on www.ctyme.com/intr/int-2f.htm
www.ctyme.com/intr/rb-4378.htm "DOS 3+ internal,
perform critical error interrupt" (expects ds=es=DOS
DS and no DOS stacks in use, also expects extended
error code on stack, returns user response in AL as
0 ignore 1 retry 2 abort 3 fail, CF clear iff retry,
stack unchanged, "Notes: Can only be called during a
DOS function call, as it uses various fields in the
SDA to set up the registers for the INT 24. Reportedly
sets current DPB's first root directory sector to 1")

That is odd - the message about a missing critical
error handling thing raises the question why and
which critical error was about to be handled here.

Int 2f.120a *seems to be (ALMOST?) same as* int 2f.1206,
*anybody got an idea whether there are differences* ?

The message can be found in discussions in 2004 and 2005,
for example in context of network drives or GEOS...

shows in int2F_12_handler (lines 1740 to end) that the
function 2f.120a is still not implemented. The current
state supports: 0, 3, 6, 8, c, d, 0x11-13, 0x16-0x18,
0x1b, 0x20, 0x21, 0x23, 0x25-0x2a, 0x2c, 0x2e, 0x2f as
subfunctions of int 2f.12xx ...

For comparison, the UNSTABLE kernel branch shows:
(apart from adding int 2f.16xx experimental WfW 3.11 support)
...that function 2f.120a is not supported either, but that
function 2f.122b got added (line 2236-2259, basically only
a wrapper for DosDevIOctl :-)). Function 2f.122d is also
added and actually very simple: r.AX = CritErrCode; (get
extended error code).

For reference, other things in int 2f.12xx that are not yet
implemented in FreeDOS are: 1 close current file 2 get intr
address 4 normalize pathsep 5 output char to stdout 7 make
disk buffer most recently used 9 flush and free disk buffer
0a perform critical error interrupt 0b signal sharing viol-
ation to user 0e mark all disk buffers unreferenced 0f make
disk buffer most recently used (again?) 10 find unreferenced
disk buffer 14 compare far pointers 15 flush buffer 19 set
drive??? 1a get drive of file 1c checksum ram 1d sum ram
1e compare filenames 1f build current dir struct CDS 22 set
extended error info 24 sharing retry delay 2b invoke ioctl
(present in UNSTABLE) 2d get extended error code (SAME) and
the Win95 specific functions 30 and 31. All of those COULD
be implemented but SHOULD only be implemented on demand (as
needed in real life) but they SHOULD be documented as not
yet implemented in the FreeDOS kernel documentation!

Other DOS related int 2f functions: b7nn APPEND b0nn GRAFTABL
ad80 KEYB adnn DISPLAY ac00 GRAPHICS 55nn COMMAND shareable
portion possibly in HMA 4bnn task switcher 4a33 Win95 DOS7
4ann smartdrv/dblspace/dosshell/HMA/floppy-DJ/... 49 SETUP
(interaction with FORMAT progress meter) 48nn DOSKEY ...
43nn novell DPMS 1ann ANSI 19nn SHELLB 16nn Win/DPMI/WfW311-
compatibility/bootlogo 13 int13 hooking 11nn network redir
10nn SHARE 08nn DRIVER 06nn ASSIGN 05nn critical error msg
override hook (called by command.com) 01nn PRINT ... Lots
of obscure and internal functions but some of our drivers
do happen to implement some of them - probably more than
strictly necessary to run 99.99% of all DOS apps :-).

> Using NetBEUI protocol instead of TCP/IP:
> The "INT2F/120a" error message isn't shown when using the NetBEUI
> protocol. But the command "dir" doesn't show anything - at first:
> After typing "dir" a second time, all files and directories are shown
> as they should. The procedure is repeated - I have type "dir" twice
> to get a listing.

That is quite strange! But nice to see that things work at all.
I wonder if anybody can investigate the details... NetBEUI is
exotic and having FreeDOS client and server using it even more.

> http://www.wintotal-forum.de/index.php/topic,67037.15.html
> http://www.nabble.com/Kernel-Problems-td1664097.html


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Freedos-user mailing list

Reply via email to