Oxygen Basic
Information => Open Forum => Topic started by: Charles Pegge on March 11, 2014, 12:34:51 PM
-
Vista has served me the dreaded 'Blue screen of death' - probably a bald spot on my hard drive caused by the relentless thrashing it gets whenever the PC comes out of hibernation. Anyway, before rushing out to buy a new PC, I thought it would be a good opportunity to work in Ubuntu and Wine for a while, which has no problem in accessing the Windows partition. It will be interesting to see what the strengths and weaknesses are. I will miss MS Anna, the voice. She is stern, but Mr (Ubuntu) eSpeak has no charm whatsoever :)
-
That sucks!
Try cleaning up the temp directory and maybe even renaming your windows memory manager cache file. I would do a file scan of the Vista partition
and see if your guess of a weak sector is the cause. Backing up all those Windows files would be tops on my list.
FYI: Hard disk failure is not picky about what it destroys and what partition it does it on. I'm glad you built that Linux partition as it's the safety net that may have saved you from a very expensive disk recovery charge.
-
Hello Charles,
Your development work under Wine may be severely compromized when you come back to an original Windows 7 installation. Especially those parts of it that are kernel32-related low-level stuff. Wine is only an emulator despite its name and ambitions.
Please note that "windoze" and linuxoid OpenGL canvases and techniques are somewhat different. Also, it is reasonable to use nVidia's proprietary driver if your videocard is some kind of nVidia brand. And finally, make sure to stay away from Mesa. There's no such thing as Mesa for Windows any more and many Mesa-based projects are not compatible with Windows' native OpenGL.
You can safely experiment with GDI graphics in the meantime though.
-
Thank you, John and Mike.
I'm ready to order another box if anything else goes wrong, and to experience the delights of Windows-8. Vista, I will not miss.
After endless fiddling, I've got all the essentials running. This is a 64-bit version. (I tried 13.10 - too many glitches to stand a chance).
The generic nVidia driver had to be activated for OpenGl to work properly, and to avoid the black screen of death whenever the PC is brought out of 'Suspend'. I did not encounter 'MESA' - I don't think I will have to do anything Linux-specific in the Wine environment.
3D ttf fonts come out flat, and the letter 'e' is missing from the Arial font. I hope the other fonts are not so affected :)
To get Wave Audio and MIDI working, 'Timidity' had to be installed.
The Skype microphone was initially inactive, until going into the Skype options menu/audio. No further action was required.
Subjectively speaking, Wine seems to run programs at at about 1/3 speed, which is tolerable for now.
-
Charles,
I gave Ultra Edit Linux version another try since it was first released some time ago. I have to say the current version is up to the standards of the Windows version and I can now retire my Windows version of UE running under Wine.
John
-
@John
Code::Blocks (http://www.codeblocks.org/) has been my editor of choice under Windows for many years. It's only natural it's with me under my eOS too. A perfect match under the both operating systems gives me equal ease of use and confidence in what I'm doing.
@Charles
Raw Ubuntu still looks somewhat alien, gloomy, restrictive and sometimes unpredictable to me. I'm happy I came across elementary OS Luna (http://elementaryos.org/) -- a light-weight Ubuntu 12.04-based distro which will enjoy LTS (long-term support) till 2017 together with its parent. Its UI is beautiful and familiar even in its raw form and it can also be tweaked (although not so easily as one would like) to look and behave very much like the most beautiful graphical interface ever, which is undoubtedly Mac OS X:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/Screenshot.png)
Of course, as Russians say on their forums, this is only my own "IMHO". :)
Also, be sure to install the latest Wine 1.7 directly from Wine Headquarters (http://www.winehq.org/download/ubuntu). The package offered at the Ubuntu Software Center seems to be of some ancient build.
-
Thanks Mike!
Upgraded to Wine 1.7.14. Everything seems to work fine that worked before.
-
From my Linux partition I was able to copy all of my files from my Windows 7 partition to my 4 TB USB drive. Microsoft feels they own 4 of the files and they couldn't be copied. (security, profile, ...) It even copied the pagefile and hibernate system files. I'm sure the registry hive files made it as well.
-
Hehe, OTOH MS Windows refuses to recognize linuxoid Ext1/4 partitions at all. It simply reports them as unallocated. A sow is no match for a goose, so to speak. :)
-
Wine 1.7 is a lot faster - comparable with Vista with the OxygenBasic examples. The only problem is that MIDI has gone. May need to load in some sound fonts.
With Wine 1.7 The letter 'e' in Opengl scalable typefaces has been restored. Actually, this problem only affected bold fonts (Wine 1.4).
Elementary OS Luna looks very attractive, but I will stay with Ubuntu for a while, since its is the most popular of the Linux distros. I need to get familiar with it.
-
Hello Charles,
Perhaps this info (http://wiki.winehq.org/MIDI) will help you cure your MIDI?
-
Hello John,
You may sleep tight tonight. You've just christened yet another potential Linux developer! :D
-
Thanks Mike, I can see the Midi Ports already set up but no instruments / voices attached. I think these Linux systems are full of pot-holes :o
-
Yes Charles,
Linux is the most dreadful "dll hell" I ever saw. You may actually get your MIDI samples with some other package that's got nothing to do with MIDI. There are too many dependencies but you actually get used to it with time. Linuxoids just don't fully realise how lopsided their universe is. But I have to admit it was much worse than that some two or three years ago.
I'm glad to see they are catching up with the rest of the world though. :)
-
Keep in mind that you can use Windows native DLLs in most cases if the Wine version isn't compatible enough. Check the Wine site for information on using Windows DLLs.
@Mike - You have been a Linux user for a long time. You can only sit on the fence for so long before common sense finally kicks in. ;)
-
Gotcha John,
(http://fbsl.net/phpbb2/images/smilies/icon_ml_duel.gif) or (http://fbsl.net/phpbb2/images/smilies/icon_m_mega_evil.gif) or (http://fbsl.net/phpbb2/images/smilies/icon_ml_flaming.gif)?
(http://fbsl.net/phpbb2/images/smilies/icon_m_spin.gif)
-
FWIW AutoIT seems to run on Wine.
(http://files.allbasic.info/AllBasic/autoit_wine.png)
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 (https://www.autoitscript.com/autoit3/docs/functions/DllCall.htm)
$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")
.
-
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.
-
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. :-\
-
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.
-
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, ...)
-
FreeBasic takes slightly longer to compile OxygenBasic (under Wine). About 2-3 seconds. Intolerable!
-
I wonder what the distribution will be of old MS XP users to non-MS platforms.
I am waiting for SliTaz 5. ;)
-
@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. :)
-
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. :)
-
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... ;)
-
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 (http://kolibrios.org/en/). 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.
-
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.
-
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. ;D
-
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.
-
Yup, FBSL has many built-in "layers" that would normally correspond to separate add-on DLL's in other laguages such as, say, thinBasic. Each of them has its own set of functions and also their aliases. This means a great number of relatively large keyword hash tables are used that eat up lots of binary space. Luckily, my zlib-compatible (but not zlib-based!) intrinsic layer can be used very efficiently to have the tables and other data uber-zipped with compression level 10 prior to FBSL source compilation in order to reduce the overall binary size. The tables and data are unzipped directly in memory on the fly at app start, in fact adding very little overhead to FBSL's overall launch time. The layer per se provides the user with controllable compression level Inflate()/Deflate() functionality and also allows for codec-independent PNG image handling.
I'm at a constant grueling war against my own ideas and source code efficiency for every kilobyte of final binary's size. From that standpoint, I'm really looking forward to FBSL v4 that's going to be multi-platform, which means using some multi-platform windowing framework for its graphics and UI. They are all really huge these days and my own code contribution is going to be insignificant against their background. :)
And yes, I'm also using console for debugging some parts of the language although my experience has shown that there are cases when simple printf() may meddle with the debuggee to the extent of crashing it while MessageBox() is more reliable in this respect. The nature of this behavior is unknown to me. Perhaps it may be some internal glitch of GCC v4.3.3 that we use exclusively to compile FBSL v3.
-
Script BASIC has an interesting build system that generates .h (header), syntax definitions, make files and the HTML help from the .c files from scratch. It takes a while to understand how the whole process works but once you do, expanding and configuring the BASIC is really efficient.
-
I think the documentation part is called Doxygen. - Uses a markup notation embedded in C comments.
-
Actually they are custom tags Peter Verhas derived for the Perl parser that builds the HTML docs. It's somewhat broken and another thing on the list to fix before the 2.2 release. One the major goals of this release is to eliminate as much of the Perl scripts as possible and have scriba take over doing the docs and install process.
Here is the Doxygen (http://www.scriptbasic.org/docs/doxygen/index.html) output for Script BASIC 2.1 I did some time ago.