Working in Ubuntu 12

[Mike Lobanovsky]

Gotcha John,

or or ?

[JRS]

FWIW AutoIT seems to run on Wine.



I gave IUP a try with AutoIt and I got the dialog to show. It still needs work but might be something someone ELSE would like to investigate. My curiosity has been satisfied.

AutoIt DLL Interface Docs

Code: [Select]

$iup = DllOpen("iup.dll")
DllCall($iup, "int", "IupOpen", "int", 0, "int", 0)
DllCall($iup, "int", "IupDialog", "int", 0)
$win = $return[0]
DllCall($iup, "int", "IupLabel", "str", "IUP AutoIt")
$lbl = $return[0]
DllCall($iup, "int", "IupAppend", "int", $win, "int", $lbl)
DllCall($iup, "int", "IupShow", "int", $win)
DllCall($iup, "int", "IupMainLoop", "none")
DllCall($iup, "none", "IupClose", "none")



.

[Mike Lobanovsky]

FWIW AutoIT seems to run on Wine.

Why shouldn't it? AutoIt3 is a pretty straightforward deal written in solid Delphi AFAIR and based largely on a standard set of most common WinAPI's that are supported by Wine very well.

OTOH AutoIt3 is declared as a scripting language that extends Windows' standard command interpreter to automate common MS Windows-specific tasks, mainly by emulating user input via a keyboard programmatically. From this perspective I don't quite see what AutoIt3 can and should do under Linux Wine.

And the last but not the least, AutoIt3 is so terribly slow that using it for anything other than leisurely batching is highly problematic, just putting it mildly.

[JRS]

I thought I would give the heads-up as it's a better alternative to the fruit basket of retro BASICs claiming relevance. I find AutoIt and BBC4W to have the same issues trying to interface to the Windows API. Why go through all the SDK crap when it's easier to just write it in C [BASIC].

I agree. It's one step up from a batch file processor. 

[Charles Pegge]

I'm impressed with the performance of Wine 1.7. The Opengl programs. I've tested so far, seem to run at Vista speeds. I also managed to solve the MIDI problem by running QSynth with a SoundFont specified. The only problem is being unable to output Wave Audio at the same time. Qsynth takes it over.

[JRS]

Just in time for the death of XP. When the dust settles, I wonder what the distribution will be of old MS XP users to non-MS platforms. (Linux, OSX, Android, ...)

[Charles Pegge]

FreeBasic takes slightly longer to compile OxygenBasic (under Wine). About 2-3 seconds.  Intolerable!

[Aurel]

I wonder what the distribution will be of old MS XP users to non-MS platforms.

I am waiting for SliTaz 5. 

[Mike Lobanovsky]

@Charles

The generic nVidia driver had to be activated for OpenGl to work properly

Is that the proprietary driver Charles? In Linux lingo that means the one which nVidia developed and was gratified with Linus' humble middle finger for in exchange. Can you find the usual nVidia Control Center in your System Tools->Administration menu? Linux' own reverse-engineered "HW-assisted" drivers are only good for 2D rendering and fall back to SW emulation in 3D environments on nVidia GPU's.

I'm impressed with the performance of Wine 1.7.

If you're using the proprietary driver then it's not so much Wine's merit. Wine only uses what Linux has to offer, graphics-wise.

The Opengl programs.

This is exactly where Mesa steps in. What you see is not original OpenGL. By "not original" I mean not the usual set of dynamic libraries designed by nVidia to accompany and control the most up-to-date features of their GPU's as it does in the world of MS Windows. It's a general-case open-source implementation of OpenGL API that's still somewhere at the GLSL v3 level IIRC which means two generations behind the rest of the world. The proprietary driver improves somewhat on Mesa's behavior too but not as perfectly as it would were it using individual GPU-specific capabilities to their utmost.

FreeBasic takes slightly longer to compile OxygenBasic (under Wine). About 2-3 seconds.  Intolerable!

It takes GCC 2.5 minutes to compile the FBSL sources on a 2.2GHz Core2 Duo, and 1.5 minutes, on a 3.2GHz i5 Quad. Long live GNU GPL!

Horrible!

@John

I wonder what the distribution will be of old MS XP users...

Ref. my new signature.

[Mike Lobanovsky]

SliTaz is nice, Aurel, and I'd been fiddling with it for years myself. But only until elementary OS Luna was released. It's amazing in its user-friendliness (for a Linux distro, of course) and it is only at its v0.2 at that! I haven't seen a single word of dissatisfaction with it on the net even from seasoned Linux geeks and it's really worth something.

In fact I'm so often under eOS that when I come back to Windows, I still keep on clicking the buttons on the wrong side of my app windows.

I'm writing this from under eOS BTW.

[Aurel]

Mike..
i have tried many ,many linux distros and i even have one on my computer instaled
Mandriva ,but all of them are heavy or slow or tend to crush without visible reson
that is why i don't like linux to much ...
SliTaz maybe is not 'the best' for user friendy distro BUT is small and fast and many things
work on Slitaz 'out of box' without problem...

[Mike Lobanovsky]

Sure Aurel,

SliTaz is small and it looks good too by Linux standards. I still have it native on my old IBM PII ThinkPad along with KolibriOS. And yes, it is faster than most home-brewed Linux distros mainly due to its compactness. But that's only until you try eOS. eOS is a full-blown Ubuntu yet it is amazingly, stunningly fast for a Linux! If you HW and bandwidth permit then I'd advise you to try it at least in a virtual machine. VMware Player will do just fine. Both 32- and 64-bit downloads are available for free.

[Charles Pegge]

Mike,

Activating the nVidia driver was absolutely essential. I presume all nVidia cards will work with it. Without this driver, my PC would lock up after being suspended. Also, Opengl picking would crash any program that tries to use it. I'm not using anything above Opengl 2, so far. That is plenty to play with.

Yes, I've seen the Linus middle finger being deployed against nVidia. He has quite a temper as we have seen before.

How much FBSL source code are you compiling, Mike? 3 mins is okay for regular building but a long time for bug-tracing.

[Mike Lobanovsky]

Charles,

Currently just a little over 4MB of densely written Java style formatted code with some 3/4 of it optimized with the -O2 (hehe "oxygen") option and the rest of it, with the -O3 ("ozone", hehe again) option.

That annoying timing is for a complete rebuild of the Release EXE+DLL target. But GCC is much more liberal syntactically than its rivals and that's what I value most of all. MS VC would be too restrictive for our "Freestyle" hacks.

My preferred and most efficient debugging method is MessageBox, very much like yours. I use GDB very rarely mainly to find out more about weird coding practices of certain GCC developers though sometimes it does help me spot my own negligence and/or first signs of early senility.

[Charles Pegge]

Yes, 4 meg is a large hunk of code to process. I think Oxygen is around 450k of FB source. As a rule of thumb, I reckon source and binary sizes are around 1:1. But FBSL necessarily has a much larger set of functions than Oxygen. I squeeze very hard to keep the code size down, but there are still a few repeat patterns in there. I use a lot of strings rather than fixed structures, and mini-languages to render the source code down to binary.

The MessageBox  is very useful but on some occasions the console would be very useful to monitor multiple events.