Back to Website

NTFS question

All development related issues welcome

Moderator: Moderator Team

NTFS question

Postby clancg2003 » Sat Apr 10, 2010 3:45 am

Hello, I apologize if I posted this on the wrong board, but I have a question about NTFS.

Does the project known as NTFS-3G have full NTFS implementation (I'm guessing it doesn't :P .) and if it does not, what exactly is it missing? I don't really know much about computer hardware, but I've always wondered about this.
clancg2003
 
Posts: 29
Joined: Sat Apr 10, 2010 3:24 am

Re: NTFS question

Postby Haos » Sat Apr 10, 2010 9:26 am

It misses being Windows IFS driver. It is a Linux FUSE driver instead. This means porting is required if one wishes to use this code in ReactOS. As we did learn, porting stuff from Linux to NT is time/resource consuming, cumberome and doesn't guarantee any success.
Haos
Test Team
 
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am

Re: NTFS question

Postby clancg2003 » Sat Apr 10, 2010 10:59 am

So then NTFS-3G is actually a complete NTFS implementation only it is for Linux? I always figured that it had some of the basic NTFS functions but was missing some of the more advanced.
clancg2003
 
Posts: 29
Joined: Sat Apr 10, 2010 3:24 am

Re: NTFS question

Postby Haos » Sat Apr 10, 2010 1:16 pm

Its not 100% complete, but pretty advanced. Not for Linux, but for *nix FUSE (Filesystem in USErspace).
Haos
Test Team
 
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am

Re: NTFS question

Postby bobsobol » Tue Apr 27, 2010 4:25 am

Several attempts have been made to create a FUSE compatible layer for Windows, and while User-mode file system extensions which perform the same function (from a users point of view) are quite common, the design of FUSE and the file-system modules that work with it are so bound to the Unix paradigm "everything is a file" that they really don't work well.

One coder claims to have written FUSE for Windows, fulfilling a "code bounty" and the requester seems happy with that... however, that was code written under a commercial contract which neither the coder not the purchaser have any legal requirement (or desire) to share... even for money.

NTFS3G is complete, from a UNIX point of view... it handles Hard and Soft Links, full file permissions for User and Group rwexd... all of these things are un-helpful in Windows terms, where we are only interested in global DOS permissions RAHS and Access Control Lists (ACLs), Junctions, Reparse Points and alternate data streams (ADSs) which have no meaning in Unix.

As an example of this "lost in translation" FUSE and NTFS3G compile and work well on Max OS X 10.x.x and this is a good way to access NTFS drives on your Mac. OS X is BSD based at it's core and natively supports BSDs FFS (not the Amiga FFS), DOS / USB memory Sticks FastFAT, the ISO9660 and UDF for Read Only Optical discs and Apples HFS and HFS+ file systems. Traditional HFS systems store a Data Fork and a Resource Fork for each "object" (file or folder) on the volume. In Windows terms the Data Fork should be the primary Data Stream for the object and the Resource Fork should be an Alternate Data Stream, but because DOS and Unix know nothing about Data & Resource Forks or Alternate Data Streams, FUSE uses the Macs fall-back for non-native file systems and stores them in an additional hidden .resource file.

If there was a native NTFS driver for Mac, it could handle Resource Forks in a more native NTFS manner, but because their isn't it has to be translated from Mac to Unix first and then from Unix to NT. The same would happen if you try to "use" NTFS3G in Windows... you have to translate from Windows to Unix to Windows and loose all the native advantage of having an NT file system on an NT OS... it would just work like Ext2fs only much, much slower.

The problem with the NT IFS (Installable File System) method, is that it is not a user mode file system extension... it is akin to traditional Linux Kernel modules, and runs purely in Ring0 (kernel mode)... making them hard to develop, hard to debug and very hard to reverse engineer blindfold. XD Between the code in NTFS3G and the GNU NtfsTools (now NtfsProgs) there should be enough to write a GNU NT IFS but since no NT based OS kernel which supports NT IFS' does not come with an NTFS IFSD and Recogniser there is little incentive.

To be clear... ReactOS must first support IFS drivers and recognisers before one can apply an NTFS one to it. Right now, all it's file system support is hard-coded into the kernel. But that doesn't prevent you from using tools like VirtualVolumes in user-mode to access files on other file systems.

