[Mono-dev] DriveInfo implementation
Miguel de Icaza
miguel at novell.com
Thu Dec 20 00:17:19 EST 2007
Excellent work! I know that it has been a long process from the
original simple contribution, but am looking forward to it ;-)
On Thu, 2007-12-06 at 14:33 +0100, Javier Martín wrote:
> 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.
> 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
More information about the Mono-devel-list