Hey Javier, Excellent work! I know that it has been a long process from the original simple contribution, but am looking forward to it ;-)
Miguel. 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. > > Habbit > > 2007/12/5, Javier Martín <[EMAIL PROTECTED]>: > > 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list