Dokan is the most successful open source user-mode file system (FUSE-a-like) framework for windows and take-up for implementing file systems in it seems low. There are many mentions of winFUSE on the net, but all have died and since been pulled down, suggesting that the benefits are far out-weighed by the effort.

Other interesting projects which work along similar lines include Pismo File Mount Audit Package which is licensed as commercial, and half open source (some source is free, but it's definitely not free beer, and far from GNU or BSD license standard "open") and WinMount which is 100% closed source commercial software. However, each of these systems mount archive files (ISOs, Zips, Rars, vhds and vmdks etc) as if they where folders or drives. They mount them in such a way as even DOS / win32 command line programs can browse into them and read (if not write) to them like directories or drives... this is different from a number of GMail Drives, which are effectively name-space extensions to Explorer (like the Control Panel, Recycle Bin or "Fonts" folder which display files that are not necessarily actually in that location, and definitely don't look like that when you browse to their actual location) and are not visible to other applications. TortoiseSVN produces a similar "name-space" extension, but has it mapped over a true directory... the extension allows you to do special synchronisation with a central repository in a similar manner to the Microsoft "Briefcase" which is another extension to explorer, not the file-system stack.

If one of the (several available) e2fs IFS drivers that work via retail Windows IFSD system would work on ReactOS, then you could surely "borrow" the NTFS and fastfat IFSD from your legal copy of windows in order to use NTFS in ReactOS until an open source version could be developed... but as yet, they do not. :(
bobsobol
 
Posts: 18
Joined: Tue Jun 05, 2007 9:59 pm

Re: NTFS question

Postby Ged » Tue Apr 27, 2010 10:13 am

It's a library. It doesn't need to be ported, it needs an FSD wrapper similar to what Aleksey started with the fastfat library
Ged
Developer
 
Posts: 925
Joined: Thu Sep 29, 2005 3:00 pm
Location: UK

Re: NTFS question

Postby bobsobol » Tue Apr 27, 2010 3:57 pm

Yes... but when you are being asked about completeness, it's as complete as it can be from a Unix point of view only. The reason NTFS is interesting on a Windows platform (over and above e2fs/e3fs, FFS, BFS, AFS, ResizerFS etc) is the Windows NT platform specific features is supports natively.

fastFAT doesn't and never could support Junctions, Re-parse Points, Alternate Data Streams or Access Control Lists, compressed and encrypted attributes etc. and nor could most filesystems used on Unix / Posix operating systems... the BFS from BeOS is the only one I can think of that would come close, and you'd have to use it's extended "named attributes" to store ACLs and ADSs, though they are quite capable of being used that way. There would still be no means of distinguishing a junction from a re-parse type hard-link, unless you marked that with an extended attribute.

All filesystems could have their library "wrapped" to work... and I guess you could "fudge" extra features into hidden files similar to the "Long Filenames" in FastFAT or the extra files a Mac drops on any alien filesystem... but that's not the same as the features being natively available.

For forensic purposes I've known people use FUSE to even gain access to NTFS encrypted files, by looking up the key in the system SAM registry, provided the user who owned that file hasn't been deleted.

So if all you want to use it for is to gain access to data on an alien system (your XP / Vista / Win7 partition) it's fine... but if you want to make it your primary filesystem in ReactOS, it would require some work to get the full feature-set available to you in a native way.
bobsobol
 
Posts: 18
Joined: Tue Jun 05, 2007 9:59 pm

Re: NTFS question

Postby EmuandCo » Wed Apr 28, 2010 9:37 am

Err, we never said ntfs will be our primary filesystem. it will be supported for completeness, but right now we go in ext3 direction.
Image
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
EmuandCo
Developer
 
Posts: 4035
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld

Re: NTFS question

Postby gonzoMD » Wed Apr 28, 2010 3:21 pm

but if you say you want do follow the winNT design isn't it more correct to take ntfs?
gonzoMD
 
Posts: 973
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany

Re: NTFS question

Postby EmuandCo » Wed Apr 28, 2010 4:12 pm

The file system has nothing to do with the OS Design. XP runs on FAT32, too and its still a NT Arch OS.
Image
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
EmuandCo
Developer
 
Posts: 4035
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld

Re: NTFS question

Postby Z98 » Wed Apr 28, 2010 5:59 pm

Except we lose all of the security features that depends on the FS. ext3 would not be adequate and NTFS would be a nice endgame. Or something as nice. Considering ext3 is just ext2 with journaling, and ext2 made all sorts of compromises for the sake of speed, etc, etc.
Z98
Release Engineer
 
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm

Re: NTFS question

Postby clancg2003 » Thu Apr 29, 2010 9:23 am

Ok, so if I'm understanding you guys straight, if the developers were to port the NTFS3G implementation from Linux to Windows, then ReactOS would have NTFS that is on the same level as Microsoft's implementation?

And yeah, I happen to agree, that the final version of ReactOS will definitely need NTFS support. The majority of MS users probably have no idea on how to partition their disks to some other format. Unlike Linux users, many MS users know very little about computers and simply want an OS that is easy to use and works. They certainly won't use ReactOS if it requires them to configure a bunch of things around.
clancg2003
 
Posts: 29
Joined: Sat Apr 10, 2010 3:24 am

Re: NTFS question

Postby Ged » Thu Apr 29, 2010 11:12 am

As I said earlier, it doesn't need porting, NTFS-3G is a cross-platform library which is used in many different OS's.

wikipedia wrote:It is runnable on Linux, FreeBSD, NetBSD, OpenSolaris, BeOS, QNX, Windows NT, WinCE, Nucleus, VxWorks, Haiku, and Mac OS X.


It's used in Linux via the FUSE wrapper, it's used in Haiku via their own driver wrapper, etc, and it can be used in reactos via an FSD wrapper.
This is exactly the same as Aleksey did with the FullFAT library which will hopefully become our new FastFAT driver in the future.


The goal is to use it as the primary filesystem in reactos, ext3 isn't sufficient.
Ged
Developer
 
Posts: 925
Joined: Thu Sep 29, 2005 3:00 pm
Location: UK

Re: NTFS question

Postby EmuandCo » Thu Apr 29, 2010 12:13 pm

clancg2003 wrote:Ok, so if I'm understanding you guys straight, if the developers were to port the NTFS3G implementation from Linux to Windows, then ReactOS would have NTFS that is on the same level as Microsoft's implementation?

And yeah, I happen to agree, that the final version of ReactOS will definitely need NTFS support. The majority of MS users probably have no idea on how to partition their disks to some other format. Unlike Linux users, many MS users know very little about computers and simply want an OS that is easy to use and works. They certainly won't use ReactOS if it requires them to configure a bunch of things around.


The majority does not know how to format to NTFS, too. 1st stage setup does this for them and the same way it will be done in ROS.
Image
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
EmuandCo
Developer
 
Posts: 4035
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld

Re: NTFS question

Postby bobsobol » Sat May 01, 2010 6:22 am

EmuandCo wrote:Err, we never said ntfs will be our primary filesystem. it will be supported for completeness, but right now we go in ext3 direction.
And this is the single most frustrating thing I see frequently coming from ROS development... the primary reason to have an open source NT based OS is native access to *ALL* features of NT file system via Win32 PE executables... anything else I can do from FreeDOS, ntfsDOS and HX-DOS. An Open Source Win32 OS is fun to play with. It's nice. But what I need is an open source system which links PE files against kernel32.dll, user32.dll and maybe advapi and uses the NT Object Name-Space to access NTFS via native NT objects with their full ACLs, ADSs etc just as the NT kernel handles in memory NT objects and devices... otherwise I may as well stick with a blend of DOS and Wine. Both of which are very stable and slightly limited by their lack of "native support for NTFS".

For me, and probably for many other people, ROS is a toy until it supports NTFS natively. I love the project, but make no mistake about the importance of this "feature". I remember ROS team discussions about whether to support the system Registry using the same file format as Microsoft or whether to just implement it via some existing open source SQL engine... that is not so great an issue, as third party tools can access system.dat and user.dat files for off-line repair. Well listen:-
  • NTFS is a must because without it you can't "upgrade" your XP / Vista / se7en install on NTFS to ReactOS without switching FS to ... ext3? Vista and se7en won't install to FAT any-more, because it is too limiting and CANNOT support basic system security. Anything other than NTFS is a no-brainer, you stick with MS.
  • You can't mount an MS partition under ROS to use native tools and utilities to repair permissions and other factors via Win32 APIs. If you could (as a system engineer I know fixing someones PC by booting off of a live "distro" to fix their broken PC is a big sell for the "fixee", because my Knoppix rescue disc has sold many home users on the power of GNU, one way or another.
  • You can't run many server based applications that rely on NTFS permissions for their own system security without "emulating" those features on top of any other file system... and ReactOS has always been about reimplementing, not emulating. If you want to emulate Windows you use Wine.

Please note, all of the above goes against current ROS dev planning.It is not an official statement of intent by the ReactOS team, it is completely contrary to the intentions of the ReactOS team. I am aware of this, and have come to accept it. However, I will not sit silent while you poodle along as you are just so you can "think" that all your supporters are happy with that. I do, and will continue to support your efforts and sing your praises, but it is my opinion that on this issue you (the active development team doing work I can only dream about being skilled enough to achieve) are following a misguided direction.
EmuandCo wrote:The file system has nothing to do with the OS Design. XP runs on FAT32, too and its still a NT Arch OS.
XP... 2000... NT4 and even NT3 all run certain tasks and applications VERY badly on anything other than NTFS... many native securities introduced in 2000 (in particular) rely heavily on the ACL system implemented in NTFS and XP (SP2, and IE 6 + even on 2K) makes active use of the ADS for internet download warnings... or where you all simply not aware of these "native features"? I think not. I think you fine fellows are far too knowledgeable for that. I just can't believe you could have achieved so much without knowing such things.

I'm sure someone on the active ROS team is aware of them, and has in the back of their mind some idea of how ROS will implement equivalent features, but I never read any mention of it. TBH, I smell a "gotcha". It feels like the tentacles of MS have put out feelers to say, "You can do this, provided...." and NTFS is in the provisions of ReactOS not getting the big bad MS hammer of lawsuit. But if there are good answers to all these problems that will be introduced if ReactOS never gets to boot natively off an NTFS partition, please tell us how "ReactOS" believe that overcoming them with some other file system and forcing us to do maintainence on the systems of the corporate sheep with block level systems which may as well be run from DOS or Linux is "better"... please tell us. Don't just say "we don't want to do it", "it's too hard", "the standard isn't documented"... because most of what you implement in ReactOS is hard, undocumented standards, and implementing sufficient NTFS specific features at API level mapped to an alien filesystem is not going to be easy either.
Z98 wrote:Except we lose all of the security features that depends on the FS. ext3 would not be adequate and NTFS would be a nice endgame. Or something as nice. Considering ext3 is just ext2 with journaling, and ext2 made all sorts of compromises for the sake of speed, etc, etc.
Correct. But "nice" is not strong enough wording IMHO. *IF* full NTFS "emulation" is implemented on ext3FS, or any other FS... say with special hidden files the way a Mac implements it's native resource and data forks on alien filesystems... that is fine for the operation of ROS, and is also a plus for ROS users, *provided* native NTFS support is there in order to maintain compatibility with stubborn and half-well written utilities and server suites which require NTFS at sector level as well as API level... We've seen from Vista how many programs conform to MS API style guidance (which is poor anyway) and still fail to work on an API equivalent upgrade.
clancg2003 wrote:Ok, so if I'm understanding you guys straight, if the developers were to port the NTFS3G implementation from Linux to Windows, then ReactOS would have NTFS that is on the same level as Microsoft's implementation?
NO! You understand wrong... if NTFS3G where implemented natively in ROS it would work as well as the open source communities best current implementation of NTFS... It would work as well as ext3fs on ROS. It would still be a million miles away from being "adequate" for use on anything but a non-Win32/Win64 OS. Running ROS on NTFS via NTFS3G would be as useful as running it on fastFAT, ext2fs, ext3fs, ResizerFS, BFS, FFS etc.

The reason why it is "not up to the job" is because the API it's written against reduces filesystems to Files, Directories and Subdirectories. The bare essentials of *any* filesystem... it's an abstraction of a virtual "thing" which starts from the premiss that "all filesystems are alike" and can and should therefore "be treated equally". The design of FUSE also makes the assumption that "all Operating Systems are basically like Unix", at least to the extent of POSIX compliance, and despite the claims of the quote from Wikipedia above, I have seen no successful implementation of a host for *any* FUSE filesystem library on the NT architecture which is actually workable in the public domain... for sale, or for open source dissection... (somebody please give me a link if I'm wrong, because I've seen so many claims and found so little evidence)

wikipedia wrote:It is runnable on Linux, FreeBSD, NetBSD, OpenSolaris, BeOS, QNX, Windows NT, WinCE, Nucleus, VxWorks, Haiku, and Mac OS X.

  • Linux = i386 GNU Open Source Unix clone
  • FreeBSD = Berkly Institute BSD Open Source Unix clone
  • NetBSD = See FreeBSD, it's the same root source with different optimization aims and package management.
  • OpenSolaris = Open Sourced former commercial Unix clone
  • BeOS = Dead commercial POSIX compliant implementation based on some brilliant re-thinking of the micro-kernel projects.
  • QNX = QNX is kUNIX... Quick Unix designed commercially from the ground up to excel at real-time operations.
  • Windows NT = I've not seen it, and don't (yet) believe the claim.
  • WinCE = I have little to do with this, but I doubt this claim, and would care little if it where true. Windows CE is not much different than Windows ME for mobile devices merged with the multi-platform abilities of NT4 (DEC-Alpha and PPC variants) or an X-Box, if you want to look at it that way.... it's nearly but not quite Windows.
  • Nucleus = I know very little of this but the website quotes "Real time kernel, C++ and POSIX interfaces, dynamic download, interprocessor communications."
  • VxWorks = I have no idea how this "embedded" OS works, but 2 of the three "host" systems (one of which is required to program it in the first place) are Unix based.
  • Haiku = Open Source reimplementation of BeOS. (see above)
  • MacOS = It's BSD with a very, very nice GUI and driver system. (specifically, it's Darwin BSD based on the Mach0 kernel)
