 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> > But they don't. Why not? I have no idea.
> Did you ask them?
Yeah, like they are going to answer me.
> And you can do that too. Click "open command window here"
Do they have that in Vista? There's an extension for XP (doesn't come by
default, naturally), but it only makes it just slightly less inconvenient.
> > It's extremely inconvenient and slow. I want a full list of a directory
> > with file sizes in bytes. That's all.
> 09/24/2009 18:39 231,936 XpsRasterService.dll
> 09/24/2009 19:00 3,068,416 xpsservices.dll
> 01/20/2008 19:48 942,592 XPSSHHDR.dll
> 01/20/2008 19:49 2,935,808 xpssvcs.dll
> 12/31/2006 21:00 625,152 xvidcore.dll
> 12/31/2006 21:00 120,320 xvidvfw.dll
> 09/18/2006 14:39 2,650 xwizard.dtd
> 01/20/2008 19:50 353,280 xwizards.dll
> 11/02/2006 04:19 94,208 xwreg.dll
> 01/20/2008 19:49 111,104 xwtpw32.dll
> 11/08/2008 17:38 <DIR> zh-CHS
> 11/08/2008 17:30 <DIR> zh-CHT
> 02/24/2010 16:09 <DIR> zh-CN
> 12/10/2009 20:05 <DIR> zh-HK
> 02/24/2010 16:09 <DIR> zh-TW
> 08/29/2007 17:06 61,952 ZIMF.DLL
> 04/11/2009 00:11 387,072 zipfldr.dll
> 08/29/2007 17:06 127,488 ZSPOOL.DLL
> 08/29/2007 17:06 52,224 ZTAG.DLL
> 2344 File(s) 1,122,038,817 bytes
> 98 Dir(s) 57,167,736,832 bytes free
I wish Windows Explorer listed it like that. But it doesn't.
> And I'm explaining why, under Windows, that question is ambiguous, by
> providing an analogy that shows "how big is it" doesn't always have a
> trivial answer.
You yourself gave an unambiguous answer in the above listing.
And Windows Explorer already shows the proper file size. The problem is
that it's rounded.
> > So what? I'm not interested in how much disk space the file is taking.
> But most other people are. Hence the default UI.
Windows Explorer doesn't show the disk space the file is taking. It shows
the size of the file (rounded).
It's MacOS X Finder which shows the disk space rather than the file size.
I have hard time believing Mac users are interested in seeing how much disk
space a file takes instead of seeing the file size. (I bet most of them don't
even know the difference and would be none the wiser if it was changed.)
On the contrary, it's irritating because it's very confusing. I'm not
really interested in how much disk space the files are taking. I don't do
anything with that info. (The only info which may be interesting to me is
seeing how much free space there is left, not how much disk space every
individual file is taking. That's just useless information.)
> > There are tons of way more useless features in Windows than this. Features
> > which almost nobody uses. They didn't have resource problems for those.
> And you have good statistics for what features get used most on Windows?
> Really? Where can *I* see those? Or did you work for that department in
> Microsoft or something else proprietary?
How many regular Windows users even *know* that there's a program called
'dxdiag' or another called 'regedit', much less have ever launched them?
*Those*, if any, are hacker tools, not regular user tools. Yet they are
like a million times more complicated than adding a simple option to
Windows Explorer, and they come by default with Windows.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> >> Didn't you tell me Haskell has a COM interface?
> >
> > Yes, but it doesn't compile on Windows.
> Are you sure it's "it doesn't compile" and not "I don't know how to compile it"?
I wouldn't even be surprised if it was a case of "I haven't even tried
compiling it; I just saw a random forum message about the subject a couple
of years ago". ;)
> OK, POV-Ray doesn't. It uses a different mechanism for some unknown reason
> to supply the "GUI Extension" function.
Which came first, COM or POV-Ray GUI extensions?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> If we start dropping everything that is not absolutely necessary, we could
> get a pretty bare-bones system.
Sure. Like, UNIX v7 or something. :-)
I'm not saying they can't be handy. I just don't find them particularly
useful myself, and I don't think they solve probems.
>> Oh, give it a rest, Warp.
> You are not giving me much reason to.
I haven't turned anything into personal attacks.
> And once again we have a hard-coded, specific feature which will work
> *only* for dll files but nothing else which might be similar.
Or use the registry. :-) And yes, I think that's sometimes a good idea,
because it gives you a place to leverage when you have to change something.
If all your configuration control is based on symlinks and then you want
something more powerful, it's very difficult to backpatch everything after
the fact.
For example, if you base your configuration on ini files, you're pretty
screwed if you need something more complicated, or if you want to go into a
multi-user system where individual users don't have permissions to change
global ini files. If you base your configuration on an API to read and
write ini files, then you can reimplement that API to store the ini files in
the registry or in a per-user directory. Unless, of course, you have a
program that bypasses the API and tries to write ini files directly into
c:\program files, which causes all kinds of trouble and hackage to fix.
Basically, you're saying "if you don't encapsulate stuff, you can use it
more easily for completely unrelated applications." I find encapsulation is
more future-proof.
> Generic solutions are much more useful than hard-coded, specific ones.
Sure, symlinks can be used for other things too.
>> The symlink solution works OK until the upgrade from libxyz.1.2.so to
>> libxyz.1.3.so breaks the program written to use libxyz.so.
>
> Yeah, I see how programs are constantly breaking when libraries are
> updated.
Were you, by chance, using UNIX variants before Linux had package
management? Because, ya know, I was, and it sucked.
> Seemingly you missed the "if the library is backwards-compatible" part.
That works great until the new library (say) fixes a bug the old library
had, and programs that worked around the bug now break, and programs that
expect it fixed break if you don't.
"Backwards compatible" isn't a binary choice.
>> And dont tell me it doesn't happen
>
> I don't remember personally ever seeing it happen in my computer.
> OpenSUSE repositories are pretty competent at handling dependencies
> properly.
Sure. If everything comes from the repository, you're golden. I'm talking
about stuff not from the repository.
>>> In other words, if version 1.2.3 of a library is fully backwards compatible
>>> back to version 1.0.0 of the library, the "versionless" library (eg.
>>> "libsomething.so") file will usually be linked to the 1.2.3 version of the
>>> file (eg. "libsomething.so.1.2.3"), as well as the several versioned files
>>> (eg. "libsomething.so.1" would be a soft link to "libsomething.so.1.2.3" if
>>> the latter is fully backwards compatible with version 1).
>
>> Yes, I know how that works.
>
> Then why are you asking for examples if you know that?
I hadn't remembered that one. Plus, I was really looking for an example
where *users* would care about symlinks, rather than system administrators.
You gripe that explorer doesn't let you make symlinks. That seemed an odd
gripe if the reason you want them is to manipulate shared library versioning
schemes. It sounded more like a gripe about not being able to have your
music library organized the way you want on your desktop.
> As said, if program A depends on libSomething.so.3 and program B depends
> on libSomething.so.4, and the latter happens to be fully compatible with
> the former, it would be a waste of disk space to have both. Instead, the
> former is simply made a symbolic link which points to the latter.
Yep. You don't really need a *sym* link for that, tho.
> What happens if you are dealing with something similar, but which is not
> a bunch of .so files which are loaded by a loader routine?
Give me an example?
>>> And before you start nitpicking about how that could be solved in other
>>> ways (which I'm 100% sure you will do), that was just ONE EXAMPLE of many.
>
>> Sure. Let's hear some others. Seriously.
>
> Why? For any possible example I could mention you will come up with a
> contrived reason why it's "better" to do it in some other way. Just for
> the sake of argument.
No, because I'm actually interested. Every time someone says "symlinks
rulez" I ask for examples. Virtually nobody gives me decent examples of why
someone would prefer them over hard links, except in very specific
circumstances having to do with crossing file systems.
>> How would a *user* use symlinks, is really what I want to hear. Not someone
>> managing software installations, but an end-user. Why would I want a symlink
>> in my home directory, for example?
>
> Have you ever heard of "shortcuts" in Windows? They are like a poor-man's
> symbolic link.
No, they're interpreted by the shell. They're more like aliases in bash.
> (Yes, go on an rant about how these "shortcuts" are so much infinitely
> better than symbolic links. After you have done, please explain to me why
> shortcuts *are* useful to regular users while symbolic links *aren't*.
Shortcuts are useful because they provide more than just a symlink. They
provide a place to store settings for an executable program, they eliminate
a "path" variable that's 90K long (given that there's no central authority
regulating what you name your program, and you wind up clobbering things if
you put everything into "/bin").
Given that, people have made shortcuts on their desktop to point to network
shares and such, so I see the point, yes. If Windows had symlinks before
shortcuts, Windows probably wouldn't have shortcuts and would probably store
the auxiliary information in a different part of the symlink file or something.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> But they don't. Why not? I have no idea.
>
>> Did you ask them?
>
> Yeah, like they are going to answer me.
I know. I was being mildly sarcastic.
> Do they have that in Vista?
Yes. Sadly, no "open administrative command line here".
> There's an extension for XP (doesn't come by
> default, naturally), but it only makes it just slightly less inconvenient.
Yes. (Lots less, actually, I've found.)
> I wish Windows Explorer listed it like that. But it doesn't.
Yep.
>> And I'm explaining why, under Windows, that question is ambiguous, by
>> providing an analogy that shows "how big is it" doesn't always have a
>> trivial answer.
>
> You yourself gave an unambiguous answer in the above listing.
That's only unambiguous because that's the one they picked.
> And Windows Explorer already shows the proper file size. The problem is
> that it's rounded.
Are you sure?
Actually, it's not showing the file size. It's showing the file last byte
marker. The file could have more data after that, or could be missing data
before that. I can give you a file that shows that number as three million
that has *no* data associated with the file, simply by deleting the bytes
off the start of the file.
>>> So what? I'm not interested in how much disk space the file is taking.
>
>> But most other people are. Hence the default UI.
>
> Windows Explorer doesn't show the disk space the file is taking. It shows
> the size of the file (rounded).
Not quite "size of the file", no. If there are holes in the file, or if
there are alternate streams holding data, neither of those is "the size of
the file". It's more "the place data would get appended were you to append
it to the primary data stream." :-) There's undoubtably an unambiguous name
for that that Microsoft has decided upon.
Perhaps "number of bytes you could read from the file if you first copied it
to a file system that didn't support the stuff NTFS does" or some such.
> It's MacOS X Finder which shows the disk space rather than the file size.
I can't argue for that. But I strongly suspect Apple has done more research
into what people want in MacOS than you have. :-)
> How many regular Windows users even *know* that there's a program called
> 'dxdiag' or another called 'regedit', much less have ever launched them?
I suspect quite a few have used dxdiag when their game didn't run, actually.
The regedit I'll grant you is probably only used by people knowing what
they're doing.
But now you're asking me to justify Microsoft not writing some piece of
code. I don't know. I'm just listing possible reasons, and you're saying
"that's not good enough for me, dammit!"
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-4-2010 0:39, Gilles Tran wrote:
> discussion : 4BC### [at] gmailcom...
>> On 21-4-2010 22:39, Warp wrote:
>>> I really got once stuck because I just *couldn't* find what I was
>>> searching for. I knew the string was in some files and I wanted to know
>>> which of them, but the damn thing simply refused to tell me, no matter
>>> what I tried. (IIRC I was searching for C++ files which include a
>>> specific
>>> header or something like that. I ended up having to figure that out by
>>> other means.)
>>
>> Seems like you have the same problem as me.
>
> Google for messages about search not finding [programming language name]
> files in [windows version]. The general trick is to tell windows to
> index these files and not just the default ones but how to do this is
> version-specific (and well-hidden, particularly in XP). It's indeed
> annoying (I have to search for this at least once a year) but it's not
> exactly difficult to find for folks who program for a living ;)
Matlab files with extension .m in XP
no luck but your google skills are way beyond mine anyway.
Do you have an idea why it would not find those or look into them
anyway? Because if I had a theory about that I could try to find a cure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Which came first, COM or POV-Ray GUI extensions?
COM was originally OLE, which was around in Win3 days. Certainly by Win98 it
was a well-established technology.
The only reason I said "unknown reason" is that the windows interface only
works on Windows. The reason for using INI files instead of the INI API is
portability, I'd expect. That wouldn't be an issue with COM and the Windows
editor/interface thing.
I don't know enogh about the history of COM and the Windows port of POV-Ray
to know whether COM could do what the GUI extensions needed when they were
written.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> With an extension? Or natively? I don't recall seeing anything about it
> in the docs. (I did find DDE, however. And registry access.)
That said, it's in ActiveState's teapot, so in a sense it's "native" and
"comes with Tcl".
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Do you have an idea why it would not find those or look into them
> anyway? Because if I had a theory about that I could try to find a cure.
Because it doesn't know how to index them.
It knows where to look in a jpeg to get the metadata. It knows where to look
in a Word file to understand when something is in a different language. You
don't want search finding "Fred" in a jpeg image body, or "Fred" in a word
document in Big-5.
You have to tell the search engine that .m files can be indexed like text.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> What do you *need* directories for? Useless. Just use a naming convention.
BTW, most microcomputer OSes, including DOS and CP/M and MacOS didn't have
directories. So, yeah. :-)
> If we start dropping everything that is not absolutely necessary, we could
> get a pretty bare-bones system.
You'd have FORTH, I expect. ;-)
> Have you ever heard of "shortcuts" in Windows? They are like a poor-man's
> symbolic link.
Thinking on this, one primary difference is that shortcuts don't
*automatically* get followed if the program doesn't specifically prevent
that. I'm not sure that's as useful as the ability to have one file that
acts as a reference to another file.
See, here's my thinking. Given that people don't really type long paths on
Windows very much (at least not as much as UNIX), having a program follow a
link like that automatically doesn't especially seem helpful, especially if
it points to a file system with different semantics (like a network share,
say). Pretty much all but the simplest programs on UNIX have to handle
symlinks anyway, whether they're recursing a directory (like find or grep or
backups or whatever) or whether they're just moving files around (like "mv"
needing to know if it's the same file system or not). A user on Windows
tends to launch a shortcut and it comes up in a window, whether it points to
a file or a directory or something. If they're navigating, they're doing it
one step at a time, so having it happen automatically in the middle of a
path doesn't seem as useful in that situation. But maybe usage patterns
would be different if they were around earlier, sure. Shortcuts were clearly
a hack to support not having a huge PATH variable that grew into a more
general mechanism over time.
(BTW, Windows2000 supported junction points, which are the higher-level
abstraction on which mounted file systems and symbolic links and remote
files are all based. Again, it just didn't come with the OS, but you could
buy programs that did it. Just FYI.)
> (Yes, go on an rant about how these "shortcuts" are so much infinitely
> better than symbolic links.
BTW, I'm not the one "ranting". I'm discussing stuff rationally, I think.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-4-2010 21:21, Darren New wrote:
> andrel wrote:
>> Do you have an idea why it would not find those or look into them
>> anyway? Because if I had a theory about that I could try to find a cure.
>
> Because it doesn't know how to index them.
>
> It knows where to look in a jpeg to get the metadata. It knows where to
> look in a Word file to understand when something is in a different
> language. You don't want search finding "Fred" in a jpeg image body, or
> "Fred" in a word document in Big-5.
>
> You have to tell the search engine that .m files can be indexed like text.
>
Ah ok. And how do I do that? I'll find out next week after some deadlines.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
