World: r3wp

no, rebol is an interpreter, it can write to any file... for my own 
application to write within my own install dir is perfectly fine. 
 its not going to affect any other application.

I would understand for an exe not to have to write anywhere else 
THAN its own install dir, or even maybe a specific directory, within 
the original install dir.

(within the windows folder)

Imagine that you are a least-privileged user, but evil. Do you want 
to write to a directory that contains programs that are run by other 
users?

Anton: regarding the DRAW fonts on Linux. The font redering is supported 
(at least it worked on all distros I had to use in recent 3 years 
or so). The essential problem is how to automatically get the paths 
to your Linux truetype fonts so you don't need to specify the font/name 
with absolute path as it is now....

If anyone knows about any efficient method how we could get path 
to the font files on Linux so it works on all distros let me know. 
Solving this issue would definitely improve the DRAW font usage a 
lot.

brian, I do understand the issues, its just that windows thinks obfuscating 
things is security.  shared files here or there are still shared.

the windows file organization is so screwed up in EVERY conceivable 
way that it will never be fixed.

There are group policy settings that can make it so that programs 
can only be run from certain directories, and security settings to 
make it so only administrators can write to those directories. And 
the only reason that they have to do things so drastically is because 
of developers like you who insist on writing Win9x apps and trying 
to run them on Win2k+. Apps like AltME.

Yes, it's screwed up, but the screw-up is because permissions are 
user-based rather than app-based. This problem is shared by Linux, 
OS X, and most other Unix-serived OSes.

serived -> derived

It's a common mistake in OS design, and in some cases one that is 
mandated by law (DOD rules).

the way I see it, applications should be FORCED into using specific 
paths for specific things.  then you could enforce proper file access 
etiquette.

but when I say forced, I don't mean spread up all around the disk 
and forgotten on uninstalled, untraceable deep paths, masked by the 
explorer, and even translated on top of it.

I mean like each application is forced to put its dependecies into 
specific folders within its install path.  this way you can very 
easily verify that things are wath they should, and can make OS lib 
calls which act with confidence.

the root problem for all of this lies in the archaic tree structure 
file systems.

a file should be able to have several paths (a bit like symbolic 
links in unix)  each one with different properties based on app context.

Sorry, there's no user-specific folders under the install path, not 
without separate user folder permissions maintenance for each application, 
or those aliases you mentioned. Is it really so hard to put user 
files in user folders? You have to do that on Linuc and Mac...

but some files Are not user files... like the rebol.r file, for example. 
 it should define where the user files are though.

That is platform-and-computer-specific. And the user files will be 
in a different place for each user - that's the whole point of them. 
Is it really so hard to put files in the standard user directories?

its hard when the damn paths are so obscure that you need to call 
the OS using libs to get the paths confidently.
its hard when those paths change all the time.
its hard where there are more than one path per application.


its just really complex when the darn paths could be simple... even 
on linux, they keep changing the paths almost every release on some 
distros.. it gets ridiculous.

I mean, you wouldn't complain about using the HOME variable on Linux, 
right? It's the same thing.

(note that on linux I am not talking about the home or user dirs.)

The paths change all the time, but where the paths are listed don't 
change. That has been pretty consistent for 10+ years.

Well I *am* talking about the user dirs. This whole conversation 
has been about user dirs.

hopefully with MS recent october 22 announcement of the canning of 
XP we can finally forget that OS for install targets :)

R2 still supports Win95. R3 still supports Win2k.

At least installers would be easier for R3, even if R3 doesn't need 
an installer yet.

ICarii, AltME is currently a Win95 app (it puts its writable data 
files in the same directory as its program file) and it's written 
in R2.

You can write modern apps that will run on Win95, even with proper 
multi-user directory usage; just don't use Unicode.

brian, if windows actuall made the home directory something obvious 
and not tried to hide it in every conceivable way in the explorer 
I think the situation would be much better.


Vista/7  makes some of it better, then screws it up in another way... 
it just gets weirder at every release.

in any case, I am happy we see eye to eye in the role of the rebol.r 
file.

The only weirdness in Vista/7 comes from the need to support roaming 
profiles. Windows is built around multi-user, multi-computer use 
over a whole enterprise. It took them a while, but they are finally 
starting to get it right in Vista/7. The only sucky things come from 
having to run apps that don't play by the 10+-year-old rules. So, 
would you prefer that those workarounds be gone and not be able to 
run AltME on Vista/7?

I wish they had gone the OSX path and started fresh, with a built-in 
VM for XP/win2k support.

it would have done the whole APi a hell of a lot of good.

Maxim, the rules you are complaining about were there for Win2k/XP 
apps too. Apps like AltME just ignored them. The only difference 
now is that the rules are being enforced.

Look up "Windows 2000 logo compliance" - same rules.

So you aren't comparing Classic, you are comparing running OS X 10.1 
apps in 10.6.

But they do have a VM for Win2k/XP apps; it's called Windows XP Mode.

well, they just relax the enforcement... the rest of the os is still 
there... they still support most of the old api, its still just a 
tack-on more stuff and try to make it compatible again.  I know some 
of the kernel changed, but that doesn't really affect applications 
that much, since that is mostly doing stuff behind the API wall.

I am talking about  mac classic /OSX  cleanup.    basically what 
vista was supposed to be, but really just changed the skin.  not 
much really changed.

but they did rename and move a lot of things, for no purpose a part 
from annoying the hell out of everyone, still they are the same components.

that will probably happen in the next OS they are taunting us with... 
their cloud OS thing.

1) Making the user directories finally work with roaming profiles, 
even though the registry settings to make them work have been there 
forever. 2) Enforcing the Win2k rules, but allowing Win9x programs 
like AltME that still break them to still run, but safely now. 3) 
Getting rid of the spaces in the standard directories so stupid Unix 
ports work, but aliasing to the old directory names so stupid ancient 
Windows programs still work. Not "for no purpose" at all.

And by aliasing in this case, I mean Unix-style symlinks. Only the 
new directory names are really there - the old, localized names are 
just symlinks.

And all because people keep hardcoding the English localized names 
instead of looking it up like they should.

what i meant is that windows, without any historic reason for the 
changes, has not really improved that much in vista/7.

there are a few nice new things, yes.  but all the old crap is still 
there to provide compabitibility.

well on disk there exists only the english names... the linking is 
only available in the explorer.

when you do a dirlist in rebol, you get the english name (like "users" 
instead of "utilisateurs")

Compatibility, yes, but not exact compatibility. The new behavior 
is now a way to approximate the old unsafe behavior in a safe way. 
So it is not bug-for-bug compatibility.

Do DIR /a.