World: r3wp

>> exists? to-file "c:\rebol\rebgui\enfacecmd.exe"
== false
>> exists? to-rebol-file "c:\rebol\rebgui\enfacecmd.exe"
== true

Seems to be big functional differences on windows at least.

Mostly around driver letter and slash direction handling. I suppose 
the question then is, why doesn't to file! do what to-rebol-file 
does ... I don't see the point in using to-file to create an "invalid" 
file ... a bit like having both a to-decimal and to-rebol-decimal 
for example.

>> to-file "test.exe"
== %test.exe
>> to-local-file "test.exe"
== "test.exe"

to-local-file makes sense to me, it's the need for both to-file and 
to-rebol-file I'm curious about.

TO-FILE is only for datatype coersion. It makes sense to have both.

Uh? All the to-* datatype conversion functions are implicitly to-rebol-* 
... why the need for a to-file that can produce "invalid" rebol file 
types and to-rebol-file that produces "valid" rebol file types? I'm 
looking for the reason/case where you would want to use to-file in 
preference to to-rebol-file.

The file! type is just a datatype. There's no guarantee that the 
file! refers to anything, or is even the right syntax.

to-rebol-file and to-local-file are more like a pair, too.  The other 
to-* are their own set.  For a new user, it seems more obvious that 
to-rebol-file and to-local-file would go together, I think.

I think the way things are with TO-FILE and TO-REBOL-FILE is just 
fine. I would be annoyed if TO-FILE took had the more complex functionality 
of TO-REBOL-FILE. I agree with BrianH.

Could I ask why rebzip.r will only unzip a gzip if the console is 
launched from rebview ( in this case 2.7.6) but not from rebcore? 
thanks

I guess it's because it relies on the PNG decoder for decompression 
which comes only with /View engine.

Btw, congratulation to the author, Vincent Ecuyer for this great 
library!

anyone know of a way to get a persistent value based on someone's 
computer... the longer the string the better... (on windows)

this is with a /command license, so any accessible rebol feature 
is usable.

something like:
    -System install serial number
    -Disk serial number
    -CPU id


I want to generate an encryption key which isn't stored as part of 
the code.  It just makes it a bit more complicated to reverse engineer 
the stored password if the encryption key is different for all installations.

this value is only the basis for an intense series of string manipulations 
which make even the original data useless unless someone has the 
exact algorythm which generated the key.

MAC address ??

how do I get that info into rebol?

get-modes ??

or not

I am not sure get-modes gets you a mac address ....

you can as well use some power of command line - parse results of 
commands like ipconfig, arp -a, etc.

ahh. yes... doing a dir returns the volume name and serial number 
in one shot  :-) perfect.

so I'll just call and use the result string!

btw, thanks pekr don't know why I didn't of such a simple solution.... 
to much PITL dev I guess ;-)

yes. The same went for my news-scroller. I just tried to outline 
it in REBOL, thinking someone should do it in some PITL environment. 
Then I saw my brother using it in PC Shop on his LCD TV. I asked 
him - hey, wait till someone makes final version, and he replied 
- it works, no? And then I thought to myself - can I regard 2 pages 
of code being actually an application? :-)

hehe

max, it always scares me when people think that obscurity is a form 
of security...

Gab, are you saying that my idea is only obscurity, or that its the 
proper approach?  just want to confirm what you mean.  the

the idea is for the encryption key to a stored password is created 
dynamically via an algorythm.  
If the software is encapped, then its a pretty safe system IMHO.


But if the software stays open source (and interpreted), at least 
I can use some natives for which the key-gen algorythm is hard to 
reverse engineer.

Although someone with rebol know-how can obviously get the passwd 
by running the algorythm manually, there is no way around this AFAIK.

There is no way to protect a password you are saving. Normally, you 
just want to obfuscate it so that it does not jump to the eyes when 
someone is looking.

if the file containing the password is accessible to other people, 
then the password is accessible to other people.

but that is true of all passwords on a computer even login passwds.

but an encrypted password, without the key isn't usable if you don't 
know the key.

or even the algorythm its encoded with

If you think that keeping the algorithm secret increases the security 
of your encryption then you should not be writing an encryption algorithm. 
it's that simple. :)

The application knows the key, so anyone that can access the application 
knows the key.

the only way to keep a password secret if your files are accessible 
to other people is to not store it into a file.

you mean like in the registry?

I've wondered how useful it is not to store the password itself, 
but encrypting each keypress instead on top of the last keypress.

know that I understand that ultimately there is no method to hide 
any data.

I mean that thing that humans have that's called "memory".

yes ...  and it forgets   ;-)

I have a record right now of 67 passwords I have to remember... I 
mean I can't remember all of them.

right, so you have two options: you make sure noone can access your 
files (like you make sure noone can access your credit card), or 
you make sure you don't forget.

I do remember dozens of passwords, but this is not the point. Now 
you're talking about a different thing, which is a password manager.

A password manager encrypts all your passwords using a single password 
that you have to remember. so you remember just one.

In decent operating systems, that is standard with the OS, so what 
your app does is just communicate with the password manager and store 
passwords there.

yep, but it can be broken, just like any other system, cause it, 
like any system has to store those passwords somewhere.

as long as the master password is not stored anywhere... you are 
safe.

No, it does not have to store the master password anywhere.