World: r3wp

just the fact that we've got two intepreters using the same extension 
makes the whole issue even worse.

really, there should be two executables.  One which does all of that 
fancy stuff, and another which just doesn't do anything.  no install, 
no security.

two intepreters using the same extension

 - you mean rebview and rebcmdview? Core doesn't set or require an 
 extension.

R2, R3.

but cmd and normal too.

I'll check about the viability of the multiple executables model, 
but it looks like installation-related rebol.r settings are more 
likely.

my point is that install is very annoying for people who develop 
because it creates a dependency in the interpreter which cannot be 
rooted out.


I am not against the installer, i'm just against it being forced 
upon me, when the whole platform itself has no requirement for it


I have not started REBOL without it requiring an external file or 
socket in what 10 years... so really what is the point.  it just 
makes EVERYTHING complicated, like telling clients they have to fuck 
around with adding -qs all the time in their batch code, etc, etc.

vista doesn't even allow arguments in shortuts, so that's even more 
annoying.

Which is why the rebol.r settings.

hey, if the executable can reliably read rebol.r, then that's cool. 
 its also MUCH simpler for networked install, since you can lock 
down the permission on rebol.r so that every one launches the same 
way.   if we really need user.r... then just provide its path within 
rebol.r and load it from there.

also, if the security can be lowered within rebol.r without requiring 
a windows popup... again cool.

Sorry, on Windows you can't know where it is safe to look for user.r 
without going through the same information-gathering process that 
an installer has to go through. So it's the same problem.

ok I think my main grievance is that the "installer" is within the 
rebol.exe  it has to be a separate executable which does the information 
gathering, copies and creates all the files.  but launching rebol.exe 
should never again ask for installation.


if that is how you are thinking about it then, I don't mind installation.

The "copying files to some location" is the least difficult part 
of an installer. The tricky part is determining exacty *where* to 
put stuff. Fortunately, most of that is ahead-of-time research about 
where to look in the registry and environment for settings, where 
to put them, etc. And that varies depending on the Windows version 
because the really good tricks weren't adopted until later.

yes I know all about that, and its really fucked up in vista/7.  
for an application not being able to write in its install path is 
ridiculous.

much better to store files in 3 different places, forget about them 
and fill up the disk, with the user totally unable to know where 
to and how to cleanup his disks.

We need to have a way to have the program not install and not bring 
up the desktop without command line parameters, from the same executable 
that will under different circumstances offer to install. It's one 
of the modes I mentioned.

oh and did you know that in vista (and possibly windows 7)  the names 
for windows paths are translated in the explorer but remain english 
in the file structure?


such that you can actually have the same folder twice within an explorer 
view  :-)   yep, great engineering.

Maxim, "its really fucked up in vista/7" - no, those rules have been 
there since Win2k.

I first started complaining about the installer in 2000. Some of 
my recommendations have been implemented, but not all. And 2 more 
standard installation profiles have been added since then.

Any multiuser Windows has this problem.

the way I see it, the moment there is a rebol.r file in the same 
folder as the rebol.exe, no install should ever be required, whatever 
the rebol.r file contains.

the rebol.r file should operate before the sandbox is activated. 
 it needs access to the secure command, so it can prevent the sand 
box from ever starting.


If it can be made that simple, then install-away all you want.   
:-D

folder aliasing is new vista, and its a very stupid idea.  using 
the same path you end up at one file for read another for write? 
 wtf!

Yes, it can be made that simple, but the rebol.r also needs to be 
able to mandate the installer if need be, or to start portable app 
mode. It depends on its settings.

Folder aliasing is there to make up for silly people who still write 
apps that try to write to their application path without sufficient 
rights. If people had paid attention to the rules in 2000, we wouldn't 
have this mess now - Windows apps would be acting like Linux or Mac 
apps, and putting their files where they should be.

I agree, as long as the rebol.r *enables* has final control and nothing 
requires to be stored in registry, its all good.


obviously, windows will want some stuff in the registry for its own 
management, but rebol should not peek there to try and determine 
anything.

if it really has to.. put that registry peeking in the rebol.r

oops  the *enables* isn't from that sentence... ignore.

installation would simply be the act of running rebol.exe without 
a rebol.r file and generating a default rebol.r file in your current 
setup.

If rebol.r is loaded before the security settings are established, 
we don't want any code in there at all, we just want settings. We 
still need the installer; rebol.r will at most tell the installer 
to run, but it won't itself contain the installer.

one thing that could alleviate the fear or running code in rebol.r 
is if rebol.exe couldn't itself write to it... ever.

And the installer would need to peek in the registry, since that's 
where locations are stored.

yes on install time, you have to peek, but not when running.

if rebol.exe couldn't itself write to it... ever.

 - Great, now you understand the reason for Windows security settings! 
 Yay!

I don't want a registry setting that stores "rebol is installed", 
for example.

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.