| ActiveMac | Anonymous | Create a User | Reviews | News | Forums | Advertise |
|
|
|
User Controls |
|
New User |
|
Login |
|
Edit/View My Profile |
|
|
|
|
|
|
|
ActiveMac |
|
Articles |
|
Forums |
|
Links |
|
News |
|
News Search |
|
Reviews |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
ActiveHardware |
|
Xbox |
|
MaINTosh |
|
News Search |
|
|
|
|
|
|
|
ANet Chats |
|
The Lobby |
|
Special Events Room |
|
Developer's Lounge |
|
XBox Chat |
|
|
|
|
|
|
|
FAQ's |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 4 |
|
Internet Explorer 5 |
|
Windows NT Tips |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
Latest Reviews |
|
Applications |
|
Microsoft Windows XP Professional |
|
Norton SystemWorks 2002 |
|
|
|
Hardware |
|
Intel Personal Audio Player 3000 |
|
Microsoft Wireless IntelliMouse Explorer |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
ANet Forums |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
Member Pages |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
 |
Microsoft Overhauling Files for Next Windows | |
|
||
| Time: 08:51 EST/13:51 GMT | News Source: ZDNet | Posted By: Julien Jay | ||
|
To achieve the long-elusive goal of easily finding information hidden in computer files, Microsoft is returning to a decade-old idea. The company is building new file organization software that will begin to form the underpinnings of the next major version of its Windows operating system. The complex data software is meant to address a conundrum as old as the computer industry itself: how to quickly find and work with a piece of information, no matter what its format, from any location. For those using Windows, this will mean easier, faster and more reliable searches for information. Replacing its antiquated file system with modern database technology should also mean a more reliable Windows that's less likely to break and easier to fix when it does, said analysts and software developers familiar with the company's plans. | ||
|
Write Comment
Return to News |
Displaying 1 through 25 of 333 Last | Next |
The time now is
6:43:15 AM
ET.
Any comment problems? E-mail us |
| #1 By 5444 (208.180.245.184) at 3/13/2002 12:04:28 PM |
|
Brian,
Well the Filesystem is a Database. A specialized one. Usually not extensable after it is designed. So switching to a TRUE database that handles every thing isn't that far of a stretch #5. By todays standards it is. But the Common File store has been a Goal since at least 1995. Right now you can't for instance search for every document that Bob and Judy have worked on. Further, Every File can be index if it inside the same filestore Which will speed searches not to mention boot times and other common issues. With a Transact datastore, a FS can be rebuilt from scratch fairly easily, all it has to do is read the transactions. You see some of that in NTFS now with indexed files. but it isn't the same accross all the various datastores. #3 there will probably be an NTFS driver for those programs that rely deeply on the NTFS. and perhaps even a Fat driver for the same purpose. But in the Longrun you are eliminating several different datastores. NTFS, fat/fat32, the jet datastore used by Outlook and OE and Access, the modified jet datastore used by Exchange, Active Directory, and sharepoint(or what ever the name of the share program is) Even windows CE will benifit as a Low level version of it will exist. And perhaps with this FS there will even be better security implementation than currently in NTFS. It may also happen in this version (longhorn) the migration of the CLR into the OS. Since the CLR will be an integral part of Yukon, But I believe that that will wait until Blackcomb. If it is in Longhorn. You will be able to write queries in any language you feel confortable with though. Thinking along those lines. If the CLR is fully integrated the Object based Operating system may be a reality, (although BEOS achieved it first, But I won't mention that it was Apple that forced BEOS off of its system first, and forced BE to rewrite the OS for x86 based systems putting a draiin on thier resources, I won't demean that MS boot system may have made it harder for them to install, and certain contract negotiations may have prevented them from installing on vendor in a dual boot situation) But it was apple that led them to that road in the first place. El |
| #2 By 5444 (208.180.245.184) at 3/13/2002 12:19:13 PM |
|
stubear,
If they do it right. the concept of a drive wouldn't exist. There would be the Datastore. and that is it. I haven't played enought with SQL server yet. to understand the full implications. But SQL server now allows for clustering of drives. (ntfs kinda does with Dynamic drives, but you must decide on it at the very beginning) From what I have read about SQL sever 2000, you can just add a drive and it expands the storage available to the system. No concept of D drive or E drive etc. at least for HDD The only partioning that would therefore be needed would be for alternative OSes. and the initial partioning for the system to know it is a fs location. #11 why yes it will:) Imagine if you have a Small home network with 4 drives at 30 gigs apiece. If the FS is setup correctly, The difference in FS would be insignificant. IOW the Drives become a Cluster storage system for the entire network. The main issues I see is the Lack of domain sign in on the HE (or even real local sign in for that matter) but those are issues that will be sorted out. Another issue would be if a program is installed and goes on to the net store and that net store is unavailable for instance Time will tell in how MS implements it. El This post was edited by eldoen on Wednesday, March 13, 2002 at 12:29. |
| #3 By 3339 (65.198.47.10) at 3/13/2002 12:28:57 PM |
| I would hope that if MS does achieve this, they are also working to remove all the crap that gets stored in some of MS's most popular and proprietary file formats, particularly Word. That would be truly brilliant on their part--stripping out a lot of the crap that has bothered people for ten years about .doc files because that data won't need to be transferred within the file. And then the files themselves would be more cross platform, requiring other systems and apps to only be able to translate the actual "contents" of the file. |
| #4 By 5444 (208.180.245.184) at 3/13/2002 12:37:17 PM |
|
sj,
datastore and file format are too different things. I can think of several other file formats that are propiertary and people don't complain about. Wordperfect being one, But yet I see programs all the time that work with Word Documents, WP documents even PDF documents (and to use some features of PDF you have ot pay for patent licences and it is the webs format for documents) Then who can forget GIF(wag the format in front of everyone thing it is free and then try to charge everyone after the fact) el. |
| #5 By 3339 (65.198.47.10) at 3/13/2002 12:56:19 PM |
|
I'm not talking about them eliminating ALL proprietary file formats, el. What I am saying is that a lot of the crap added to the .doc format were done so as to accomplish some of these datastore goals in a makeshift fashion. So if they are finally going to deliver this functionality and we'll finally be able to completely forget that .doc files are storing computer locations, authors, keywords, etc..., then they should get rid of that crap because those add-ons have actually been impairing the .doc format for a long time.
In other words, every so often Microsoft delivers something that they had been promising for years, over the years they have developed poor "near" answers, but when the new technology outmodes these makeshift solutions, the crap remains because they don't want to admit that it's a poor solution, nor do they want to do the work that they can't sell in an easy tagline or catch phrase. For example, I would want this to be accompanied by a complete overhaul of Outlook--the most inept and frustrating datastore MS offers. With them being involved in CRM now and with a DB file system, Outlook could improve substantially. But I doubt we'll see it. Such a datastore is a fantastic idea, but it really needs the joint development on the application side to make it useful, or eliminate some crap from the apps or docs themselves, or to even provide enhanced functionality not only to the datastore but to the app. |
| #6 By 3339 (65.198.47.10) at 3/13/2002 1:11:28 PM |
|
Before people jump on me, I read the comments here first and have read similar articles so I hadn't read the article before posting. I've read the article and they mention how--for this to be useful--they will have to rewrite Office, Outlook, etc.. and provide an API for other apps. That's exactly what I wanted to hear.
And of course, it exposes the issues and problems that they face, supporting two completely different file formats, sets of apps, and data stores simultaneously. This will be difficult for MS to pull off; I suppose the only way for them to do it is to build the apps that really benefit from this. After all, if it's just the file manager and other system apps that can use it, this will go no where. So I would say this is still a long way off--pieces will be in Longhorn but that'll just be another tagline for MS to hang their hat on. The apps needs to be there, then the file system will be useful, then it will take off. Before then, I think you'll have a hard time convincing both companies, especially companies, and developers that this is worthwhile--especially with people buying and developing exspensive and complex enterprise document management systems right now. (Some of these systems seem pricey now, say $50,000 and way, way, WAY up to implement, but that seems cheaper to me then replacing every single application and system in your company; so as these doc/workflow management servers develop--their cost versus the benefits of an entirely new system will be compelling, especially when, still, most users and corporations do not see what the benefit from such data management will be). This post was edited by sodajerk on Wednesday, March 13, 2002 at 13:15. |
| #7 By 5444 (208.180.245.184) at 3/13/2002 1:17:45 PM |
|
Outlook and Access for that Matter, will be reprogrammed to take advantage of the single datastore.
Outlook Express may or may not be. There are still alot of internal mechanisms for Word to handle in Document editing. Unless you see Windows itself becomeing the Document centric OS?? Which would be great in my mind. but other vendors may find it disenheartening. IOW why have WORD, EXCEL, POWERPOINT etc be seperate programs. I as a user should be able to choose the format I want in each of those basic functionality and program them together. Or for that matter If I like WP implementation of the spread sheet program better but like MS implementation of the word processor I should be able to link those programs into a seemless implementation. But going back to the doc format. if the file is stored fully as an XML document with versioning control with XPATH support, then yes I can see it being seperated. the DOC format may become a container for such features. much the same as PDF is for its own format. They may have to rename the extention though to distinguish between the old version. Or perhaps put it in the meta data as they do currently in the current doc format. But I would expect all vendors to play fairly and do the same thing.:) Sorry crossed in the posts. El This post was edited by eldoen on Wednesday, March 13, 2002 at 13:24. |
| #8 By 5444 (208.180.245.184) at 3/13/2002 1:31:56 PM |
|
SJ,
Thinking about it a little bit. Part of the Issue that may exist for a little while longer, is Supporting Win 9x systems. Some of the internal File system support in it may still need to be there for a couple of versions of Office. At least until Win 9x is phased out completely. Some of those features will need in system authencation to really work outside of word and Win 9x just doesn't provide that. El. |
| #9 By 3339 (65.198.47.10) at 3/13/2002 1:49:09 PM |
|
I would think there are bigger support issues than that, el. I don't see how this shift would be able to support NTFS simultaneously, but maybe there would be some form of backward compatibility. But, initially, this is clearly going to have a performance hit (I find network file performance slow already, never mind if my volumes are now "queries", however well they implement the system)--I would think that MS will want a clean room scenario for this radical shift without trying to support older apps and files. Oh well, MS simply can't resist forking their own system code base.
Even though MS has had signigicant shifts in code, file systems, etc.. they haven't really dealt with such an issue as big as this (DOS emulation is not a big issue). But, for example, when Apple shifted from HFS to HFS+ (a file format which is fully backward compatible and doesn't affect such a significant change) that took what 3-5 years, and there are probably still plenty of the old HFS files on a lot of machines. This post was edited by sodajerk on Wednesday, March 13, 2002 at 14:03. |
| #10 By 5444 (208.180.245.184) at 3/13/2002 2:40:23 PM |
|
I don't think there will be much of a performance hit on a NTFS driver that goes through to the sqlfs. Namely that is how it works in reverse now on a sqlserver system
Of course that all relies on how well they write the drivers Although I do agree that this transistion is a Years type change not an over night change. People still use Fat and Fat 32 in NT for example. In the long run haveing one file store allows MS to concentrate on improveing that datastore instead of having to continously deal with 7 or 8 different versions. El |
| #11 By 3339 (65.198.47.10) at 3/13/2002 2:56:12 PM |
|
I'm not sure I follow you in regard to performance (NTFS to sqfs, in reverse). This I anxiously await seeing though. We are talking about a database working across domains and WANS, integrating with Active Directory and Access, etc... I can't imagine trying to navigate a "directory" composed of documents which are actually located across the network, across volumes, which are being written to and opened, and constantly updated, and not see a substantial hit. I'd also like to see how they implement "object" record blocking--will you be able to edit files simultaneously but not the file system object itself, will files then get out of sync with the file system, etc... Personally, I also don't see how this will make a Windows system less breakable--it seems like it would be more breakable--a lot more breakable. Clearly, it's a wait and see issue. I won't call it vapor, because I'm sure they'll get there, but I wish MS would actually tell people a bit more and provide a roadmap. This article provided more info then I've learned from 40 articles over the past year. This is a very long haul. I guess even they aren't sure where they'll end up at the end of the journey. This post was edited by sodajerk on Wednesday, March 13, 2002 at 15:34. |
| #12 By 2459 (66.25.124.8) at 3/13/2002 3:54:51 PM |
|
.NET already puts an end to application installation troubles for the most part. Most .NET apps only require a copy of the files to a directory for installation. For uninstallation, delete the files. For ease of use, familliarity purposes, and file decompression, app configuration, etc. installation apps will still be included for most programs, though. This post was edited by n4cer on Wednesday, March 13, 2002 at 15:58. |
| #13 By 61 (65.32.169.133) at 3/13/2002 5:59:41 PM |
| Hopefully they learn from BeOS's pioneering that the filesystem can not be a full blown database, but rather its a file system with database features and abilities. |
| #14 By 2332 (129.21.145.80) at 3/14/2002 5:28:23 AM |
|
#28 - What distrobution of Linux uses a transactional database file store? Most Linux distrobutions use EXT2 (soon to be EXT3). These are node-based file systems that are, in many ways, poorer than NTFS.
BeOS had a truly transactional database file system, but they were not the first. The problem with transactional database file systems is that they tend to be slow. It's only be recently that hardware has gotten good enough to make it feasable. |
| #15 By 135 (209.180.28.6) at 3/14/2002 3:53:30 PM |
|
Haven't you heard RMD? Linux invented everything, even those things which don't exist on Linux.
|
| #16 By 61 (65.32.169.133) at 3/14/2002 4:57:59 PM |
| etx2 in fact is a big pile of doggie dung. Ext3 is better in that it (finally) has journaling capabilties/ |
|
Write Comment
Return to News |
Displaying 1 through 25 of 333 Last | Next |
The time now is
6:43:15 AM
ET.
Any comment problems? E-mail us |
