 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>
>> I put the task bar on the side. I can probably put 40 tabs on there
>> before it gets close to full.
>
> Logically that makes sense - especially if you have a widescreen
> monitor. But that would just be too weird - for no better reason than
> "it's not what I'm used to".
It wasn't what I was used to etiher, but I got used to it really quickly. I
resisted for years myself.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> I mean, I realise that hypothetically a regex can find things that a
>>> normal search can't. But in reality, when are you *ever* going to use
>>> that? What would it be useful for?
>>
>> For example, finding where in the file a symbol is defined instead of
>> used.
>>
>> I do that all the time. "Where is the definition of this macro?"
>
> As I say, I've never needed to do that. (Then again, I don't work with
> other people's code, only my own.)
Lucky you!
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> 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. And dont tell
> me it doesn't happen, as I have not infrequently binary-edited libraries
> to change the strings there.
BTW, that said, I think it's more like this was a problem,a nd rather than
write code to fix the linker, people started making quicky patches using
symlinks.
Its a quick and simple solution to something that plagues MS for years and
years. I just don't think it's the *right* solution. I'm more of a code
and API kind of programmer than a file system and file format kind of
programmer.
>> This is not a question of "bad configuration".
>
> Inadequate configuration. The program itself should be telling you which
> versions it's compatible with, and the loader should be enforcing that.
> The fact that you *can* do it with the file system doesn't mean that's a
> *good* way to do it. :-)
Oh, and you'll notice that Linux goes thru all the libraries when it starts
anyway to gather up version information, and you'll notice that GNU has
defined a library format that has a textual description of which libraries
you *really* want to load. Both of these are a better (IMO) solution than
using symlinks. And not because Windows doesn't have symlinks, but because
it's less fragile.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> > So in order to get Windows Explorer to show exact byte counts, I would have
> > to download and install Visual Studio, get it to work, write an extension
> > manually, install it, and keep it with me in an USB stick so that I can
> > install it in a friend's computer if I ever want to see the byte sizes there
> > as well?
> Pretty much, yah. Same as any other program you write. What did you expect?
I expect Windows to support such a *basic* feature as showing the sizes of
files in bytes. It's not like it's too much to ask. I'm sure someone at MS
could add the feature in 5 minutes. In fact, I wouldn't even be surprised
that they *already* have the feature but it has been disabled with an #ifdef,
so all it would take to support it is one additional #define.
But they don't. Why not? I have no idea.
> You mean if I want to indent files the way I like, I have to download emacs,
> write some elisp code, then stick it on a USB stick and carry it around to
> every other emacs-enabled computer?
Yeah, because indenting code is in the exact same league as showing file
sizes in bytes rather than rounded.
> > I think you made some kind of claim containing the word "trivial" in some
> > post of yours.
> More trivial than rewriting the shell. A 50-line program is pretty trivial, yes?
No. Trivial is "click here and here, and you are done".
You have a rather odd definition of "trivial". It still sounds like "not
impossible".
> >>>> And which byte count do you want?
> >>> The size of the file. How many bytes it contains. If I opened it with a
> >>> program and started reading bytes, how many I would get before EOF.
> >
> >> Open it raw, or processed, or for backup?
> >
> > You are nitpicking, and you know it.
> You're nitpicking. You want exact byte counts in one window but not the
> other.
What? What window? What other window? I have no idea what you are talking
about.
The only thing I want is an option somewhere that, when checked, will make
Windows Explorer to show file sizes in bytes instead of rounded to kilobytes
or megabytes. That's it. Nothing less, nothing more.
> It's trivial to get that information
I don't want to "get that information". I want Explorer to use bytes when
listing files and their sizes. "Getting" is too laborious. I don't want to
"get" anything, I want it to show it without me doing anything to "get" it
explicitly.
> yet you complain it's difficult.
It's extremely inconvenient and slow. I want a full list of a directory
with file sizes in bytes. That's all. I don't want to have to open some
separate info dialog on every single file just to see the size in bytes.
That's just crazy.
It's not like it would be away from anybody. If someone doesn't want to
see the sizes in bytes, he just doesn't use that specific option. It's that
simple.
> Plus, you can't even clearly define what it is you want to see.
You know *perfectly* what I mean, so stop acting stupid. You are just
arguing for the sake of argument.
> > Is agreeing with something really so hard?
> I already agreed. You kept bashing at it.
"you can't even clearly define what it is you want to see" doesn't sound to
me like agreeing.
> > So if I want to see the individual byte sizes of 20 files, exactly how do
> > I do that "with one extra step"?
> "dir"
You have an odd definition of "one extra step".
Pressing the keys 'd', 'i', 'r' and return is certainly not enough. There
are quite many additional steps involved, including going somewhere else than
Windows Explorer.
> > Each file in a list having its size shown with a different unit is
> > confusing. You can't visually see which of the files are larger and
> > which ones are smaller.
> Click the size column header and it sorts by size.
That doesn't give me visual feedback on the sizes of the files. It only
tells me which files are larger than the others. It doesn't tell me how
much, unless I start deciphering the units one by one.
> >>> Except that it doesn't tell that. If you try to copy it to another file
> >>> system or an archive file, it will most probably end up taking a completely
> >>> different amount of space.
> >
> >> Hence the "which size do you want" question. :-)
> >
> > The amount of bytes in the file. What's so damn hard to understand about
> > that?
> OK, now I ask you "how big is the directory? What's its size? How many bytes
> in that Linux directory? What's so damn hard to understand? I just want to
> know how many bytes are in it."
I'm not interested in the size of a directory. I interested in seeing the
sizes of the files in bytes, that's all.
(Seeing the total size of the files in bytes without having to do anything
extra to get it is useful as well, but a somewhat different issue.)
> "How big is that process? How many bytes does it take in memory? What's so
> hard to understand about that?"
I'm not interested in that in this context.
> Copy the file to another system or an archive file. That's three different
> sizes. Copy the file to another file system may or may not lose the
> compression. Copying it to an archive file is going to need it to carry the
> encryption and ACL overhead as well as alternate streams. That's exactly my
> point.
So what? I'm not interested in how much disk space the file is taking.
I'm interested in its size in bytes. If disk usage is what one wants, *that*
can be put in some info dialog or whatever you want.
> > The amount of bytes in the file. What's so damn hard to understand about
> > that?
> Because first you ask for the amount of bytes in the file, then you ask for
> the amount of bytes you'd read if you opened and read the file. And that's
> two different numbers.
Why do you keep nitpicking? You understand perfectly what I'm talking about.
> >>> Yeah, start doing that to a dozen files, rather than seeing it in one
> >>> glance in the file listing. It *is* extremely inconvenient.
> >
> >> If I want the total, I pick a dozen files and say "properties" and it tells
> >> me the total.
> >
> > Do you have reading comprehension problems? I was not talking about totals.
> The "that" wasn't really clear there. "Start doing that to a dozen files"
> doesn't really say whether you mean "one at a time" or "all at once."
If Windows Explorer showed sizes in bytes for each individual file *and*
for the total (in the status bar), then it would solve both problems at
once, without the need to open any info dialogs. See? Easy.
> I'm not defending Microsoft per se. I'm just saying you seem to think
> there's some big important reason for this feature not to be here.
Well, I have yet to see a good reason for it to not to be there.
(Except Microsoft's incompetence. This is certainly not the only
annoying feature which worked ok eg. on Windows 3 but MS decided to
screw it up for newer versions just for the sake of making it different,
even at the cost of making it usable.)
> I just
> think it's that it didn't sell more copies of Windows. There would be no
> downside to providing it except the need to spend resources providing it.
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> What do you *need* symlinks for?
What do you *need* directories for? Useless. Just use a naming convention.
What do you *need* long file names for? 8 characters are plenty for any
amount of files you might need. Useless to have anything larger.
What do you *need* Windows shortcuts for? It's not like the system
couldn't work without them.
If we start dropping everything that is not absolutely necessary, we could
get a pretty bare-bones system.
On the other hand, other people find convencience features useful.
> > You might yourself believe that, but I don't think it's true. I'm pretty
> > certain that if Windows had supported soft links from the very beginning,
> > you would today be defending them. (You would *especially* be defending
> > them if Unix/Linux didn't support them, I'm pretty sure.)
> Oh, give it a rest, Warp.
You are not giving me much reason to.
> >> I think soft links are an abomination, and I've
> >> only ever seen them used to basically correct flaws in software
> >> configurations.
> >
> > Linux distros use them frequently to, for example, make "aliases" of
> > libraries of different versions to an actual file which is fully compatible.
> OK. Windows puts this information in the files themselves, and the code asks
> to load the library with the compatible version. Or it looks up the
> registration in the registry. (Hence the name, you see.)
And once again we have a hard-coded, specific feature which will work
*only* for dll files but nothing else which might be similar.
Generic solutions are much more useful than hard-coded, specific ones.
> 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.
Seemingly you missed the "if the library is backwards-compatible" part.
If it isn't, then it will not be sym-linked so that programs will believe
it's the same library, of course.
> 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.
> > 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?
> > This is not a question of "bad configuration".
> Inadequate configuration. The program itself should be telling you which
> versions it's compatible with
Most programs do. You can use the 'ldd' utility to check which .so files
they depend on, and usually they do have the version number. (Then if you
check the actual .so file itself, you'll usually see that it's a soft link
to a compatible version of the library.)
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.
> and the loader should be enforcing that. The
> fact that you *can* do it with the file system doesn't mean that's a *good*
> way to do it. :-)
Instead, you want to hard-code such specific features as .so file versions
into a loader routine.
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?
> > 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.
> 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.
Why would a user need those?
(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*.
You are insinuating that symbolic links would be completely useless for
regular users. "Shortcuts" are functionally the same, and are being
constantly used in Windows. Are you arguing they are also completely
useless?)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> From what I've seen, you can't touch COM unless you're programming in
>> C or C++.
>
> Nonsense. Every programming language and every scripting language
> supports COM that I've seen.
I've yet to find a language that can do it.
> Didn't you tell me Haskell has a COM interface?
Yes, but it doesn't compile on Windows. (That's The Real WTF, right
there!) Then again, a few people have hinted that it's possible to do
things like COM, ODBC, etc on Unix too...
> I know Tcl does.
With an extension? Or natively? I don't recall seeing anything about it
in the docs. (I did find DDE, however. And registry access.)
> OK, I'll grant that maybe postscript doesn't do COM. Whoops, nope, I
> take that back. Ghostscript supports COM.
PostScript does a lot more than many people realise...
> What language have you used on Windows that does *not* do COM? That
> would be like having a language on Linux that doesn't support
> environment variables.
Java, Smalltalk, Eiffel, JavaScript, Tcl, Haskell, POV-Ray (well, duh!)
As far as I know, none of them support it. (As I say, there's a Haskell
library, but it doesn't work. And even if it did, some documentation
would be nice...)
>> Last time I checked, neither WSH nor Power Shell comes with Windows.
>> You said "all of this is trivial using only the scripting tools that
>> come with Windows". So how exactly do you do this then?
>
> They both come with Windows.
>
> Obviously "last I checked" didn't include googling before you posted.
As I posted in another thread, it appears that WSH now comes with
Windows. Obviously this is kind of game-changing; it changes it from a
novel curiosity to something that might have a real-world use...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I expect Windows to support such a *basic* feature as showing the sizes of
> files in bytes.
It does. It just doesn't show it *where you want it*. It has shown file
sizes in bytes since before there were windows involved.
> I'm sure someone at MS could add the feature in 5 minutes.
Uh, no. Nothing happens in five minutes in MS. How long do you think it
takes to even translate the help files and header text into 105 different
languages?
> But they don't. Why not? I have no idea.
Did you ask them?
>> More trivial than rewriting the shell. A 50-line program is pretty trivial, yes?
> No. Trivial is "click here and here, and you are done".
And you can do that too. Click "open command window here" then click "d" and
then click "i" and then click "r" and then click "enter."
> You have a rather odd definition of "trivial". It still sounds like "not
> impossible".
No, I mean adding your own extensions is well supported and well documented.
A small extension is short.
But no, it's not in there by default, and they could add it as easily as
they add any other trivial feature, but they haven't.
>>>>>> And which byte count do you want?
>>>>> The size of the file. How many bytes it contains. If I opened it with a
>>>>> program and started reading bytes, how many I would get before EOF.
>>>> Open it raw, or processed, or for backup?
>>> You are nitpicking, and you know it.
>
>> You're nitpicking. You want exact byte counts in one window but not the
>> other.
>
> What? What window? What other window? I have no idea what you are talking
> about.
The properties window or the cmd.exe window.
> The only thing I want is an option somewhere that, when checked, will make
> Windows Explorer to show file sizes in bytes instead of rounded to kilobytes
> or megabytes. That's it. Nothing less, nothing more.
I understand that.
> 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
>> Plus, you can't even clearly define what it is you want to see.
>
> You know *perfectly* what I mean, so stop acting stupid. You are just
> arguing for the sake of argument.
I know what *you* mean. I'm just saying that it's not as simple as you
think if you want it usable by more than just you. Perhaps you're just used
to open source, where you can scratch your own personal itch *and* get it
into the official distribution?
>> I already agreed. You kept bashing at it.
>
> "you can't even clearly define what it is you want to see" doesn't sound to
> me like agreeing.
I agreed it would be trivial to put something like this in Windows. I didn't
agree that you can clearly define what you want. ;-)
> You have an odd definition of "one extra step".
If you want sizes for multiple files, then yes, it's maybe five seconds of
work instead of two extra clicks. Maybe four or five mouse clicks, and then
four button presses.
>> OK, now I ask you "how big is the directory? What's its size? How many bytes
>> in that Linux directory? What's so damn hard to understand? I just want to
>> know how many bytes are in it."
>
> I'm not interested in the size of a directory. I interested in seeing the
> sizes of the files in bytes, that's all.
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.
>> "How big is that process? How many bytes does it take in memory? What's so
>> hard to understand about that?"
>
> I'm not interested in that in this context.
It was an analogy to explain why what *you* want isn't what everyone else
wants. You want "how big would this file be if the only access was
UNIX-style access".
> So what? I'm not interested in how much disk space the file is taking.
But most other people are. Hence the default UI.
> I'm interested in its size in bytes. If disk usage is what one wants, *that*
> can be put in some info dialog or whatever you want.
Indeed, it is.
>>> The amount of bytes in the file. What's so damn hard to understand about
>>> that?
>
>> Because first you ask for the amount of bytes in the file, then you ask for
>> the amount of bytes you'd read if you opened and read the file. And that's
>> two different numbers.
>
> Why do you keep nitpicking? You understand perfectly what I'm talking about.
I'm nitpicking to show that what *you* ask for is different than what many
other people might ask for, even tho they'll all describe it the same way.
I *do* understand what you ask for. Then you ask me "why can't Microsoft do
that?" And I'm explaining that what you ask for isn't general enough to
sell to hundreds of millions of people, and then you get mad for trying to
explain that.
> If Windows Explorer showed sizes in bytes for each individual file *and*
> for the total (in the status bar), then it would solve both problems at
> once, without the need to open any info dialogs. See? Easy.
Indeed it would!
>> I'm not defending Microsoft per se. I'm just saying you seem to think
>> there's some big important reason for this feature not to be here.
>
> Well, I have yet to see a good reason for it to not to be there.
The same reason there's no future value calculations in the calculator. It's
a lot of work for Microsoft to put features in.
> 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?
--
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:
>>> From what I've seen, you can't touch COM unless you're programming
>>> in C or C++.
>>
>> Nonsense. Every programming language and every scripting language
>> supports COM that I've seen.
>
> I've yet to find a language that can do it.
I've named half a dozen. What languages do you use?
>> 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 know Tcl does.
>
> With an extension? Or natively? I don't recall seeing anything about it
> in the docs. (I did find DDE, however. And registry access.)
http://www.vex.net/~cthuang/tcom/
Extensions *are* native. Tcl is a language for writing extensions in.
>> What language have you used on Windows that does *not* do COM? That
>> would be like having a language on Linux that doesn't support
>> environment variables.
>
> Java, Smalltalk, Eiffel, JavaScript, Tcl, Haskell, POV-Ray (well, duh!)
> As far as I know, none of them support it.
In other words, you didn't take the time to google
java "com interface"
smalltalk "com interface"
eiffel "com interface"
tcl "com interface"
before you said you have no languages that support it.
Javascript per se doesn't, but jscript does, which is pretty much the same
thing with a different name.
OK, POV-Ray doesn't. It uses a different mechanism for some unknown reason
to supply the "GUI Extension" function.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