I'm sure FUSE would run fine under Cygwin or Services for Unix layer, that doesn't make it work on native Windows NT.

I watch this subject closely, it is dear to my heart, I have seen all the arguments which generally shut up disbelievers who don't really understand what non-Windows OS are and are not capable of doing natively, and I still feel like I'm being sold down the river by a politician who doesn't live in the same world I do... the real world I work in (the one most of you work in)... the world where I have to push your product just as hard as the money men, because you are worth it.

I really, really, really want to push ReactOS, but in all honesty I look at my clients and if I'm going to pull them away from the commercial NT kernel OS, even if ROS is not Beta, and everything works flawlessly, the lack of NTFS support is going to be a killer for server devs and admins, for home users who use existing Anti-virus and Anti-Malware systems and Firewalls based on commercial Windows distributions all to the extent that I could sell them on Linux, BSD, Apple or even AROS easier and with a clearer conscience. Leaving only Game players who are happy to get infected every 3rd week and reinstall their OS on that frequency. Especially if ReactOS can be installed "lean and mean" with no superfluous overheads.

That's just not what *I* want to promote ROS for. I want to promote it as Windows that YOU have the source for. That if your server needs to boot in some specific way that requires a tweak to the kernel you can hire a guy to do that for you. That if you want to play games and surf the net in safety you can do it for a whole lot less money that MS ask... and let's be fair, home users don't really get the support from the OS they pay for... they pay for the support given to SMEs and Developers, and that's just not fair. I want to promote it as a free and open source Live! boot CD, DVD or USB stick for maintainence guys, that if they don't need the GDI system running and want to run the NT kernel from a command line with full access to "CACLS" etc and maybe boot GDI at a later date to surf the web they can "build" a boot disc to do that, and it won't take months of trawling through WIM image documentation and BartCD scripting and stuff to achieve it... but I need to promote NTFS, using NTFS features from NT objects in the NT object name-space natively from native Win32/Win64 PE/PE+ programs they can build just the same as they build their existing tools to fix NTFS drives using Windows APIs.

