World: r4wp

Yes most likely.

1058: I don't know, that's Kaj's error.

ok

Hmm, I guess we should try then implementing a suitable callback 
to answer properly to SCM commands...

Yes, still not sure what SC seen as file not found though.  But a 
process monitor from systems internals might tell us that.

Run procmon.exe against it and see if it records a specific file 
not found.

Thanks for helping on this, Paul!

Sure no problem.

Filemon: yeah, thanks for the reminder, forgot about it.

Procmon is the newer version of Filemon.

It gives you much more including registry, network, and profiling 
counters in addition to file system calls.

Thanks, Paul

When working with Windows debugging, I typically like to run a process 
through procmon.exe and dependancy walker profiling before tossing 
into the windows debugger.

np

1058 is driver deactivated or couldn't bind to any devices

ok, so I assume that was on another platform?  Or was that also on 
windows?

However, the driver just has a skeleton success return entry point, 
it doesn't try to take any devices or anything yet

That's XP

Yeah run against Process Monitor and look for any access denied or 
file not founds or path not found messages.

Does that do kernel drivers?

Is it a driver or system service?

A kernel driver, but it's started with the service infrastructure

Have you isolated it down to the system perspective or the driver 
perspective as to where the error is encountered?

It stops earlier for Doc. File not found seems to be the driver file 
itself, so it probably doesn't load at all

On my machine, it loads but then comes back with error 1058

I would use the driver verifier utility on that.

So the system is expecting it to do more than it does. But a null 
driver should just work

Sounds good, what's that?

It checks windows drivers to ensure they don't crash or have other 
stability issues.

You'll want to start  there.

It sounds vaguely familiar, but where is it?

Should be able to find a free download via Microsoft site.  I think 
it is include in the Driver Development kit.

Yes, I may have encountered it, but don't remember the name

http://support.microsoft.com/kb/244617

Thanks!

np

Sadly, I can't get any information about the driver out of Verifier 
or ProcMon

ProcMon is more about userland, and Verifier is about drivers that 
actually run

Where can I find your I/O binding Kaj?

@Doc in your example I now notice the declaration of the local variable 
as well: http://pastebin.com/Dddf57eH

Is that necessary, I didn't use it and all seems to work pretty well.

It was just for the sake of showing that arguments and locals are 
not in the same context.

ok I was afraid some sort of memory leak could happen if you forgot.

INPUT and ASK are in the C library binding:

http://red.esperconsultancy.nl/Red-C-library/dir?ci=tip

Both for Red and Red/System, in ANSI.red and ANSI.reds

Ah! the ANSI files. Should have guessed! Nice to use in the video 
next.

This Zato.io stuff is where I was looking for Red + zmq to go.   
bit.ly/19U6S64  (Hintjens RT)

http://bit.ly/19U6S64

I am trying to learn Red/System but I have a strange result. When 
I enter this code all works fine, the input line is printed correctly:

#import [
	LIBC-File cdecl [
		get-line: "gets" [
			line	[c-string!]
			return:	[c-string!]
		]
	]
]

foo: ""
get-line foo            ; when run I enter: this is a test
print newline
print foo                  ; Correctly outputs: this is a test


but if I do this;

foo: ""
boo: ""
get-line foo          ; when run I enter: this is a test
boo: foo
print newline
print boo

then I get             ; "thisX @"

or if I enter: hello
it prints out: hellX @


It seems that something in the process of binding foo to boo is messing 
up, but I have no clue what it might be.
Any ideas?

gets() requires you to allocate a buffer of adequate size. Empty 
c-string! literals ("") will statically allocate an empty string, 
unsuitable for use with gets(), resulting in buffer overflows ('boo 
is allocated just after 'foo). Try rather: 

foo:  allocate 100
boo: allocate 100


This will dynamically allocate 100 bytes for each c-string!. You 
need to ensure that gets() won't overflow those buffers (which in 
practice is impossible, so one should just avoid using gets() in 
production code).