Re: Organization of files
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sat, 14 Jan 2006 12:29:58 -0500
See below...
On Tue, 10 Jan 2006 16:31:13 -0500, "Steve Russell" <srussell@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
>I always appreciate the editorial flavor, Joe! I still remember my very
>first MFC post and the reply you had for me.
>
>A couple of questions, please:
>
>What's the biggest you would allow an executable to become? I am not
>particularly interested in a large exe, but it would be helpful to hear your
>answer. I do expect to hide some proprietary things by making them
>resources rather than letting them exist as separate files.
****
This is really more a matter of taste and engineering. I'd have to see what the reesult
was, and decide what its impact on performance was, before I'd figure out what a number
is.
My gut reaction is that given your suggested quantity of images and sound clips that the
executable would be unwieldy.
Some years ago, I had to put a 40MB database on a 10MB laptop. It was an inventory with
lots of cross-references to other parts. What I did was create a sequence of n DLLs
(where n was determined at generation time), where the first DLL had a very large
STRINGTABLE and all the other DLLs represented text fields as STRINGTABLE indices. I got
the 40MB database down to about 5MB in about twenty DLLs. It ran on a 33MHz 386 with
respectable performance, and I forget what the laptops were, but the customer assured me
that it was a great performer. Given the alternative was that it wouldn't fit at all,
this was a big plus. I did LoadLibrary/FindResource/LoadResource/LockResource, and on a
16-bit Windows environment, this meant that all the storage management was done by the
operating system, a big plus.
***
>
>What exactly do you mean, in this context, by "extensible"?
***
In this case, I was thinking of the problem of adding more images or sound clips. This is
fairly difficult if they are resources, trivial if they are files. The way we 'extended'
the database I just described was that every Monday the salescritters loaded up their
laptops from the compressed database that had been generated late Friday afternoon.
(Remember, we didn't have CDs as an option in those days!) The database could also fit on
six floppy disks, so on Friday afternoon, there was overnight Fedex to the remote
salescritters, so they had new disks by 8am Monday (Internet? Broadband? We were in an
era where 2400 baud modems were state of the art!)
They used that system until laptops with built-in CD readers made it unnecessary.
>
>My image files are the emf's that I refer to in the prior post. Art created
>in Macromedia Freehand. So perhaps your comments about metadata were based
>on another interpretation of what I appeared to be saying/asking?
****
By "metadata" I was referring to the problems of concepts which are non-hierarchical. For
example, a clipart object showing a beer-drinking group can be classified (and I just did
this search because I needed clipart of a beer stein) as "beer", "people", "men", "keg",
"mug", "party", etc. In particular, pictures are usually complex enough that they can fit
into multiple categories. So the metadata used to retrieve information can be very
complex, particularly for human-oriented rich objects such as images and sounds. This
makes hierarchical organization difficult.
Also, I've found that trying to do distributions where many subdirectories are involved
can be a real royal pain. I once had a client for which I wrote a Windows application to
replace their MS-DOS BASIC (not VB, real BASIC!) application. They insisted that I keep
the same file organization so there was complete compatibility. File paths three to five
levels deep. This was the year I stopped dealing with installation problems, saying "I've
written the code. You write how to install it." because they wanted an installer, in the
days before there were really good installers. Some years later, I worked on a similar
project where the people were using InstallShield. It was the Install Problem From Hell
(it wasn't helped by the fact that InstallShield came with crappy documentation; both the
online and the printed documentation referenced each other and each was hopeless, but
trying to figure out what was going on was a complete disaster; the tooling didn't work;
and the scripting language implementation was so buggy that I would have given the project
a failing grade had a student turned it in).
However, given you want to protect information by putting it in resources, I'd suggest the
DLL approach. For one thing, it reduces the executable size. It has a set of files
compatible with most concepts of installers. There are even options for LoadLibraryEx
which suggest that loading the DLL can be more efficient than the general case.
But without any good idea of the size of your problem, or other details, these are just
random ideas. Your Mileage May Vary.
I'm leaving tomorrow for two weeks with no Internet access, so if you don't hear from me,
it's not because I'm ignoring you. Or, more properly, because I *am* ignoring you, but
I'm ignoring everyone else (I'm an equal-opportunity ignorer). Most of the rest of today
is shot as well, because we are going to be very busy momentarily. I was just checking
for last-minute issues when I saw your email.
joe
****
>
>Your comments about directories are very helpful to me -- pretty much what I
>wanted to hear, I guess.
>
>Thanks a lot!
>-------------
>"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
>news:53t7s1lg22061q709ldvjbigk80jodoo3c@xxxxxxxxxx
>> The notion of hierarchical organization is usually risky, because it is
>> very limited. For
>> example, is a picture about a car pulling a trailer to be treated as
>> "vehicle",
>> "pictures\vehicle\auto", "pictures\vehicle\trailer", etc. Is the sound of
>> a car
>> screeching to a halt and crashing categorized as "sounds\car\stopping" or
>> "sounds\accident"? What you;ve stepped into here (and I mean this in the
>> way you might
>> step into something found on the street) is the "metadata problem".
>> Presumably you have a
>> way of deciding how you have organized this information.
>>
>> As to which resources you include in the executable, that's entirely up to
>> you. The
>> difference is one of size. If you include hundreds of image files and
>> thousands of sound
>> clips, you are going to have a truly massive executable, and the set of
>> resources will not
>> be extensible. If you distribute files, you have a smaller executable,
>> and the set of
>> images and sounds could be extended.
>>
>> There is no real limit to the number of files in a directory. Large
>> directories are hard
>> to manage, but most imposed organizations are at best whimsical. For
>> example, you could
>> do some broad categories, or just take the filenames and put A-F in one
>> subdirectory, G-M
>> in another, etc.
>>
>> Now the issue of the metadata comes up. Where are you storing the
>> metadata? If you put
>> this in a resource, you can't extend the set of objects. You could keep
>> it in a text file
>> which you read, or my own preference, which would be in a database that
>> mapped attributes
>> to filenames. This would also allow for extensions after release. I'm
>> not a database
>> expert these days, but I'd become one if I needed to solve this problem.
>> joe
>>
>> On Mon, 9 Jan 2006 22:35:19 -0500, "Steve Russell"
>> <srussell@xxxxxxxxxxxxxxxxxxxxxx>
>> wrote:
>>
>>>In the next several weeks, I expect to complete my first windows
>>>application, built primarily with C++ in MFC. I will have hundreds of
>>>image
>>>files across various categories by subject matter, and probably several
>>>thousand small, compressed audio files organized in a number of ways.
>>>
>>>By nature and profession, I am very organized. But I need help in
>>>understanding what factors to consider in regard to using multiple folders
>>>in my release directory, and how to decide what resource files to possibly
>>>include in the exe itself. Is there such a thing as too many files in one
>>>directory? Is it reasonable to simply dump all my emf and audio files in
>>>the release directory? Etc.
>>>
>>>Could anyone point me in the direction of some good reading and/or provide
>>>some comments on this subject? Maybe a list of criteria that govern this
>>>final stage?
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@xxxxxxxxxxxx
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: Organization of files
- From: Steve Russell
- Re: Organization of files
- References:
- Organization of files
- From: Steve Russell
- Re: Organization of files
- From: Joseph M . Newcomer
- Re: Organization of files
- From: Steve Russell
- Organization of files
- Prev by Date: Re: Changing Text Color?
- Next by Date: Re: Simple CEdit question
- Previous by thread: Re: Organization of files
- Next by thread: Re: Organization of files
- Index(es):
Relevant Pages
|
Loading