I know games using ADSs for registration information, (they won't install, or can't be registered on FAT partitions) I know tape drive backups which compresses the MFT of your server using a different algorithm to the one used for general data systems... and that compression is embedded in a chip on the tape drive... you can't bypass it, or write a different driver, they're server backup systems for NT servers, the don't work on Linux, the can't be re-written and they can't back-up FAT partitions because "no serious Windows server would run on anything but NTFS" I know "Microsoft Office" uses ADSs to store author, editor lists etc in it's documents. I know Vista keeps much of it's indexed data searches in ADSs, and you can use Google Desktops XML system but if you write a tool to work in co-operation with Vista / Se7en indexing you will need an ADS implementation. BFS has one, ext3 could fake one, but how is that easier that "getting it right in the first place". ROS is still beta, if it's buggy right now then it's buggy, you'll get bug reports and learn more about NTFS from user responses that anything else.

Try it guys. Try all your applications, from the most common to the most specific, and try copying their files off an NTFS partition and back on to a different NTFS partition under a different boot OS... you will find all sorts of meta-data gets lost... that's normal operation. It's not normal for that information to be lost every time the file is created or saved, and some organisations come to rely on that transaction tracking meta-data. ACLs are used extensively in NT Domains and Workgroups... which is why Microsoft tell you never to place Roaming Profiles on ANYTHING but NTFS... you try putting them on FAT and see (across an SME network) how many more times user profiles have to be re-constructed, especially if your employees are hot-desking. SAMBA fakes this information with SQL (I believe)... but is that really what you want for ReactOS? Again, isn't that pushing us to running Linux and Wine and not ROS? And if you want to take that route... admit, this is a play around project for hobbiests and is never meant to come out of beta. Some other project is going to have to take the most stable version of ReactOS they can get and turn it into a real workable system... I don't want to advocate that, (it is why BSD looses out to Linux) but I can see you pushing people in that direction on this subject alone.

