Anyone an expert on the WinXP file system?

49 thoughts on “Anyone an expert on the WinXP file system?”

1. “people need a database method that will last 30+ years”

   Why? The storage medium and computer won’t last that long. Electronic Archives shouldn’t be designed as forts, but rather as bucket brigades of data.

2. The SMB protocol (used by Windows) and the Windows filesystem is not well documented at all. If someone has been able to find good documentation on it, please let me know as well.

3. Ironically, the XP filesystem is being overhauled for Longhorn. Although this next generation file system (WinFS) will be vastly more suited to storing and searching photo metadada because it merges RDBMS and file system semantics/api’s, it’s likely to be no more long-lived than anything we have right now.

4. John: I understand that MSFT will periodically change its implementation of the Windows file system. However I expect these changes to be more or less transparent to users. For example, they can’t throw away all of the extra properties attached to files when a person upgrades to Longhorn because Microsoft Office appears to rely heavily on the info in those properties. And basically the photographer is getting a free photo database upgrade at the same time he or she upgrades his desktop OS.

   Basically my idea is that the user is already stuck maintaining/upgrading/whatever his or her Windows file system so that might as well be used to the max extent possible.

5. (Warning: I am not a Windows shell programmer, but I fancy having a crack at this anyway, as someone who has occasionally wandered through MSDN. Once I have posted this response I will point my Windows-programmer friends at it, and they will doubtless laugh at me. But since this is the best way of getting them to post corrections, here goes.)

   The simple answer to your first question is: msdn.microsoft.com

   There, I found this document on creating property sheet handlers, which is what you’re talking about. You usually need to write Windows API code in C/C++ for these (though some environments like IBM’s excellent Sash wrap nice abstractions for this at the cost of whacking great runtime installation). You register them in the Registry against the file classes (e.g. Image) that you want them to appear on.

   The bad news is that these Property Sheets aren’t pulling the metadata from any special metadata area outside the file, such as Mac OS Resource Forks (though whether this is actually a bad thing is arguable, given the problems I’ve had when trying to move files from Mac OS to other filesystems/OSes). Property Sheets have to know how to dive into the file data to do the get/set work.

   As for Indexing, that’s where it gets a little better – see the documentation in this tree about extending the Indexing Service. (apparently you want to implement an IFilter interface) However, I’ve heard very mixed things about the Indexing service’s reliability.

   In other words, what all this amounts to is various extensions relatively high up in the OS rather than low down near the filesystem, so they’ll be nicely integrated with a few bits of the Explorer shell but little else. There are already quite a few share/freeware implementations of the kinds of extensions you want, so it’s worth looking around to see if they give you the complete functionality you’re looking for. Also, as has been much trumpeted, metadata takes a big step forward in Windows when Longhorn finally arrives (whenever the hell that is) but at the cost of a nice, simple hierarchical FS (the new WinFS will be much more like an RDBMS). As for other OSes, you may want to look at projects like GNOME Storage, though that’s very much in alpha.

6. Interesting – I had thought that the summary fields were added when you installed Office, rather than being a native file system capability.

   You may be interested in looking at Pixvue (www.pixvue.com) – a freeware Windows explorer extension that among other shows IPTC and EXIF annotations as extra panels in the Properties dialog box.

7. Folks: I created a .txt file in Notepad and augmented it with some title, category, comments, etc. info. The extra info is visible from the Windows Explorer tools but when I do a Dired in GNU Emacs it shows the file, which contains “foo bar” as only 9 bytes in size. Opening the file in Emacs shows only the “foo bar” contents that is visible in Notepad. Wouldn’t this indicate that Windows FS has some other place to store information than in the bytestream of the file? I.e., that there is in fact a Macintosh-style Resource Fork somewhere in NTFS?

8. NTFS does have the concept of “streams” (I suppose similar to mac resource forks). Your typical file is only contained in and is using the default stream, but you can add any number of streams to a file and keep info in there. Whether or not streams are used to store the extra properties, I am not sure.

