[Mono-dev] DriveInfo implementation

[Robert Jordan]

Hi Javier,

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.

The PLATFORM_WIN32 conditional in icall.c must be avoided.
Since you're going to implement GetDiskFreeSpaceEx in io-layer
it will be not necessary. But I guess you already know this
and tried to keep the code compilable, correct?

Also, do not use g_assert if you already thrown an exception.
This will kill the runtime.

On DriveInfo.diff: we all know about the
"if (platform == 4 || platform == 128)" trick. There is no
need to comment it like this :-)

Since you're in corlib, you should use the internal property
Environment.IsRunningOnWindows anyways.

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

Please try to get a running cygwin environment, because it's
kinda normative for mono. The "make" issue can be fixed by
installing the make version as linked from:

http://shana.iidbbs.com/en/mono_cygwin_tutorial.html

Thanks
Robert

> 
> 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
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list