World: r4wp

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).

Thanks Doc. What then would your recommend for getting console input 
into Red/System if not gets()?

The allocate did not work because of a type mismatch but using long 
empty string literals did.

Have a look the Red/Sysme parts of Red's console:

https://github.com/dockimbel/Red/blob/master/red/tests/console.red


These are not the only ways to securely read inputs from user, fgets() 
is the main safe alternative:

http://stackoverflow.com/questions/4309746/safe-alternative-to-gets

Thanks Doc.

Type mismatch: you can fix it easily with a simple type casting and 
proper string initialization.

foo: as c-string! allocate 100
boo: as c-string! allocate 100

Great, thanks Doc, worked a treat!

Here is the first Red/System driver, a minimal Hello World kernel 
driver for Windows:

Red/System []

#import ["ntoskrnl.exe" stdcall [

 log-error: "DbgPrint" [				"Print formatted message to debug log."
		[variadic]
		; format		[c-string!]
		;	value		[variant!]
		;	...
	]
]]

on-load: function ["DriverEntry"
	DriverObject	[driver-object!]
	RegistryPath 	[byte-ptr!]
	return:			[integer!]
][
	log-error "Hello Red/System from Windows kernel driver!"
	0
]

Great news!

Can the RED compiler generate PDB files?

So, I gave my new BeagleBone Black (BBB) a quick test. With latest 
Arngstrom Linux, I was able to upload Red ARM tests (generated using 
%build-arm-tests.r). All tests pass, except %function-test, which 
crashes with Runtime Error 1: Access violation ....

The above mentioned script also fails at it tries to make a directory. 
Maybe it needs make-dir/deep %runnable/arm-tests, or simply to remove 
%runnable ....

Doc said PDB is undocumented and too complex

I didn't know it wasn't documented.

Early results were that PE format is less complex than ELF, but if 
you count in debug extensions, it's the other way around

I have a technet subscription so I'm combing the database right now.

Ah, just found out, that above access violation is present even with 
Windows version of the function-test.exe