9. Part of the FS. “When a volume is formatted with NTFS, a Master File Table (MFT) and other special file system metadata files are created.” in http://www.microsoft.com/whdc/hwdev/tech/storage/ntfs-preinstall.mspx

10. Sounds to me like it is a combination of things, like EXIF for images, and some other location. But is sounds to me like that data wouldn’t be copied if you sent it to a non-MS file system or use a non-Windows transfer method, which would make it easy to lose the data.

    I have been thinking about the same thing, I won’t start a database in a propriatary format for the same reason you won’t. Now I am a programmer but although I am long on ideas, I am short on time and the result is that I have no database at all.

    What I would prefer is an open image database standard, XML based, that anyone can implement and if one product is discontinued, you can simply use another.

11. Here’s an interesting treatment of the subject from a security perspective: http://silverstr.ufies.org/blog/archives/000363.html.

12. Interesting. I’m thinking about a new application that would use the Windows file system as a database too. My question is can it handle a folder with a million files in it?

13. Phil, I am sad to see you go over to the “Microsoft Way” as it were. Why don’t you just write up something simple with TCL/TK or one of the freeware Lisps that run on Windows and other OSes too?

    How tough would it be to store relatively trivial amounts of data (say enough metadata for 20,000 pictures) in flat files, dbm-style indexes or even just binary Lisp files, just putting the actual images in some set of private directories. With today’s RAM-hungry machines, no one will notice your app using 10MB to store the contents of the database in RAM while the app is running.