It's too soon in ROS development to consider production server systems? It's too soon to look at such "rare and uncommon uses of Windows" what? MS Office and IE? That's a rare use? Workgroups and Domains are Rare? And if you aren't already thinking about these implementations of ReactOS then it is too soon for you to be saying "we have no plans of ever implementing full NTFS support as a native and integral part of ReactOS"... otherwise you need to poll interested parties about why "they would want native NTFS support" and "whether some emulation of those features and a user-mode basic file access driver" would be sufficient. Because, for me, it is not... I could be in a minority... but I suspect I am not. I also suspect that many "users" are not aware of how much of their OS doesn't work, fails gracefully or just refuses to run / install if the primary boot partition, or the partition on which they are installed is not flagged as NTFS. Ask them to try it and see the difference.

It's not great, for home users, they just get infected quicker, find the maximum partition size limiting, and get a few less nag screens... but on a DC, or ActiveDirectory setup it is mission critical. Suddenly IIS is more flawed than a Mosaic server with some CGI bolted on, and MS-SQL server is open to all sorts of new and funky vulnerabilities and code stops working for no apparent reason. Roaming profiles become as intermittent as a Rover 523 with a leaky hood on a cold wet day and many decent firewalls just miss too many intrusions or simply refuse to install. Live-backup systems refuse to install, and system up-time becomes minimal (services keep restarting of their own accord). Don't ask them to work on FAT32, try one of the e2fs fsds for everything but the boot partition... the same thing happens. It's NTFS on ReactOS or stick with the commercial implementation for serious power-user to admin work, and there can be no argument in my mind. (None that I've yet heard has convinced me.)

When you say "we aren't going to use NTFS for ReactOS" I read "we aren't a serious project with any real aim to compete with Linux, Windows, MacOS or even AROS or Haiku... we're just having a bit of fun here." and "We don't really care if Windows programs run on ReactOS, just so long as the kernel and driver system is compatible" I am saddened to the bone. What is the point? Are you looking to achieve Windows HAL drivers to power X-Windows on Linux so nVidia and ATI don't have to write custom drivers for those OS? What other practical use for ReactOS have you got in mind? Who is your target audience for this software? Hackers and geeks who think it's cool to have Windows that Microsoft didn't write and actually works with less software than a MS pre-Alpha OS? Come on... don't sell your self short... Pleeeeeeeeeeeeeeeease.
bobsobol
 
Posts: 18
Joined: Tue Jun 05, 2007 9:59 pm

Next

Return to Development Help

Who is online

Users browsing this forum: No registered users and 5 guests