World: r3wp

but more will jam at first page full...

and its not very professional for clients...

Yep. It's not what I want my customers to show as well

for some reason, I am sure I had it working... I did so many tests.

Well.... you must have been mistaken

Now I can either create a wrapper program that can do this and runs 
my rebol program in the background, or ask my users to use 'more

but the more serious limitation is not being able to ask a question 
on the command-line   ;-(

Yes, but in my particular case, that is not a problem

I wonder if this limitation is only due to the fact that Carl does 
not want the rebol executable to be bloated... cause I see no reason 
why this limitation exists... even python works directly in the console... 
maybe RT should look at python's startup code to see how they did 
it?

I have no idea aither, but code bloat seems unlikely here.

I thought the API approach would at least work, but I don't know 
if doing it inside a process that has already opened the console 
in a non-shared mode would cause the issues I saw or not. And I would 
think that CGI mode would work too.

Max: Perhaps you could come up with a nomore for clients. I came 
up with one in JScript (as it is pre-installed on all Windows 98 
& NT 5.0 onwards).

Usage:
test.exe. | cscript\\Nologo nomore.js

Script:
var si = WScript.StdIn;
var so = WScript.StdOut;
var line;
while (!si.AtEndOfStream)
  {so.WriteLine(line = si.ReadLine());}

Here's a quicker one that buffers all the output:
var si = WScript.StdIn;
var so = WScript.StdOut;
so.Write(si.ReadAll());

..but it needs to recieve all the output at once.

thanks, Unless RT fixes this long-standing issue for the next R2 
bug fixes I'll at least try this  :-)

and could wrap my app in a little batch file... to make it invisible 
...

Maxim  Im pretty sure windows has always woked this way , can you 
also pipe to TYPE to avoid stopping at 1 page?

type doesn't seem to work for me  :-(  it expect a file name as an 
argument...

is there any way to use class methods from C++ implemented external 
libraries?

... | copy con

grasping at very old straws here

?

can you pipe to copy con

or has some kind soul implemented  unix cat for dos

hum... cat.exe probably exists maybe less.exe also...

http://unxutils.sourceforge.net/

How can I change/get rid of the REBOL word in the title?

depends if you are in view or not.

when not in view:  (on windows)  Graham posted this a while back:

win-lib: make object! [
	
	user-lib: load/library %user32.dll

	SetWindowText: make routine! [
		handle			[integer!]
		Title			[string!]
		return:			[integer!]
	] user-lib "SetWindowTextA"
	
	set 'WindowTitle func [
		Title [string!] 
	] [
		SetWindowText get-modes system/ports/system 'window Title
	]	
]

for view windows,  there is a title field in the encap part of the 
rebol header

rebol [
	encap: [title "NOT REBOL"]
]

are there ways to extract version information about an encapped binary 
from REBOL? I'm building a software update tool and want to read 
the version information about a specific binary.

not AFAICT cause its always the same wrapper, and the content is 
encrypted, so you can't just read and parse the binary  !

I guess it would be possible to do a checksum and correlate that 
against a version list.

but for that you have to have access to the version info from the 
outside, meaning you already know it... but I guess this is not such 
an issue depending on why you want version info..

yes, the app and updates come from me and so I'll know which version 
it is if I just have a checksum on the executable.

if you have full control on the app sources... using a resource editor 
(on windows), you could probably edit the rebol version data included 
in the binary metadata and then there are probably os calls to get 
that natively.

this has the added benefit of being precise within the icons and 
shortcuts... and may remove the reference to REBOL within which is 
a bit annoying when you release stuff and its not labeled as per 
your output names ' :-/

except it has to be fully automatic...

on encap you mean?

yes, no human involvement between initiating build and finished executable 
and knowing the version

well you know the version from the source, and as you say, can resolve 
a checksum from the output bin.  but you must keep a table of all 
the builds somewhere...   I wonder if there are any commandline resource 
hackers?

which would allow you to stamp the version (maybe) within the bin 
automagically.

You need to use the API to get the version resource from a PE file. 
It might be a standard resource , but I haven't touched that in a 
long time so I can't remember.


As an aside, this feature was so requested in the VB world, years 
ago, that Desaware created a commercial product called VersionStamper 
that did just that; and they sold a lot of them.

The UpdateResource API, and others, were added to later versions 
of Windows, but I've never used them. Might not be too hard, but 
I can't say.

GetFileVersionInfo info isn't a real simple API call either. Have 
to figure a few things out in order to call it from REBOL.

Ideally, you would be able to specify version info in the encap header 
and then query it from system/options later.

but this is to get version info outside of the executable.

Ah, I missed that part. Just need to map GetFileVersionInfo then 
I guess.

hmm. GetFileVersionInfo would be written how? I need to control that 
through encapsulation.

Henrik, if you need to do automatic update, you might want to look 
at how the detective does it, it has worked *very* well so far, and 
it can update both the exe (if you change version of the interpreter) 
and the code only (to save download time). the autoupdate library 
is bsd.