14. I looked into using Windows’ extra properties, too, but as you saw with EMACS, the metadata isn’t in the file, except when it’s an image (EXIF). My solution was to store the metadata all in EXIF (using a free utility called Jhead (http://www.sentex.net/~mwandel/jhead/)from Matthias Wandel) AND put all the info in my RDBMS. This way I get the functionality of the RDBMS, but the images themselves also have a copy of the metadata built right into them. EXIF image data isn’t dependent on NTFS, but I have found that it doesn’t stick when the images are copied to CDs.
    What about using a text-file-based indexing system? XML, or even regular HTML, index pages could list all the images in a folder, providing not only the text needed for indexing, but also a cross-platform time-stable thumbnails page.

15. Dave – I don’t see why not, but you have to be VERY careful with this. A few years back I was working on a server app hosted on NT4 which kept a good few thousand files in a cache dir. We accidentally left an Explorer window open on that dir and it slowed to a crawl, as it was redrawing the file list every time the dir contents changed (which was several times a second).

    As for the other stuff, I have had my first feedback from a couple of coder friends (thank you, Richard and Charles) and they say I was half right – some property handlers (e.g. JPEG, JFIF) talk direct to the file, others (such as .txt metadata) use alternate file streams (as Michael suggested). However, these streams only exist on NTFS format – if you try and copy them to a FAT partition, you’ll get a warning about metadata loss. (More importantly, these streams aren’t available over Samba, as far as I can tell) As for Office docs, apparently these are “OLE Compound Docs”. (No idea.)

    If you want to look at the data streams on an NTFS file system, check this out.

16. More on optimising NTFS (especially when it comes to large numbers of files in a single folder) here

17. Patrick: I’m all in favor of writing Lisp code but not to solve a problem that might already be solved with software already on 98% of consumers’ desktops.

    David LaR: Jhead sounds like a good idea except that Microsoft isn’t cooperating with Canon and Nikon so you end up with RAW files and I’m not sure that they have the same EXIF format (though obviously they have some way of storing all the camera settings info). Windows XP does seem to be pretty smart about indexing the EXIF data, e.g., I can search for “Casio” and find pictures taken with the Casio camera borrowed for the Mexico City trip.

18. Canon and Nikon’s RAW formats store the shooting information in a EXIF format in a small JPEG file with the extension .THM, next to the main CRW/NEF file. Microsoft is actively working on metadata in Longhorn, and will almost certainly include basic photo management functionality in that OS, so even if you do not use NTFS/WinFS metadata to manage your files, you should consider stuffing a copy of your information there as it is likely to be the standard for PC apps, the way Adobe is trying to push their XMP (http://www.adobe.com/products/xmp/main.html) out-of-band metadata architecture for the high-end.

19. Oh, and going beyond photos only, Microsoft also has an interesting research project called MyLifeBits (http://research.microsoft.com/barc/mediapresence/MyLifeBits.aspx), run by Gordon Bell, no less, that aims to organize ALL of your life’s digitized documents in one data store. It looks like one of the few Microsoft Research projects with some chance of turning up as a useful product.

20. If the goal is something which will survive the ages, then you’ve also got to consider that Windows may not be the dominant platform 30 years from now, therefore portability *must* be a key requirement.

    A completely file based solution that doesn’t rely on embedded attributes of the file object would be portable and therefore draw interest from Windows, Mac, Mac *nix, and *nix communities, plus, would support any file object.

    A tcl or Python or [insert scripting language here] based solution that uses a plain text method (pickled data, a seperate object information file (oif), or what have you) to store metadata would be far more portable both across platforms and within platforms (future proofed).

21. Following up, in my work building image repositories (business imaging) we don’t much care about longevity, although business images tend to use well adopted standards which have stood the test of time – longevity remains an issue of migration planning, not technology. For business it works.

    For individuals I’m less confident.

    So many users of digital cameras don’t even know how to manipulate files in their file systems. “You can delete / move / copy those? Wow!” This doesn’t give me confidence that photos snapped digitally within the past 10 and perhaps the next 10 will survive the test of time. I’ve long wondered if the family “photo drawer” will be a thing of the past as their history is truncated and lost during various data accidents.

    In addition to portability mentioned earlier, platform accessibility may be an requirement to move higher on the list. After all, there are far more *nix based web sites hosting personal sites, and therefore photos, than Windows based web sites. I’m making a large inference from various web hosting account surveys out there which show Apache based systems fully dominating the WWW at the moment.

    Would it not be highly desirable to have a solution that runs on *nix platforms therefore?

22. Philip-
    It seems to me that the stumbling block is making the standard Windows “Search” operation work. Otherwise, I think the same problem lies in other digital collections like MP3 collections. My music database is just a bunch of directories on my disk filled with MP3 files. Somehow, every player program seems to be able to interpret this structure and make use of the ID3(?) tags for metadata. What’s the difference with digital photos?

23. Not sure why the word “Search” ended up as a link. I didn’t intend for that to be a link…

24. Instead of looking for an implemented system that will last the longest, look for features that you can expect will be implemented the longest. I would argue that rules out any peculiarities of Windows filesystems.

    While you could implement something that uses only files, as others have suggested, you’d still have to re-implement the whole application some day. I’m betting AI won’t be available yet, so you’ll still have to code it in 30 years. I think you can do better than this by using a 2-tier architecture.

    Rather than selecting the database with the best prospects for longevity (probably Oracle), choose any database you like, and use only basic SQL. MySQL or SQLServer, or even the MS Jet database engine, might be decent options. Of course those all probably suck, but they do implement basic SQL, and no one has invented a robust yet small and easy to use database. When they do, you’ll migrate to that one. If you keep it simple enough, migration can be as simple as exporting a few CSV files and importing those into a spreadsheet.

    For the interface, you have lots of options, but Java probably has the best prospects of longevity, other than C, without requiring low-level coding. Again, I would avoid the more esoteric features so that your application would compile with just about any JDK. Maybe just use a small collection of basic JSP’s to provide a web interface, rather than a stand alone application. Don’t bother with complicated stuff like JDBC connection pools, just use the simplest possible database connection since it’s only for one user.

    You could use perl, PHP, ASP or ADP as well, I won’t debate that, but my choice would be JSP because I like it, and I think it has a critical mass of developers that will keep it alive longest. The venture capitalists may well insist on it.

    Of course it won’t last forever, and you’ll have to re-implement some of it in 30 years, but this gives you the best chance of postponing that re-implementation as long as possible, divides the implementation into 2 simple tiers, and minimizes the scope of reimplementing either or both of the tiers when it becomes necessary.

    Or you could just put photos in a bunch of directories with a basic naming convention, burn them to CD for backup, and rely on preview, thumbnail, and image-searching applications getting better and better over the next 30 years.

25. An earlier poster was on the right track. NTFS uses an “alternate stream” to store this info. These links might get you started in the right direction:

    http://patriot.net/~carvdawg/docs/dark_side.html
    http://www.howtodothings.com/showarticle.asp?article=447

26. For those suggesting the EXEIF block in jpg, keep in mind that the ideal long-term solution won’t rely on one particular file format. Even now PG is using RAW and JPG, so some of his files already probably don’t have EXEIF. Something with a common meta data storage method, whether a separate store or something built into the file system would seem to be better… and, it’ll let him get that new camera in a few years with the new 3-d image format.

    Admittedly, for long-term storage, staying with publicly well-documented formats will be better than anything that you may not be able to read when the software or its supporting company dies out.

27. Ok … a quick primer:

    1. A file system is a database. It is not a relational database — but is perfect for the type of application you are proposing. To Dave’s question of can it handle a million files — the answer is yes. I’m not sure about 10M tough.

    2. There are at least 3 different “windows” files systems. FAT is old DOS compatible file-allocation-table. Upper limit on total disk size (I believe it’s 2GB). FAT32 is an “extended” version of FAT — supports partitions up to 4GB initially but I believe you can have up to 64GB with recent versions. NTFS has had a number of incarnations — but NTFS is fundamentally equivalent to the OS/2 file system (which Microsoft developed with IBM way back when). NTFS most recent version supports AFS (alternate file streams). The behaviour some users earlier in the thread described about not being able to “see” properties when viewed from Emacs is *an* example of how AFS may be used by the Shell (which in my opinion is not part of the OS) to “enhance” the user experience. The underlying apis for maniulating the file system are well-documented and have been non-volatile for many many years.

    3. OLE Compound Files (which was used by native Office applications — particularly Word and PowerPoint as their native/proprietary storage system) are, in essence, file systems embedded within an outer file. Within a compound file you have “property streams” (sometimes called “bags”) that allow you to build up an associative-list like set of key/value pairs. You also have ability to create files, folders, etc. and manipulate them with OLE document APIs. The Windows Shell knows about certain “well-known” compound documents and thus is able to provide the enhanced user experience. NOTE: With Microsoft’s shift towards using XML as native format (let’s not get into debate about their licensing) — some aspects of the compound document format are lost.

    4. The Windows Shell provides many of the user-facing enhancements. It’s (relatively) trivial to extend the shell’s namespace so that one can: a) provide extra property pages for an arbitrary file type; b) provide custom context menu for any arbitrary file type; c) build into the desktop a modeless appbar that’s always visible (there are 3rd party examples of chat panels, etc, RSS readers, etc.). If you extend the shell you are also extending IE — for example if you create a custom toolbar — it can be in the system taskbar, withing a toolbar in any folder explorer or IE directly.

    5. Longhorn is the future codename of the next MS OS. WinFS is the name for the new file system that is a hybrid of NTFS and RDBMS. NTFS will *always* be there — sometimes you’ll hear/read the phrase “file-backed storage”. This is what will certainly happen in Longhorn for “legacy” files of not only Microsoft applications — but all others (jpeg, gif, .wks, .123, .flw, .rtf, etc…). A key aspect of WinFS that *could* be leveraged by an application developer is that WinFS storage can be replicated against a schema and WinFS will take care of the voodoo of doing that replication between the “peers”. Schema is the key word here: you have to define the schema, register it with WinFS, etc. and then build the application that does the CRUD against that distributed data store. MS has made it clear as mud that core Office apps (Word, PPT, Excel) won’t be re-architected to use WinFS at the schema level (apart from outside the file meta-data). An example, Word is not being re-architected to operate at the word/paragraph/style/charrun level and use WinFS to store document contents at this granularity. But — they have made clearer statements about how WinFS could be used to build next-generation PIMs (Outlook). Imagine a future were everything you placed in Outlook was synchronized across your various devices… but this is the future and I’d not encourage somebody to go in this direction until longhorn is much closer.

    6. Certain file formats are de facto now — but were created before the age of “standardized meta-data”. Newer file formats such as MP3 have built-in meta-data. Older file formats that used compound document storage have similar meta-data capability (see property stream above). Trying to be all things to all file types is a thankless job … but restricting to certain well-known file types is another matter.

    So … back to the task at hand. You could build a hybrid architecture that used a single meta-data file (I’d use XML and XPath). You have to make a decision as to whether or not the filename should be human consumable (GUIDs are readable but not necessarily understandable except as indirect token). You need to build viewer for the single-meta data file. At this point you’re still not tied to a specific platform (depending on technology used to build viewer). To do the final level of integration you could then extend the viewer to be used as deskbarband (toolbar, explorer bar), namespace extension (custom menu and property pages), and/or IDTExtensibility2-provider (this gives you a toolbar in every major MS application). While this last set of integration steps would tie you to all of the currently supported Windows OS’s — the actual amount of code to do this is < 50KB (source/compiled). Additional advanced integration might then include drag/drop and clipboard integration. This would all be platform specific — there is no magic bullet that any single OS or runtime environment offers at this level.

    If you want to learn more about how to build these types of extensions — I highly recommend http://www.codeproject.com — a Window’s-focused website that has tremendous amount of tutorials and “free” code to help bootstrap you. There is a 8-step shell extensions tutorial for example. Other tutorials show how to utilize alternate file streams, build toolbars, build explorer bars, etc.

    -phil

28. Has anyone thought of asking museums and archives what they use? I’ve heard that the Smithsonian’s efforts are meant to last far more than 30+ years… They’re the pros. Surely they’d have good suggestions.

    I’d heard that they were even copying music and sound archives onto some kind of laqueur disks (long-term LPs) so that they could be used even if civilization crashed… simple tech without need for any particular kind of sophisticated hardware or software player.

29. Back to first principles, please.

    The Windows filesysystem is a red herring. Property sheets for storing metadata are specific to the filetype (e.g. MSWord properties on MSWord documents, provided MSWord components), or they are provided by the shell (Explorer).

    Although the number of machines using this configuration is stupefying, there’s no guarantee any of it will last 30 years. Computers get old, operating systems improve, and eventually there’s a limit to how much legacy data you’re able to migrate forward.

    Furthermore, reliance on embedded metadata presumes that it will be copied over faithfully with media transfers. Hard disks won’t last 30 years (and if they do, will we be able to read them?), so there will likely be a lot of copying going on. Anything intrinsic will be preserved, so the metadata may be lost though at some point, simply because it is not stored intrinsically with the data.

    More realistically, the limitation should be anything that can be stored and universally retrieved from an lowest common denominator, like an ISO 9660 filesystem — a CD. Many of these photos will likely be archived to CD at some point in time. No special tricks, no being too clever by half — just store a bunch of (plain data) files on any filesystem you happen to have nearby. Anything that provides directories and files of data should suffice.

    What about the metadata? It’s going to be stored externally to the images anyway, so just store it externally. In a text file. Use whatever format makes sense: XML, Lists of key/value pairs, sexprs, steganography, whatever floats your boat.

    The drawback is that Windows won’t index this for you automagically out of the box. The benefit is that the barrier to entry is so damn low, anyone can write a program for this in any programming language, provided they’ve been writing code for at least a week. And that will encourage addons and applications for Windows.

    Funny. This is pretty much what iPhoto does, except for the bit about the text files.

30. Reiser4 has everything you need to accomplish this, you should seriously look at it. http://www.namesys.com

31. Adam- why would metadata be stored externally to the file? Isn’t this what the EXIF stuff is all about?

32. I’ve thought extensively and even written about this subject over the past year (http://www.tallent.us/CommentView.aspx?guid=82e76def-d0eb-495e-b2c5-0356df398051) as my digital photo collection has grown into the multi-DVD category. My conclusion: The *ONLY* long-term storage option for metadata is within the image file itself. This is the only way to ensure that the data will last as long as the photo. EXIF and ITPC are the best options for now, and, as you’ve noticed, Explorer has some support for them. I have an open-source project going (ok, stalling) called JpegHammer (http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=22112d14-8cd1-4301-9fc1-24300cdeaf75) to help manage EXIF metadata without dealing with Explorer’s limitations. JPEG will eventually give way to JPEG2000 and other formats, but it is bound to be with us much longer than PCX was. Even when the inevitable conversion process is necessary, software will easily be able to retain that information. My rule: think about the 30-year mark. What operating system were you using 30 years ago? What storage media? What file system(s)? Do you expect the *next* 30 years to bring more change or less? This is where the file system and database arguments fall apart. Personally, I want my grandchildren’s grandchildren to have a rich photographic record of their family, and I’m doing everything within reason to give them quality content. It will pale in comparison to their 3-D “walk-around inside” hologram photos and videos, 128-bit color, and microscopic detail, but it will be something.

33. 30 years is a long time in the tech world. Gates could look like Ozymandias by then.

34. Philip,

    You might want to look at the following document on the MSDN site: “Windows 2000 UI Innovations: Enhance Your User’s Experience with New Infotip and Icon Overlay Shell Extensions” by Dino Esposito. (http://msdn.microsoft.com/msdnmag/issues/0300/w2kui/default.aspx)

35. This is an important topic, so much so that Microsoft is dedicating
    1/3 of the next Windows (Longhorn) development to WinFS
    (other two: Avalon/XAML for GUI, and Indigo for Communication/XML messaging).
    I wander why did they need to add SQL server if NTFS was enough?

    Question: how to link together related files?
    I.e. same image if different sizes.

    A) I do agree that OS-embedded properties/description is a nice place
    for adding metadata. Just need a export/import utility. Good idea.
    By the way, this works on Windows 2000, too.

    B) Metadata in JPEG and MPEG is already used by both cameras and software.
    Extending Windows shell means installing some software.
    And if this is needed, why not install software that will use metadata inside
    JPG/MP3 etc. This solves major problem of copying data and metadata together,
    as well as portability across platforms.

    C) The simplest solution is to have a simple text file (.TXT) with the same file name
    as a Image (.JPG etc.) or music (.MP3 etc.), with name=value pairs, line by line.

    D) Index file: Index.HTML or Index.XML with custom schema and application.
    This is OS independent, same like C). I am doing this way.

    The most important is TRANSFORMATION of data, this is the key for the evolution.
    Computers are quite good in this, in particular if data are structured
    or semi-structured. So, when the Longhorn comes, just run some import utility.
    And Longhorn GUI does look nicer of XP…

    Would the Samantha be written on XP nowdays?
    When PhilG speaks, people listen.

