World: r3wp

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.

Cyphre, can't the user set up an environment path for linux fonts?

anyhow... all I meant is that windows should have started from scratch, 
learn from past mistakes and build the leanest/cleanest OS they every 
built, instead we end up with an install which takes several GBs 
on disk and 2GBs of RAM minimum to run.

And then the uptake would have been nil. Remember, from a business 
standpoint the best feature of Windows is its ability to run Windows 
apps, even the crappy ones. Lose that ability, lose the upgraders.

Unless you don't want apps like AltME and other ones that act the 
way you have requested to run on Vista/7...

that's the point of having a full VM installed in the transition 
period.  yess it takes disk space, but at least you only keep the 
legacy things within the legacy environment.  they could have gone 
100% 64bit for example and not have to support 32 bit modes within 
the 64 bit and also distribute a 32 and 64 bit version, things like 
that where there are already many *current* apps which fail in one 
or the other.  my friend can't get her camera to work on windows 
7 cause its only compiled as a 32 bit app (drivers and all).  but 
she was forced to use a 64 bit win7 because of support issues.

this sounds like it should be in Windows and not here ...

We were discussing installation issues on Windows. Since writing 
an installer for Windows (and other platforms) is the current activity 
towards the next R2 release, it is the topic of the day here. Remember 
when I said I wanted feedback here? It fianlly arrived :)

I admit we went into a side thread  ;-)

I prefer to think of it as Maxim being a useful sounding board. He 
helped me work through some of the trickier issues through being 
a devil's advocate :)

has anyone been able to install rebol on windows 7 so it executes 
with -qs arguments?

what do you mean by "so that it executes" - just tried it and it 
seems to start...

not installed under program files, though

First, thanks to Brian for making sure this gets done right (or at 
least the best we can given the circumstances :-). Getting the installer 
right is part of the battle, but another part is making sure we, 
as  developers, do the right thing as well. The effort to identify 
system direcories, and provide mezzanines to make it easy to use 
them correctly, benefits everyone.


The old Roxy installer code is all BSD, and I'm happy to provide 
it, even if just for fodder.

Was that the open source installer for the SurfDetective?

Yes.

As I recall you never released it as there was no documentation or 
something

There are open source installer-builders for Windows that I can read. 
I've even used some of them. What I'm weak on is other platforms, 
particularly Linux. I want scripts to be able to run on Linux the 
same as on Windows, so corresponding concepts should have corresponding 
settings.

Quite possible, knowing me. I don't remember if SURFNet released 
it or not, but I don't think I ever did.

Brian: What would be one such "corresponding concept" and how would 
you use it from within REBOL? (Assuming that meant REBOL scripts 
by "scripts").

The trick with installers is making sure the program reads from the 
right places after it is installed. That was a big problem for View 
after Win2k came out: You could write an external installer, but 
REBOL kept looking for settings in the wrong locations in the registry.

Yes, the sys-vars module in Roxy is a crude start on that, so you 
don't know about Documents and Settings versus ~ or Program Files 
versus /usr/local/bin.

What was always missing in R2 was the ability for a programmer to 
get system information in easy to use way.

user-name (actuall real login of running task)
user home and related dirs

things like that which should be in the next release, especially 
if you are going to rummage through all of this.


I used routines to get to some of this, but I think it would be nice 
if this was built-in.

Andreas, corresponding concepts:
- The place where the program is installed/located.

- The place where the installed program version is listed, so you 
can know whether an update is needed.

- The place where user files, particularly the view-root and desktop 
files, needs to go.

- The place where machine-specific user settings should go (console 
layout on Windows).

- File associations, where possible. Not assuming that these are 
possible on platforms other than Windows.


Where these go depends on the installation profile. Yes, not installing 
at all is one of those profiles.

Ah, so the scripts you were talking about are installer scripts.

No, I mean scripts at runtime. Installer scripts are platform-specific, 
but once things are installed, the scripts at runtime should be platform-agnostic.

That's nothing to do with an installer then, has it?

Adrian, "so it executes"  I meant installing rebol in the OS via 
file extensions so it always uses the -qs arguments over and above 
those it gets from the explorer.


also can shortcuts have arguments in win7?  this was removed in vista.

So every one of these concepts needs a runtime setting that tells 
user scripts where stuff goes.

What was always missing in R2 was the ability for a programmer to 
get system information in easy to use way....I used routines to get 
to some of this, but I think it would be nice if this was built-in.


So every one of these concepts needs a runtime setting that tells 
user scripts where stuff goes.

Agree++

Andreas, the installer determines these things at install time, and 
sets things up for the runtime. but the runtime has to look for stuff 
where the installer puts it, and previously R2's runtime looked in 
the wrong places.