[Mono-dev] DriveInfo implementation

[Javier Martín]

Status update: I'm currently at step 4, i.e. the Windows version has
been implemented and everything seems fine, sane and consistent. I had
to implement the WindowsGetDrives method too in order to make the
class even usable, but it's a bit of a stub based on
Environment.GetLogicalDrives and does not detect the filesystem type -
that should be trivial with the Win32 GetVolumeInformation call, but
it's secondary and for later: I don't want to add two new internal
calls on a single patch.

I'm now going for lauch. If noone reports breakage in a few hours,
I'll start with the POSIX port, probably adding two files "volume.h"
and "volume.c" to io-layer, since I don't think the new functions fit
anywhere else.

I have done my best to create solid, consistent code and to avoid
corrupting the namespace, but if anything can be improved, I'm
positively waiting for feedback. All my code was compiled with MSVC
8.0 (a gcc cygwin build proved frustratingly impossible because of a
Makefile error), so, even if I tried avoiding compiler dialectisms, I
could have introduced some.

This patch has two diff files: icalls.diff (to be applied at
/mono/metadata) and DriveInfo.diff (at mcs/class/corlib/System.IO).
Also, I noticed an small typo at the declaration of the Exp function
in mcs/class/corlib/System.PAL/IOperatingSystem.cs (dobule instead of
double) which prevented corlib from compiling at first.

Habbit

2007/12/5, Javier Martín <lordhabbit at gmail.com>:
> Ok, this last nut of wisdom from Robert has really fueled me up. It's
> quite nice to be back from class and find such good news lying on my
> mailbox. So, I'm starting with the Windows version first. Since this
> will be the first time I delve into the depths of the runtime's
> support code, I've written a small checklist with what I'll do where
> so that any accidental receiver of this list can spot the probable
> mistakes that my usually astounding lack of judgment is certain to
> cause x_x
>
> --ON WINDOWS--
> 1.- DriveInfo.cs - create a "external" method with the appropiate
> MethodImplAttribute flagging it as an internal call.
> 2.- icall-def.h - define the new internal call, possibly MONOIO_34,
> and route it to a new function
> 3.- icall.c - implement the said function, calling only ANSI C and
> Win32 APIs. Be careful not to dereference NULLs, corrupt memory, etc,
> since mommy GC & daddy runtime are not here to help
> 4.- build and check everything is sane. Compare to M$'s results
> --ON LINUX--
> 5.- some file in io-layer, possibly io.c - implement POSIX-based
> substitutes to the missing Win32 functions/structs/etc I've used
> 6.- $thatLastFile.h - expose the Win32 prototypes I've used
> 7.- build and check everything is sane. Compare to both mono-win and
> MS-win results
> --HAPPY ENDING--
>
> Seems easy at first, but I suppose it's neither a piece-of-cake nor an
> impossible mission. Well, tomorrow is a holiday here in Spain, so I
> can hack the whole day.
>
> Habbit
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icalls.diff
Type: application/octet-stream
Size: 2764 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071206/181a0eda/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DriveInfo.diff
Type: application/octet-stream
Size: 4634 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071206/181a0eda/attachment-0001.obj