World: r4wp

Have fun :-)

Antivirus alert: I've scanned Hello.exe with virustotal.com, no virus 
signature detected at all:

https://www.virustotal.com/file/ecde1916047993067be692235fb87352860b4596f5a2d54ba7efbf7482bcbe3a/analysis/1351329447/

Fibonacci.exe does raise some alerts from a few AV:

https://www.virustotal.com/file/6a86ef360727e907b6fc8cd7f9c0607a3ccb11f8f953747167b349dc43d6bf8a/analysis/1351329779/


I will look into these false positives signatures to see if I can 
improve that. Not sure it will be possible if they are caught by 
undocumented heuristics...

hello-unicode in MSDOS: has he switched the DOS console to Consolas 
font?

I get virus alerts all the time from red. I just turn it off. The 
only thing that ever got as many hits as red was rainbowforth which 
was another very minimalistic program. AV programs seem prejudiced 
against small executables :(

I've sent a few info requests to various AV vendors, I hope to get 
some clues about what's triggering their heuristics.

I will release v0.3.0 in a couple of hours, if you want to do some 
tests to track regressions, that would help.

For example, testing Kaj's bindings on non-Windows platforms would 
help.

Consolas font: probably not, I'll ask

Shouldn't FPU initialisation be included automatically when Red/System 
is configured to use the C library? I have at least three bindings 
that need it

What makes you think it is not included?

I've sent an email to Freddy already asking a few more questions 
about his issues.

I've dropped my C library binding from several examples that use 
large libraries on top of GTK. I had my FPU initialisation in the 
C library binding and now the crashes on float exceptions are back

You should add C-specific FPU initialisation to the bindings that 
produces float exceptions. C relies on FPU flags (masked exceptions) 
that are different from what Red/System uses. Doing so will shutdown 
some Red/System runtime error traps (like division by zero), but 
allow C-based libraries that access the FPU to work normally.

Ah, forgot that they conflict

Red alpha release: http://www.red-lang.org/2012/10/red-alpha-release.html

I'm glad this one is out...finally back to coding now! :-)

Congratulations! Looks great, sure gonna play around with this release!

Wonderful.

Great News!

Thanks! I have added a mention about missing Chinese font on some 
of the screenshots, just in case someone thinks it's a bug.

Congratulations on this heavy milestone!

I've moved the SQLite developing branch to trunk. Needs the new Red/System 
release

Is there currently a difference between MSDOS and Windows targets?

Yes, MSDOS uses the 'console sub-system, while Windows target uses 
the 'GUI sub-system.

OK, but what's the concrete difference in generated code?

So far, it doesn't make a big difference in practice.

The difference lies in the PE header, the sub-system required to 
run the app needs to be set to either 'console or 'GUI.

OK, thanks. I'll split the test builds, then

But Windows seems to be quite permissive in recent versions, so a 
GUI app can also be started from DOS console.

Yes, it would be cleaner for the day when we will have real GUI apps 
in Red, in addition to console-only ones.

(at least for the Windows platform)

I suppose GTK and SDL officially need GUI

Yes, it would be cleaner/safer to compile them using 'Windows target 
rather than MSDOS, but I'm not sure you what would happen to the 
text sent to stdout and stderr then...

Good point. I'll add instead of move them, then

Calling it something like Windows-Console rather than MSDOS might 
be better, since the real MSDOS (or rather clones of it) is still 
a valid target for embedded development. The Windows console environment 
hasn't been MSDOS since the '90s.

Brian: I'm aware of that. The probabilty of someone porting Red to 
old MSDOS (no Unicode, no multitasking, no native TCP/IP) is very 
close to zero. If someone does it anyway, we'll adjust our targets 
ID accordingly. In the meantime, I prefer typing "-t MSDOS" rather 
than "-t Windows-Console" on command-line. Also, it's easier to remember 
for everyone, after all it's just an ID, nothing else.


If you are thinking about FreeDOS, which is probably a more likely 
target than real old MSDOS, I guess we won't have any name collision 
then. ;-)

Call it DOS. But the MSDOS target name still annoys me. I don't want 
a legitimate, common target build to bring back such bad memories 
:(

Actually, not all of the memories were bad. In recent years I was 
thinking of making sure R3 would run on a set of libraries that enables 
Windows apps on DOS, but at the moment I'm having trouble finding 
the link/name of those libraries.

Ah, here it is, the HX DOS extender: http://www.japheth.de/HX.html

what about calling it CMD (as is the command, cmd.exe, which you 
have to issue to open that black old console), or CON, as a "console"?

I've hesitated between DOS and MSDOS in the beginning, and I've chosen 
the later one, because it is more meaningful for everyone, especially 
those that do not use Windows often (or never use it). As I've said, 
if someone ever ports Red to old MSDOS, we'll deal with the name 
conflict then.

Pekr: Red is not a Windows-only product. ;-)

I meant call the real DOS target DOS. No Windows-based target should 
have DOS or MSDOS in its name :(

Brian: as I've explained to Kaj earlier, Windows does make a difference 
between apps built with GUI or built for console- only. If it wasn't 
the case, we would only have the "Windows" target.

I have no problem with the existence of the target, and will likely 
use it; I just don't like the name.

Congratulations on the release of Red Alpha.

Another OS for running Windows console binaries (and possibly more): 
http://www.jbox.dk/sanos/

I also thought about "WinCon" at the beginning (and "WinGUI" instead 
of "Windows"), but quickly dropped it because it would not be easy 
to remember, and inconsistent with the way other targets are named. 
See the targets list at the bottom of this page: 

https://github.com/dockimbel/Red

Calling it DOS would annoy me, as I had that on Atari 8-bit :-)

well, let's not loose much time upon what just annoys us re naming 
convention of not so important language parameter ... :-)