36. I can see a lot of potential problems with this approach, as others have mentioned.

    If you sketched out the design for an open-source version of iPhoto (which was a bit more photographer-friendly), do you think there’s any chance you could get many people to help you with it?

    Or, I’m sure there is at least one program vaguely similar to what you’re looking for. There’s plenty of crappy open-source software out there that’s a great starting point for good open-source software!

37. How about storing the metadata in EXIF (where possible) AND in an additional txt file.
    When you upload the file from your camera, have a small app create the txt file(s) from the EXIF infos.
    Then, you can add to the TXT file/EXIF info whatever fields you want.
    Also, define a new field (as an unique guid) to indentify a “shot”. That is, this field should be the same for all the copies derived (by alterations/conversions/etc) from the original shot.

38. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odeopg/html/deovrworkingwithdocumentproperties.asp
    This give some information about working with file properties. The information in the file properties is I beleive still stored in the file itself, not in some other linked file.

39. Here also an useful article:
    “Microsoft aims for search on its own terms”
    http://news.com.com/2100-1008_3-5110910.html

40. Jeff, Apple has an article about the Smithsonian: http://www.apple.com/pro/photo/jones/ (yes, I realise this is mostly an ad for Apple).

41. Code Project, which was already named, has a series of articles on Windows Shell extensions
    http://www.codeproject.com/shell/shlext.asp there’s a number of articles on it there, should be able to find the rest easy enough. I agree with others though, that assuming that doing it as part of the windows filesystem because you want it to last 30 years just doesn’t seem logical. If indeed longetivity is a quality of the windows filesystem (and I doubt it is) then this quality is an emergent one, not integral. It strikes me to build projects on something if the quality you consider preeminent in your project is found in the object as an essential quality.

    of course if I was gonna do it I would probably go for the quick hack route and customize imgview.htt, mentioned in http://msdn.microsoft.com/msdnmag/issues/0600/w2kui2/default.aspx which I think was also pointed to elsewhere in these comments.

