World: r4wp

Can any of this be posted on facebook?

Typo: "sice"

Great work Kaj!

Great work Kaj and Doc!

Thanks for the explanation Kaj, that is most helpful.

A year ago this was beyond expectations. Congratulations Kaj!!

Congrats to all parties! Kaj for the hard-work, and Bo for the courage 
to go with Red/System solution. I would like to know the motivation 
to use Red/System instead of e.g. R3 (my understanding is, that R3 
has 0MQ available too?)

When I saw the opportunity, I had already thought that that might 
be something for Kaj, and now it even turns out he turned it in to 
a Red project too.

@Pekr: Part of the problem was that we needed to hook into the Windows 
kernel and also perform very fast operations because we're monitoring 
tens of thousands of files in real-time.  Plus, Kaj wanted to use 
the project to help Red mature, and I am completely in favor of helping 
in that manner.

In addition, Red has a "lead developer" (aka Doc) so any changes 
that needed to be made to the core language could be made quickly 
by him.  R3 has a strong lead in Saphirion, but they have their own 
priorities to consider.  I haven't been able to discern if there 
is a person outside of Saphirion that could do the same for R3.

(and Red has a Red/System part designed to operate on the same level 
as C, it is compiled)

It is in line with what your site says.

Note that the project is done in Red so far. Only a small piece of 
Red/System was added to the pre-existing 0MQ binding to optimise 
it. I'm compiling the three programs of the project, but because 
they're in Red, they could also run in the interpreter. On the other 
hand, I would expect that to use more memory, so the compiler is 
probably essential to this project, not for speed but for memory 
performance. Also, a custom Red needs to be compiled to scale the 
memory system, so I could compile a special interpreter, but I might 
as well compile the entire program

Next we will try to implement the Windows kernel driver in Red/System, 
but I may still have to use a C version of that

R3 is not practical for me to use, because the target systems are 
Windows. I can test on Windows, but I develop on Linux. I could write 
an R3 script there, but my 0MQ extension for R3 is written in C, 
so I would have to set up and maintain a complete Windows development 
environment to compile it for Windows. Red and Red/System are much 
easier to deal with

R3 is not practical for me to use, because the target systems are 
Windows.
 - this is obviously not true

I develop on Linux when I do for R3

I must have morphed into Ladislav overnight, then

Try rereading my explanation

Thanks to all who helped to get the new version out on github.

Congratulations Kaj!

Thanks. Doc, too; he made room in a tight schedule

Guys, this is great news! My first reaction was to get it posted 
on the MSDN site, but I'm not sure that reducing the need for Microsoft 
tools would be viewed as a positive thing from their point of view. 
It should be, though, since simplifying Windows driver development 
leads to more peripherals/accessories being integrated with the OS. 
It's a win for everyone (well, I guess not for the rabid anti-MS 
crowd). Between this and the similarly simple mobile dev that's coming, 
Red and R/S will be unbeatable.

Well, I'm part of the rabid anti-MS crowd, so you might chance it 
:-)

The MS crowd is used to everyone being on their platform, so they 
probably won't be defensive about it

I found a Windows kernel driver written in FreeBASIC, so we're not 
the first, either

Congratulations Kaj

One thing I'm curious about, though - what sort of debugging facilities 
are you thinking about? Will there be any hooks for a debugger somewhere 
not too far down the road? Is it possible to create a symbols file 
for these drivers?

The ELF emitter can optionaly include symbols in DWARF format, but 
there's no equivalent feature for the PE emitter (the PDB format 
is undocumented and quite complex). My plan has always been to provide 
a standalone native code debugger for Red/System, with a source-level 
debugger part once the IDE will be there. For the kernel-mode developments, 
we need some remote debugging functionality, which could be provided 
in different ways, including a specialized kernel driver in Red/System 
for debugging support. In the meantime, a kernel-mode PRINT will 
do. ;-)

Could anyone elaborat on those windows drivers? What is the main 
difference between the driver and the dynamic library your app might 
use? Is it that drivers have any higher precision/priority in regards 
to scheduled resources, they are running as services, and could be 
accessed from multiple app instances?

Pekr, we are talking about ability to build kernel device drivers, 
nothing to do with a user-mode dynamic library, it's another world.

Though, for now, we are more interested in a special category of 
kernel drivers: filter drivers (e.g. think Dropbox-like integration 
with the filesystem).

We implemented it in the dyn-lib-emitter branch because we needed 
some specific features of that branch.

Well, thanks for reply, which is not reply at all :-) If I would 
not know those are different beasts, I would not ask for the difference 
description ;-) So, as a developer, having some device - why would 
I choose to implement kernel driver instead of some supporting library? 
Does it allow e.g. access to more low level stuff inside the OS? 
Well, should google it probably ...

OK, found something - http://stackoverflow.com/questions/6007176/what-is-a-windows-kernel-driver

Device drivers are part of an Operating System, nothing to do with 
an application-level library.

https://en.wikipedia.org/wiki/Device_driver

So, as a developer, having some device - why would I choose to implement 
kernel driver instead of some supporting library? 

 You're aware that you can't access hardware directly from user apps?

ah, actually not. All our developed hw is intelligent, even if based 
on MCU, it uses TCP/UDP stack ;-)

But I do seem to understand - if I would produce card into PCI slot, 
that would be different situation. Am I right, that under Linux, 
situation is kind of simpler? I have seen some scripts, which blinked 
leds on BeagleBone, by just writing to/reading from particular directory, 
so expect situation under unix systems being kind of - simpler? Or 
once again wrong?

it uses TCP/UDP stack

 And how do you think your user app sends and receives TCP packets? 
 :-) It does through a kernel driver for the network card, provided 
 by the OS.

If you like, you could rewrite such kernel driver for the network 
card in Red/System now for Windows.

The /proc file accesses you've mentioned on Linux are just wrappers 
that rely on kernel drivers. There's no shortcut in modern big systems, 
User app => OS => Hardware.

I agree though, that the Linux /proc approach is nicer and can be 
very helpful.

For example, we could now use Red/System to write a kernel driver 
for exposing a proc:\ virtual disk to Windows, with similar features 
as the Linux /proc version.

Actually, that could be a nice project to promote Red. ;-)

indeed.   adding an actually stable and simple virtual drive system 
to windows would be nice.  I've tried two free ones, and they just 
end up crashing the machine when used.

However, this is not a project for faint-hearted, writing kernel 
drivers is notoriously difficult (whatever system you're on). There's 
a possibility for user-mode drivers on Windows, but I don't know 
much about them yet.

I hope to be able to provide a general-purpose virtual drive system 
for Red apps at some point (would be nice if this was contributed 
or sponsored).

Maxim, interesting that this problem isn't solved yet. Do you have 
links for those free systems?