Oxygen Basic
Information => Reference => Topic started by: JRS on September 10, 2013, 08:01:13 AM
-
I feel that having a stable set of include files for OxygenBasic is just as important as formal documentation if not more. I think it would be another tragedy to go down the same path as FreeBASIC and PowerBASIC with custom includes. Charles made the wise decision early on to support C/C++ native Windows include files. We have only seen spotty use of this feature when it should be the language standard and all earlier O2 BASIC style include files retired. I don't think this is going to require a life long commitment but it will require a serious effort to shake out the bugs and fill the holes so stock includes can be used.
My hope was that José Roca would see the value in O2 and take the lead with this effort as he is the most qualified. I don't have any false expectations and hope time will heal his wounds. He has mentioned on his forum about retirement and his lack of interest in open source. Anything is possible and I hope the beauty of O2 can do it's magic and get him to fall in love with a BASIC compiler once again.
I would like to get a list of essential C/C++ headers that make up core Windows development. Getting COM working well with O2 will be a requirement but I don't see it taking center stage and only seasoned programmers using it.
-
José,
This is an open source project. I'm doing my best to help Charles mature his compiler and expand his user base. I'm sorry that all the hard work you put in to the PowerBASIC product didn't pan out. The whole PB thing is a nightmare and a mess. I lost both my parents and wife in a two month period last yesar. I know what loss feels like but I'm not going to allow myself to end up a casualty as well burying myself in grief. I strive to surround myself with projects that take a creative approach and aren't afraid to break the mold. Charles is that type of author. He has surrounded himself with good people like Eros and others and the ride is more important than the destination.
I think getting involved in the O2 project will be healing experience for you and allow you to continue doing what you enjoy most. You have already mastered the Windows API, help us make use of that knowledge with O2.
John
-
I have been thinking about the best way to test the C/C++ header files with OxygenBasic. Since we already have examples posted by Charles and others using O2 WinAPI32 .inc files, I thought I would try the equivalent Windows .h files and see if the same examples still work. If anyone has a better way to approach this, I'm open to suggestions.
-
The full win api is a monster. We only need a fraction of 1% of its vast bulk to run all the examples and tools, so I am still in favour of maintaining a small win library. Then maybe suggest the MingW headers for more comprehensive scope. If you want to code anything in Windows you have to dig into the msdn docs
even if you have all the headers on-board.
-
The full win api is a monster.
I do not think is a monster.
I do not think we use 1% therefrom. 1% is only CreateWindowEx
Those api is our life and should be very big in size.
I cannot get enough api declaration, i love it all.
Convenience is the first step for self-destruction!
-
The full win api is a monster.
I was surprised when PowerBASIC came out with dead code removal. I had always thought that PB being a hand crafted compiler that it didn't compile unneeded code from includes. I guess I was wrong.
I have been thinking about this idea for some time and want to run it by everyone. How about using SQLite to store the include file definitions and have a utility that parses your code and builds a custom O2 .inc from the DB. The nice thing is the Win32DB could be used by multiple languages and the parser would be the only thing unique to each language.
Comments?
-
bad idea so far I can see. :'(
-
Mingw is a good source of Windows headers. There is also the full Microsoft SDK for Windows download. I often refer to version 6.0A which might be a little behind. But they are multi-megabyte and don't need to be included in the base package.
-
Charles,
Another possibility is to use Daniel Corbier uCalc Transformer to convert Windows include files to a O2 friendlier format.
John
-
Charles,
I did a few compares between the PB include files and the O2 current set. It looks like it would easier to convert the PB includes rather than the C/C++ headers. I'm working on a SB script to parse and write a new include file. The COM stuff will require more research on my part before attempting a conversion.
John
-
We have an include file nightmare if you ask me. Everyone seems to have their own include files. I think the 3 include files that I brought from VB6 that Charles cleaned up should be the most inclusive to date, but even so... I think that o2 should be based on a cross platform compiler, something like gcc or llvm(is not vitual machine as the name implies) or freepascal compiler. My two cents for what is worth.
GCC and LLVM both have front end systems, I don't know about freepascal. I have tried studying gcc and llvm front end code and it is over my head I am sorry. But every so many months, I go and look at it to see if I can make better sense.
Just found this site for future reference:
http://www.ibm.com/developerworks/library/os-createcompilerllvm1/
-
We have an include file nightmare if you ask me. Everyone seems to have their own include files.
The ones I'm building for the OxygenBasic project doesn't have any MY associated with it. As soon as I get the PB2O2 include file converter working I'll post the source and what files I have converted. Any help you can provide reviewing them for final submission would be great.
-
John, here is the latest that I cleaned up and broke into parts: Constants, Types and Functions and have used it to test many things without errors so far, but since it is such a big api, have only touched upon the major things so far. Hope it helps.
Files unzipped:
WinApiVB6.inc
WinConsts.inc
WinTypes.inc
WinFuncs.inc
Just updated: forgot to put WinApiVB6.inc in there, this is the file that would be used in project source code, it will sub link the other includes in needed order.
X
-
Thanks!
I'm thinking that pulling from multiple resources to build the final O2 includes may have a benefit. (cross check and if conflicts occur, write something out to a conversion log file)
SB has some neat text processing features along with dynamic matrix creation that may reduce/eliminate multi-pass processing.
-
Just updated the previous message John, I forgot to include the main include file. All updated now.
http://www.oxygenbasic.org/forum/index.php?topic=849.msg7011#msg7011
-
I have been thinking about the best way to create a include file translator in ScriptBasic. My thoughts at this point is to create an associative array key statements of an include file and the value will be the indirect address to a function.
_h{"#INCLUDE"} = ADDRESS(o2_include())
_h("FUNCTION"} = ADDRESS(o2_function())
The associative array would be a translation function dictionary for the parser.
-
I ran into a VB5/6 Win32API viewer that may be a better resource to use than the declared PB only use includes from PowerBASIC/Jose Roca.
ActiveVB site (http://www.activevb.de/rubriken/apiviewer/index-apiviewereng.html)
(http://www.activevb.de/rubriken/apiviewer/images/apv2002.jpg)
If you work a lot with the Windows API you may have noticed that the win32api.txt text file distributed with VB is completely out of date. This file is based on Windows 95 header files. Lots of new library function have been introduced with Windows 98, Windows 2000, Windows ME, and Windows XP. If you want to use these functions you can search the internet for their declaration. This takes a lot of time and and may even be unsuccessful.
For that purpose we have developed ApiViewer 2004, which is meant to replace the Microsoft API viewer utility. The database contains the most up to-date declarations taken from the most current Windows XP header files: 6 500 declarations for functions and 55 000 constants. In contrast to this win32api.txt contains only 1 500 declarations for functions and 5 000 constants. So why not simply release a new version of win32api.txt? Maybe you don’t believe it but the Microsoft API viewer utilitycrashes with an overflow error when trying to load the new version of the file.
Another resource that may be helpful and is similar is the API-Guide (http://allapi.mentalis.org/agnet/apiguide.shtml).
-
Thanks John, nice find for useful stuff!
-
The APIViewer can generates PowerBASIC syntax API references along with PureBASIC and MS micro assembler instructions. (and others)
I saved the win32api as a text file and attached it as a zip.
Maybe this can be used as a base for the O2 Windows include.
X
-
Charles had mentioned that he would prefer that we use the MinGW-gcc include files for O2.
Attached is the windows.nim in colorized syntax printed to a PDF.
@Charles - Is this parsable from O2 or would you need it in a more O2 standard declare format?
X
-
No the Nimrod API is new territory.
But your API Viewer output looks promising, John. Is this frozen at year 2004?
-
The API-Viewer looks to be a vintage 2004 era tool. It seems to have what is needed for Win32.
I think the Nimrod version of the MinGW-gcc includes (and all the supporting libraries) is the most up to date. I plan on using them to generate the DLLC API definitions.
-
Now that everyone has had time to think about include files for OxygenBasic, where are we going with this? I'm trying to facilitate some action on this but someone needs to stand up and provide some leadership in getting this done. Charles is overwhelmed with the compiler and I don't want to distract him (other than guidance) with creating includes for O2.
It seems Jose Roca has only a casual interest in O2 and open source projects isn't his thing. He would have been the best person to manage this effort. He is a smart guy and O2 is too attractive of a BASIC compiler to ignore. I'm counting on that he will see the light soon.
-
To improve compatibility with these large API headers, I am working on a true preprocessor, which will perform most macro/equate substitutions in the first pass instead of progressively in later passes. (It is what Emil had requested.)
This will make the compiler more efficient for handling the 50,000+ equates of MS windows (circa 2004).
It may entail some minor sacrifices, such as local equates - but I think I am the only one playing with them so far.
But I'm still in favour of simplified APIs, like Peter's and Aurel's, and I will maintain Oxygen's small collection of headers to support all the examples and tools.
-
Thanks Charles for the update where includes stand.
OT: Can a 64 bit version DLLC be created at this time?
-
But I'm still in favour of simplified APIs, like Peter's
Yes, follow my way, other ways lead you in to maze.
-
All the languages that I tinkered with all in the end have to deal with the api or have wrappers for them. Some of the bigger languages have tools to convert header files, but none of the languages can keep up with all the new libraries that are coming out each year. That is why I decided to bite the bullet and learn c++ a couple of years back.
I think the only way to really save a language from never ending header headaches, is to be a front end language to a well supported and documented cross platform compiler. I know this is easier said then done, but if I had Charles' brains I would go that route. He would have access to all the power that gcc offers to do anything and a really proven compiler. gcc has no good BASIC front end, they can compile all of these languages, so front ends for these wide range of languages have been written.
The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...). GCC was originally written as the compiler for the GNU operating system. The GNU system was developed to be 100% free software, free in the sense that it respects the user's freedom.
-
John,
64 bit DLLC will require some weird stuff to pass parameters using the 64 bit calling convention. Apart from that, the source code is written to be 32/64 bit compliant. If you have a 64 bit version of libscriba.dll available , that would be great for testing.
Kent,
The C emitter will take us on the journey in the direction of a GCC front end. There is much to learn about how GCC works, but only the top end of Oxygen (~20%) would be needed. Ultimately, OxygenBasic might be abstracted to a language specification, shedding its machine code origins entirely. :)
-
OxygenBasic might be abstracted to a language specification, shedding its machine code origins entirely.
(http://imagecache5d.allposters.com/watermarker/60-6004-SADB100Z.jpg?ch=775&cw=775)
-
Here is a download of the 64 bit version of SB that Armando created with MinGW-gcc. The archive includes the 64 bit libscriba.dll.
SB Windows 64 bit (http://www.scriptbasic.org/forum/index.php/topic,195.msg496.html#msg496)
-
...
The C emitter will take us on the journey in the direction of a GCC front end. There is much to learn about how GCC works, but only the top end of Oxygen (~20%) would be needed. Ultimately, OxygenBasic might be abstracted to a language specification, shedding its machine code origins entirely. :)
Charles, that is great to hear. I will work on the gcc front end until I understand it. I think having a true c++ like BASIC that I know Oxygen can be and using gcc is the best choice. LLVM is no where as nicely documented as gcc and proven.
-
I think having a true c++ like BASIC that I know Oxygen can be and using gcc is the best choice.
I don't know is this the best option...
what we then will get ...another Objective Basic like thing.
MingW is not bad but why most of pro-software is created with MS VC++ ?
Of course i talk about windows,for other platforms like linux - gcc would be better.
-
Making O2 more cross platform friendly only assures its survival.
I don't think you will have much luck changing everyone else's mind. :-*
-
I don't think you will have much luck changing everyone else's mind.
That is your aproach ,not mine.
-
That is your aproach ,not mine.
Aurel,
You are free under the GNU LGPL license to fork OxygenBasic and do whatever you like with it. (except claim you wrote it) Charles has made it clear what his direction is. If you don't like it, you know what your options are.
John
-
Making O2 more cross platform friendly only assures its survival.
For how many people ?
Thinking that the user crowd grows, is a romancer.
And what can already survive?
-
Peter & Aurel,
Your contributions are important to making O2 real. Charles has long term goals and is happy to share his thoughts and ask for feedback. This is a group effort and everyone's contributions count. Nothing is a waste of time so continue to do what you believe is best for O2.
John
-
Nothing is a waste of time so continue to do what you believe is best for O2.
holiday! (Eng.
vacation (AE).
-
I think having a true c++ like BASIC that I know Oxygen can be and using gcc is the best choice.
I don't know is this the best option...
what we then will get ...another Objective Basic like thing.
MingW is not bad but why most of pro-software is created with MS VC++ ?
...
Aurel that is why I said like c++. You don't have to code in object oriented with c++ if you don't want to. It is very flexible, you can do procedural coding, object oriented and now c++11 more functional style programming. These are all things Oxygen does too.
MS VC++ is very professional compiler and their IDE is very useful, but it is Microsoft Only and if you notice, you need to have runtimes, many versions of them on your computer and also the correct couple of dlls or your executable's won't run. That is why most MS VC++ written stuff uses installers to install all the correct dependencies. That is why I stopped using MS VC++ and stuck with mingw.
And as you noted, gcc is cross platform.
I see Oxygen as C++, but with BASIC clean syntax. Making very small and fast executable files, written in the programming style you prefer supporting a vast array of libraries on cross platform.
As I printed, there is no BASIC in that list of supported gcc front end languages, so Oxygen would be superb candidate.
Also the Mingw team does a great job in keeping up with the windows api. The previous version didn't have support for GDI+, only GDI. but the current version does support GDI+.
You have a team of developers doing all the hard work making all the headers for gcc, so it allows someone like Charles time to work on the language syntax and functionality on proven foundation code.
-
Ok Kent
I can agree with you in some point of course and i don't have nothing against
if someone want to use any kind of headers.
But pushing something over something already exists is not good
so there must be choice,right?
After all on Charles is what he will do.
-
It seems to me that once you are inside the VS system , Microsoft ensures you can never escape with your hard-earned code treasures. You are locked into a vast labyrinth of interconnecting dungeons. :)
(http://www.thedungeons.com/edinburgh/images/main-images/edinburgh-labyrinth.jpg)
-
External view. (Microsoft campus - Redmond, WA)
(http://winphankyle.com/wp-content/uploads/2013/07/ms-campus-hero.jpg)
-
Hi guys ,
I think that the best solution here is to use C emitter that produce GCC code and using Gcc as a back end of
Oxygen basic. why?
1- there is no need to pares any c header file , GCC will do that for you.
2- GCC or C++ can optimized you source code
3- allowing you insert some c/c++ code with your Oxygen basic
4- you can link and use C/C++ libraries , all C/C++ world in your hand
5- you have not to know any c/c++ syntax , just use basic syntax as usual then C emitter make it for you.
thanks
-
+1 What Emil said.
Even ScriptBasic will generate a C source wrapper for its compiled/tokenized binary script. This also allows you to static link C extension modules that have a dual mode of being dynamic or static linked on creation.
-
WOW... :o
John...i see this image first time and i don't get it where i see this image before.
I do in same shape one of my antenna...gee....
mybe MS send me trough sub-space this image in my brain ::)
-
Return to topic...
So on this way any of Peter or my program which use custom include not work.
And we be forced to use mingw headers,right?
hey don't get me wrong i really don't have nothing against C emiter but i doubt that things are
so simple like you think.
Even simple command print "" depend on win api (messagebox) and how gcc know how to
translate this simple command to gtk based widget .... ::)
-
what do you mean by custom include , if it was a basic syntax code so no problem C emitter will translate it
to c behind your sens .
you will not forced to use gcc header , it is so simple ,you write a basic sytax code and get exe file , so
no problem od intermdiate processes.
print commend will emit tp printf if your programe will be console programe or MessageBox in windows or what
else in othere system i mean coresponding in gtk based widget.
-
what else in othere system i mean coresponding in gtk based widget.
ok then... ;)
If this thing will work i would like to see some day that oxygen work on my SliTaz ;D
-
Emil and John, yes I was reading again the front end stuff for gcc and I think you guys are right. Writing a c emitter would be the most flexible because you could use any c compiler, even ones for microcontrollers!
-
Hi kryton9,
the major opinion here is Charles ' one , he the only man will decide the direction of this topic.
hope if he has a time and confined , he will start that as soon as possible.
-
So as conclusion...
C emitter will be only usefull if we want use another platform
where we can compile our programs written in oxygen....
-
Another platform ?
There is only Windows.
-
If Charles wants cross platform and interoperability, C (ANSI/ISO) is the only way to get there. IMHO
It may be a good time to fork O2 within the project as a Windows JIT ASM BASIC compiler and create a new branch as a O2C translator.
I still think writing the O2C translator in ScriptBasic would get it working faster and with more help from the group. (at least the first pass)
-
John or Charles, do you guys have any idea the route FreeBasic is taking towards being a gcc compiled language?
-
They are farther along then we are. :-[
Joshy (J.Peters) has FreeBASIC running on ARM using the C emitter.
-
Is the plan to emit low level C code as translated ASM in O2 like the FreeBASIC project? I would think it would be more useful to have a BASIC to C translator that generates C code that can be expanded on at that level. Both FB and BaCon generate C code that is unusable other than to compile to a binary. Do we really want to paint ourselves into the same corner?
Many of us are BASIC programmers first and wannabe C/C++ programmers for the portability, speed and access to the vast library base available. Static linking is another plus for porting BASIC code to C. I don't see a huge difference syntactically between BASIC and C. With all the free extension libraries for C available, many of the missing pieces in C that BASIC provides as standard equipment can be emulated. (runtime library extension)
If I were to create a SB2C translator, I would use the scriba -C output (pre-tokenized binary source) and use that to convert to C. SB has already done most of the work for me (parse, lex, ...) and has created an efficient source base to translate to C. Personally I don't see the point of doing this for SB because I can create a SB extension module in C that can solve any bottleneck an interpreter might inject.
I would like to see O2 create a library that can be static linked with C before taking on any epic adventures of a O2 to C translator.
-
Keeping the C output as close as possible to the original code is certainly desirable. It gets a little complex around string operations. - I have been paying close attention to Patrice's manual translation of PB code to VC10.
Some Oxygen constructs are quite hard to translate directly to C, so we may have to do some feature-pruning. (But I think I am the only one who might feel the loss so far :))
Static libraries appear to be compiler-specific. So to take advantage of these, the C translator has to be implemented first.
-
I think O2's ability to create virtual DLLs is a missed opportunity by the other language developers. Maybe I shouldn't say anything and be selfish, non-contributing and someone that only cares about themselves. I'm not sure if the other 35 non-posting members here fit the bill or not. All they are is a record in the MySQL database taking up space. I have no idea why people join forums and never post. Members here actually had to send Charles an e-mail to register and they have elected not to post. Guests have all the features of the site except posting rights. If someone (non-posting members welcome) can tell me why this is, I may be able to sleep tonight.
Maybe we need to be like the Jose Roca forum and not allow searching of posts or downloading attachments unless you're a member. We can also make the requirement that O2 examples are shareware and free but can only be used with O2. Hmmm, did I leave anything out?
And you know what, when it comes to advanced graphics, i can see the difference between 32 and 64-bit.
The 32 bit geniuses are waking up to reality. How refreshing. I have been running nothing but 64 bit apps for over 2 years on my development desktop PC. I have been running 64 bit hosting servers for over 5 years. The sad thing is there is so much invested in 32 bit no one wants to switch.
I encourage all my clients to spec. nothing but 64 bit business applications if they aren't interested in going shopping again a couple years.
-
Interesting discussion about some of the behind scene stuff guys. I enjoy reading about these things. Even if I am not at that level, each time one reads such a thread you get little ah ahh moments of understanding a bit.
About forum membership, I can imagine how frustrating it is to run a forum, let alone all the ones you do John. I am surprised there are not that many posts on the scriptbasic forums as that seems to be a widely used and popular language, you would think the forums for it would be a busy place.
The most active forum I have been on was the old iBasic forums and after that I would say the thinBasic forums.
I am sure once oxygen is at a release version and documented, a lot of users will join then and these forums will be busy.
I am also surprised that we are not seeing behind the scene discussions at the ALLBasic forums. If I were a low level guy, it would be neat to hang out and discuss things with other guys at the same level.
-
I am also surprised that we are not seeing behind the scene discussions at the ALLBasic forums. If I were a low level guy, it would be neat to hang out and discuss things with other guys at the same level.
I'm glad someone gets it.
(http://static2.fjcdn.com/comments/Everyone+of+us+in+a+nutshell+_00caa86f0bb55938b215b73dd540c312.jpg)
-
That is a cool image!
-
Some Oxygen constructs are quite hard to translate directly to C, so we may have to do some feature-pruning.
I see the future with alarm. Probably is it a suicide squad.
-
No worries Peter. O2 has cliff avoidance routines built in. ;)
-
O2 has cliff avoidance routines built in.
Yes, is full of cliffs, swim carefully!