42. Store the photos in a simple directory structure. Keep an XML ‘database’. XML being plain text should hold up against the ravages of time and directories are directories, you will not lose any data copying from fat32 to ext2 to ext3.

43. I have been thinking about writing a client-side javascript application for this, so a photo archive can be used from a browser. Or probably adjusting this JAlbum photoscript (http://www.datadosen.se/jalbum/) as a basis. However, I never made work of it.
    But think this possibly could be a good solution. If javascript or javabeans are gone, they photos are still in the file system.

44. Yes, I would seriously consider reiser4.

45. What a hoot: Engineers, you gotta love them. Obsessed by the beauty of their weapons.

    The first comment is the only one that is correct.

46. Philip, can I suggest OpenACS ? Especially in a double-click install incantation (which we are working on), it seems to answer all of your requirements 😉

47. Rather late to (return to) the party, but have you made up your mind about all this? Are you going to write the tutorial and/or software? Any chance we may be publishing a philg article on photo.net sometime soon?

    Personally, I’m mostly interested in any design considerations, since I am “between systems” myself. I have a Win32 / Paradox DB (please don’t laugh) application on my PC. It suits my search needs quite nicely, but it’s very platform dependent and doesn’t easily interface to the web.

48. In your free time, check the pages about small business loan | small business loan | http://www.small-business-loan-ebanking.info/ | <br/> card credit processing | card credit processing | http://www.card-credit-processing-4u.info/ | <br/> loan officer | loan officer | http://www.loan-officer-e-bank.info/ | <br/> shoe | shoe | http://www.shoe-e-shop.info/ | <br/> analize debt | analize debt | http://www.analize-debt-advisor.info/ | <br/> mortgage interest rates | mortgage interest rates | http://www.mortgage-interest-rates-ebanking.info/ | <br/> repair debt | repair debt | http://www.repair-debt-ebanking.info/ | <br/> modular home financing | modular home financing | http://www.modular-home-financing-ebanking.info/ | <br/> 2nd mortgage | 2nd mortgage | http://www.2nd-mortgage-e-bank.info/ | <br/> best credit cards | best credit cards | http://www.best-credit-cards-advisor.info/ | <br/> credit equifax report | credit equifax report | http://www.credit-equifax-report-4u.info/ | <br/>- Tons of interesdting stuff!!!

49. weight loss pill http://www.nofatonline.com/

Comments are closed.