Theos PowerBasic Museum 2017

General Category => General Discussion => Topic started by: John Spikowski on August 11, 2013, 07:20:11 AM

Poll
Question: What version of PowerBASIC do you use?
Option 1: PBWin 10 / PBCC 6 votes: 16
Option 2: PBWin 9 / PBCC 5 (Classic) votes: 1
Option 3: PBDOS 3.5 votes: 0
Option 4: Earlier versions of PB products votes: 1
Option 5: I don't own a copy of PB but I'm here becuase I'm interested in possibly using it. votes: 0
Title: The compiler advantage
Post by: John Spikowski on August 11, 2013, 07:20:11 AM
Quote from: Theo
We should not start to compare Interpreters with real compilers.
Script Basic is an interpreter and as such has its advantages and disadvantages.
At the same time a compiler has otehr goals.
If you compile something your target is maximum speed, the result is possibly a datatype conversion to CPU internal datatypa - what we see here. If i write a script language i just stay within the highes precision, because nobody will expect best performance from an interpreting language. Just that it works in any way. Therefore we should not compare two diffrent kind of things.
Please keep the discussions on interpreting languages in the sub forum for that or else i need to make a cleanup of the postings.
Because we have already solved the problem here - Jose explained it - and there is no need to mix oil into the water here.
People may have to read the sollution for this prioblem, it should be easy to find. Academic discussions should be at other places.
@John: Open another post in the Scriptbasic forum IF you see a there a real topic/advantage.

Theo,

Twenty years ago I would have agreed with you. With today's hardware I find little advantage using a low level compiler like PB for 90% of the code I write to earn a living. If I do need a boost in an area of my code I just spend a few minutes and create a C extension module function that looks like any native script function. With Charles's DLLC extension module I can run ScriptBasic in a threaded model with a common callback handler that allow me to use libraries that aren't thread safe. I can script any API at runtime, access/define structures and even do low level COM. If you still think a compiler is the only way to go, the complete feature set I just mention can be embedded in your compiled application with only a few lines of code.

Here is a couple tests I did on Ubuntu 64 bit and Android Linux comparing SB with compiled applications. I'm unable to see the advantage.


FOR x = 65 TO 90
  a = a & CHR(x)
NEXT x
FOR x = 1 TO 1000
  FOR y = 26 TO 1 STEP -1
    b = b & MID(a, y, 1)
  NEXT y
  b = b & a
NEXT x
PRINT LEN(b),"\n"


jrs@laptop:~/BaCon/V220$ time ./strbench
52000

real   0m0.840s
user   0m0.832s
sys   0m0.004s
jrs@laptop:~/BaCon/V220$ cd ~/sb/sb22/test

jrs@laptop:~/sb/sb22/test$ time scriba strbench.sb
52000

real   0m1.024s
user   0m1.016s
sys   0m0.004s
jrs@laptop:~/sb/sb22/test$


This is a SB MD5 example running on Android compared to the Linux C version. The SB version has to do the following.


  • Load scriba
  • Parse/tokenize script
  • Load extension module and declare external functions
  • Load 4.3 MB string from a file into a SB string variable
  • Call the extension module MD5 function passing the loaded text of the bible.
  • Format binary results to a HEX string
  • Cleanup memory, unload extension module and exit scriba
Compare that to a compile C program that is a standard Linux utility and there is 3 tenths of a second difference.


declare sub MD5 alias "md5fun" lib "t"
declare sub LoadString alias "loadstring" lib "t"

s = LoadString("Bible.txt")

m = MD5(s)

for x = 1 to len(m)
  print right("0" & hex(asc(mid(m,x,1))),2)
next
printnl


shell@android:/sdcard/scriptbasic $ time scriba md5cc.sb
17CE80BA9F6A0F74093C575205C9CB17
    0m0.12s real     0m0.06s user     0m0.04s system

shell@android:/sdcard/scriptbasic $ time md5 Bible.txt
17ce80ba9f6a0f74093c575205c9cb17  Bible.txt
    0m0.09s real     0m0.05s user     0m0.02s system
shell@android:/sdcard/scriptbasic $
Title: Re: The compiler advantage
Post by: Aslan Babakhanov on August 11, 2013, 12:01:47 PM
Yet, another holy war: comparing language speeds :)

Processing "boring" string concat or math in the loop is not the best option to do some comparisons.

I would recommend to categorize the tests and at least define the goal:

1) Select programming languages
2) Select OS's

If you plan to test on Android and x86, then test results may not be equal due to processor architecture differences.
For example, implementation of jump operations on ARM processors differs from x86 family.
The same applies to register/memory operations.

Here are the basic test methods:

* loop operations
* if/endif
* data conversion/casting parameters
* string manipulations
* calling subroutines
* math operations: without and with optimizations

Do not call any api functions. 

Title: Re: The compiler advantage
Post by: Theo Gottwald on August 11, 2013, 12:36:20 PM
Skripting is the tool of coice if you need some sort of SysAdmin work quickly automated.
Sort files. Patch things. Like clean up your PC-Household.
If it comes to real applications that need highest speed nothing can beat an compiler.

But i agree with you John, that most SysAdmin work - more then 90% can be done using Skripting.
But immediately if you touch for example Rendering (Raytracing) or Image-Processing,
Skripting (unless you use Scripting languages that are optimized exactly for that) is no more an option.
Same with Sound Processing. You still need any CPU cycle to get the expected performance.

Because not only the CPU Power raised wit time. But also the amount of graphical and other data that needs to be processed, increased in the same way.

Skripting: quickly solve Tasks.
Application Programming: Use a compiler of course.

Must say that i am not a database, or API Programmer in first line.
If my programms woul use 95% of their runtime to call other DLL's or API's then of course there would be no difference, between Compiler and Interpreter.
In my field (explained above) a Skripting language will have no chance unless there would be special optimizations first.
But theny they will need to be compiled.
Title: Re: The compiler advantage
Post by: John Spikowski on August 11, 2013, 06:23:59 PM
My point is that interpreters on today's hardware is not night and day as it once was. I haven't seen many web application being built with compilers. Java is the most widely used language on the planet an it's not a compiler in a true sense. There is no reason not to use scripting to save time and call compiled code when a boost in performance is needed. Charles realized that compilers have a different role and wrote his with JIT features.

I'm not a PowerBASIC hater and was part of the beta team for years. I moved on when Bob and his censorship seemed like I was dealing with a company based out of North Korea. If PowerBASIC went public today, would you buy stock in the company?

Title: Re: The compiler advantage
Post by: Anand Kumar on August 12, 2013, 05:02:06 AM
As far as an interpreter is concerned, when it is executed, there is the run-time + dependencies associated with the run-time that is loaded in memory whenever the interpreter is executed.  The memory requirements for an instance depends on the static features of the scriptbasic language which is defined in the grammar file.  So if we run 1000 concurrent instances of script-basic, it should consume most of the system resources because of its memory requirements (this depends on the available memory and other resources).  For a compiled program, only the assembled code, its associated run-time (which is ~6kb for PB) and dependencies are loaded into memory.

When a interpreted program is executed...  once the run-time is loaded, the program to be executed is loaded into memory by the interpreter's loader + parser + syntax analyzer, sentences are validated and then a tree structure that is ready for execution is created (tokens).  Now, multiple instances of this tree structure can be executed without the need for parsing, loading etc. Even then its performance is not at par with a compiled program.  This is because, what you can see is that the interpreter recreates the entire set of tools used by the operating system to load a program into memory and maintain the program flow and this is true for any scripting language.  For a compiled program, parser/syntax analyzer does not exist and the program is just loaded and executed.  In the case of client side scripts, the script engine is loaded into memory when the browser is loaded in memory and so there is lesser performance penalty but the rest of the issues remain.  In the case of server side scripts, server does load the script engine in memory but still the delays due to loading/parsing/syntax analyzing a specific script exist. 

During execution of the tokens, appropriate functions that is defined in the syntax file is called by the execution engine based on the control flow that is maintained by the interpreter.  Parameter type conversion happens in the individual function before the function is executed and these parameters can be either variables or arrays.  In Script Basic the return values are predominantly variables (based on my experience) and here again, unless defined explicitly the scope of the variables/arrays are global (If we do not include a local definition in the function/procedure we will modify the global data).  Again In Script Basic, variables are accessed by mapping each variable to a global list of locations and when we get/set values we modify values in this list.  Contrary to this, in a compiled program, variables are data memory locations whose content is modified during program execution and functions are program memory locations to which jumps are made according to the control flow.  So you can see the fundamental difference that results in performance issues.  This is inherent in the design and just because we have faster machines it does not mean it is not present. 

Actually, I can even say that with an interpreter, on every execution lots of CPU cycles and system resources are wasted because of the code necessary for loading+parsing+syntax analyzing+variable reference+function calling+translation on every run.  In case of a Compiler, this is done at compile time and only execution of assembled instructions relevant to the program occurs when the program is executed.  Therein lies the difference. 

In case of client side scripting, there are too many platforms and compilers are designed for a specific machine architecture so interpreters are the only available mechanisms to support program execution.  Here again difficulties arise due to the version of the interpreter in use and the grammar supported by that interpreter (For eg Java 1.4 vs Java 1.7). 

So lets not compare apples and oranges.  Each of these language tools are designed for a specific purpose.  Compilers are for language translation (source program language to target machine language) while interpreters does what it means... executing actions of program constructs written in a source language at run-time. 

Title: Re: The compiler advantage
Post by: John Spikowski on August 12, 2013, 05:39:22 AM
QuoteSo if we run 1000 concurrent instances of script-basic, it should consume most of the system resources because of its memory requirements (this depends on the available memory and other resources).

The ScriptBasic runtime (libscriba <360KB) is only loaded into memory once. Each tokenized binary script is run in its own thread sharing the common runtime. The ScriptBasic webserver is a perfect example. It was used for a special event that at one point was seeing 4 million hits an hour with no noticeable stress on the server.

That was a HUGE misconception and I wanted to get that point squared away right from the start. I'll follow up with the rest of your points shortly. (busy at the moment)

Playing in the trees

I don't know what BASIC interpreter you're referring to but that's not how ScriptBasic works. SB uses a contiguous block of memory to hold the highly optimized binary tokenized script. I see little difference between a BASIC to C compiled program's runtime library and SB's C compiled runtime library. Granted in tight loops C/compiled BASIC programs will excel. How many real world applications that you would actually use a BASIC language for is in that state? As I mentioned before, if I find a section of code that would be better served as a compiled C function, I create an extension module and move on.

Very little of the SB code (application) isn't running in a compiled state. Even the interpretive script is optimized for execution. Not all interpreter work this way. Eros's thinBasic for example is a line by line interpreter and if you check out some the code users have posted it looks just like PowerBASIC SDK style BASIC but easier to use.

Recreating the wheel

QuoteActually, I can even say that with an interpreter, on every execution lots of CPU cycles and system resources are wasted because of the code necessary for loading+parsing+syntax analyzing+variable reference+function calling+translation on every run.  In case of a Compiler, this is done at compile time and only execution of assembled instructions relevant to the program occurs when the program is executed.  Therein lies the difference. 

ScriptBasic parses the text script once and keeps it's binary form in a cache directory. I can easily convert the user script to a C source file with the -C ScriptBasic command line switch. This creates a standalone executable normally in the 40-60KB range depending on the complexity of the script. (extension modules used can be statically link in as well)

Title: Re: The compiler advantage
Post by: Anand Kumar on August 12, 2013, 07:05:44 AM
John,

This depends on the grammar that you utilize.  The syntax definitions of version 2.0 is around 1000 lines long (including the comments) supporting roughly 250 basic functions.  If you keep enhancing the grammar to support more functions then the run-time size increases.  My run-time engine is around 1.5 MB and it supports more than 500 functions.  When you use it as a Server which is a special case, the run-time engine is loaded into memory and used as a service for token creation and a separate thread can be spawned for executing these tokens.  That is a way to optimize the system performance. 

When you speak about 4 million hits, the questions that needs to be asked are:

1) Are the hits executing the same program or are each hit refering to a different program? If it is the same program then the need for loading + parsing + syntax analyzing is removed...  A copy of the generated tokens is sufficient for execution.  If they are unique than 4 million trees needs to be created which should consume appropriate memory. 

2) Are they concurrent hits or are they sequential hits?  If they are concurrent than 4 million threads needs to be spawned, this is a OS feature which has been utilized. 

3) What is the size of the program in terms of number of lines (The maximum lines I have written using Scriptbasic is ~10000 while with PowerBasic it is ~250000), this is necessary because if the number of lines increase then the tree size also increases and system resouce consumption increases. 

4) What is the duration of execution of each of these threads, I have run script-basic programs (based on my extensions) that run for the whole-day.  My Pb programs run for weeks but its purpose is different. 

Script Basic is a good tool...  Peter has made it extensible but still it is an interpreter with its own limitations. 
Title: Re: The compiler advantage
Post by: John Spikowski on August 12, 2013, 10:30:04 PM
Quote
This depends on the grammar that you utilize.  The syntax definitions of version 2.0 is around 1000 lines long (including the comments) supporting roughly 250 basic functions.  If you keep enhancing the grammar to support more functions then the run-time size increases.  My run-time engine is around 1.5 MB and it supports more than 500 functions.  When you use it as a Server which is a special case, the run-time engine is loaded into memory and used as a service for token creation and a separate thread can be spawned for executing these tokens.  That is a way to optimize the system performance.

PLEASE update your scriba and extension modules to 2.2 as the ScriptBasic 2.0 version (before my time) is over 10 years old. gcc deprecations and fixes for 64 bit and Android are just some of the 2.2 changes that were made. The only syntax additions were made by Tom and he added just over a dozen new math functions (most were slated for completion and left as stubs by Peter) He also added a new RAD() function which the new math function accept.

All my additions to ScriptBasic are done as extension module functions.

Quote
When you speak about 4 million hits, the questions that needs to be asked are:

1) Are the hits executing the same program or are each hit refering to a different program? If it is the same program then the need for loading + parsing + syntax analyzing is removed...  A copy of the generated tokens is sufficient for execution.  If they are unique than 4 million trees needs to be created which should consume appropriate memory.

2) Are they concurrent hits or are they sequential hits?  If they are concurrent than 4 million threads needs to be spawned, this is a OS feature which has been utilized.

As I understand the story the SB web server and the MySQL extension module were used as a registration application for a marathon or some other big event. You would need to ask Peter as I got the story second hand. Keep in mind the 4 million hits was the total number over an hour period. I have no idea what the peek load was or if they used the MT session extension module.

Quote
3) What is the size of the program in terms of number of lines (The maximum lines I have written using Scriptbasic is ~10000 while with PowerBasic it is ~250000), this is necessary because if the number of lines increase then the tree size also increases and system resouce consumption increases.

WOW! a 10,000 line SB program, wait a second and let me get Guinness on the line as this may be a record.  8)

Quote
4) What is the duration of execution of each of these threads, I have run script-basic programs (based on my extensions) that run for the whole-day.  My Pb programs run for weeks but its purpose is different.

Once again, you would have to ask Peter.

Quote
Script Basic is a good tool...  Peter has made it extensible but still it is an interpreter with its own limitations.

I have yet to run into a limitation with ScriptBasic. I wish I could say the same for PB. (Win32 only, incomplete COM, unknown future, ...)

Title: Re: The compiler advantage
Post by: Theo Gottwald on August 13, 2013, 04:09:47 PM
John - can I help you on that?
Anything in the field of image processing or ray tracing ...
Especially when it gets to larger resolutions. Often not even a compiler is best for that but pure ASM.

On the other side Office-Automations are perfect usages for Scripts, because you do "just call" the host program.
This can be done by Script languages. VB Script is popular in this field.

Saying that, i believe that an developer of a Script language goes on a swampy terrain if he tries to beat a compiler language in terms of speed.
It just does not make sense. Its just like if you want to win a race with a tank against a Porsche.
I have only seen one approach that was very fast, and that was from ASM Guru Hutch - several years ago.
But it will never beat a compiler.

As I see it, Scripting languages serve special purposes, where speed is not important.
Here is an example:

Smart Package Robot Script (https://www.youtube.com/watch?v=anAEgWK9E5g)

Note that this program is not my pogram but from DS (while some parts of it come from me).
I am showing this just as an example of a script language that is used for special purposes.

As you can see mayxmum speed is not important in this usage. Having a compiler on the other side would not help the user.
At a place where special commands were important. These are the places where dedicated script languages can survive.

Thats why i say"Get a specialized purpose for your Scripting language". How about a WOW-Script-Language, John?
I have heared that there are people out there who earn a LOT of MONEY with these ...
Some of them even got Millionaire.
Thats nothing else then another dedicated "Script language". No question how fast ...

Thinking about it i should make a BOT for FARMVILLE :-)

@John, if you have to say somwthing substancial, you posts will not be deleted. But large pictures with no reasons and useless posts get deleted. And please keep a bit forum disciplin, otherwise we can delete more then just posts.
Sometimes we like to Joke, but primarily we look whats good four our Forum readers.
We want compressed information here. We want useful Source Code. Try that.
Title: Re: The compiler advantage
Post by: José Roca on August 14, 2013, 10:06:59 PM
Some of them have been deleted by me, specially the one in which you were insulting the members of this forum. You have your own forums: use them to post and leave us alone.
Title: Re: The compiler advantage
Post by: John Spikowski on August 15, 2013, 01:20:17 AM
To some it seems all I do is complain and bitch about nothing anybody cares about. In reality I'm probably the most active BASIC developer out there. (prove me wrong!) Here is another example of my adventures with porting C based BASIC languages to Android Linux and compiling native.

(http://files.allbasic.info/RTB/mandel_android.png)

This is Return to BASIC (https://projects.drogon.net/return-to-basic/overview/) traditional interactive BASIC running on my Samsung Galaxy Tab 2 10.1 tablet using SDL. The background SDL user interface controls can be toggled on/off from the applications preference menu. I'll post a rtb.apk as soon as I fix the remaining unicode issues which SDL 1.2 doesn't support.

more ... (http://www.allbasic.info/forum/index.php?topic=223.0)
Title: Re: The compiler advantage
Post by: John Spikowski on August 15, 2013, 09:15:17 PM
QuoteYou have your own forums: use them to post and leave us alone.

The last thing I want to do is upset you. I have tremendous respect for the effort you put into your include files and the reason PowerBASIC still has a product they can sell.

I assume what you mean by us is the loyal PowerBASIC users that still believe there is a bright future for PB and users of all those other BASIC wannabe languages will soon get it.

If you prefer that this forum remain PowerBASIC centric, then you should make that fact known so folks like Patrice, Charles, Theo and myself aren't posting off topic content.


Title: Re: The compiler advantage
Post by: José Roca on August 15, 2013, 10:57:50 PM
Don't twist my words. You know exactly what I mean. If you want to talk about O2, SB or wathever, do it, but stop bashing PB or other compilers. If you want to bash other compilers, do it in your forums and annoy your users. You already did it in your All Basic forum.

When Charles asked me for permission to post about Linux and FreeBasic (and later O2), not only I allowed it, but I made him a moderator. I also asked Fred to be a moderator mainly because of his experience with C++. And Patrice is now using C++.

Please stop trying to discourage PB users. Annoying them, not only you aren't going to increase the number of SB or O2 users, but it will backfire. Nobody is going to register in the O2 forum just to no have to deal with you.

Enough said. If you continue with your campaign against PB in this forum, I know how to stop it...
Title: Re: The compiler advantage
Post by: John Spikowski on August 15, 2013, 11:43:43 PM
QuoteNobody is going to register in the O2 forum just to no have to deal with you.

The difference is Charles isn't trying to sell you anything or has the overhead of a staff and expenses to support.

I think Charles, I and ScriptBasic have been releasing some state of the art technology (JIT virtual DLLs, multi-threading with a smart (common) event handler that works with non-thread safe code)  What have you heard (other than excuses for taking the PB website down for weeks unexpectedly)  from the PB team?

I have no beef with PowerBASIC but I'm not going to lie and call it gods gift to programmers and the only language you will ever need.
Title: Re: The compiler advantage
Post by: José Roca on August 16, 2013, 05:41:05 AM
I can't tell you what I know because I have signed a NDA.

I don't need JIT.

What are virtual DLLs?

PB has a good implementation of threads. Besides threaded variables and the old THREAD statements, there is also a THREAD object and you can also make any function, method or class thread safe by just adding the THREADSAFE clause to it.

Can you instruct me how to do more mondane things like adding a resource file to my executable? All my EXEs use a resource file and I haven't found a way to do it with O2.
Title: Re: The compiler advantage
Post by: José Roca on August 16, 2013, 05:56:16 AM
Other things that PBers want are tools like a dedicated IDE, a good debugger, a Visual Designer, an help file... Without them, you aren't going to convince anybody to switch to O2.

Do you use O2, or you just use SB?
Title: Re: The compiler advantage
Post by: John Spikowski on August 16, 2013, 06:01:36 AM
Quote
I don't need JIT.

What are virtual DLLs?

O2's JIT benefit interpreters more than compilers I would say. Charles first introduced the virtual dll concept with ScriptBasic and then implemented it in thinBasic. In essence what Charles has done is allowed an interpreter to pass a string of O2 code (function) to the O2 DLL JIT compiler creating executable code in memory as if you loaded a function from a standard DLL. This allows me to script/compile lighting fast code at runtime and still enjoy the benefits of using an interpreter.

I will let Charles answer your other question about resource embedding.

Title: Re: The compiler advantage
Post by: John Spikowski on August 16, 2013, 06:09:48 AM
QuoteDo you use O2, or you just use SB?

In many ways SB and O2 are co-dependent on each other's success. It's like the 3M commercial.

QuoteWe don't write interpreters, we make them better.

I have dedicated my efforts on the Windows platform to take advantage of the features of O2 with SB for extending the language. Charles is the driving force to keeping SB relevant on Windows. The competition is fierce and you really have to have something special to get second looks. On Linux, I'm staying the course with ANSI/ISO C extension modules for portability.

FWIW @60 - That's cool, my karma and age match. (unsigned reality)
Title: Re: The compiler advantage
Post by: Theo Gottwald on August 16, 2013, 09:41:50 AM
Reading your posts, John i believe you had great chances to get politician in germany or USA.
You write ... well selected words. Where you don't really know much about the backgound.
Then you say "I'll let Charles explain you that".
;D
Why don't you come to germany? Our political parties look for such people ... lots talking. No deeper thoughts behind. Is it some sort of therapy we are making here?

PS: Sorry Jose, i just had to write this  :-X

@John: Whatever happens is often just a follow up. if  i or Jose get too many mails from forum members, asking for something to be changed. Hope for you, the therapy works.
Title: Re: The compiler advantage
Post by: Charles Pegge on August 16, 2013, 11:42:44 PM
OxygenBasic started out as a compile-to-memory system, so you go directly from Basic source script to binary code execution, without producing a PE file. Hence John's term Virtual DLL, when this technique is used in conjunction with an interpreter, or other system that normally uses DLL-based extension modules.

The current IDE provided is Scite, though personally, I still prefer to work with notepad, and launch programs directly from script.

For resource compiling and attachment to PE files, I've included GoRc and Res2Exe utilities in the tools/compilers section of the package. But most of my attention has been on the core language itself, and I not so keen to get too deeply embroiled in Windows API stuff.

Title: Re: The compiler advantage
Post by: John Spikowski on August 17, 2013, 02:07:18 AM
QuoteThe current IDE provided is Scite, though personally, I still prefer to work with notepad, and launch programs directly from script.

Charles,

Try Ultra Edit! (30 day free trial) I have used it for years.  It now comes with JavaScript as it's embedded scripting engine which would be a tantalizing replacement for what you are using FB for now.


Best text/programmers editor around for Windows. IMHO

John
Title: Re: The compiler advantage
Post by: José Roca on August 17, 2013, 02:29:22 AM
Neither GoRc nor Res2Exe are included in the package that I have downloaded: OxygenBasicA039.zip.
Title: Re: The compiler advantage
Post by: John Spikowski on August 17, 2013, 02:32:19 AM
Please use the current Work-In-Process (http://www.oxygenbasic.org/o2zips/OxygenBasic.zip) build.

This link (http://www.oxygenbasic.org/forum/index.php?topic=380.msg2755#msg2755) may also be helpful.
Title: Re: The compiler advantage
Post by: José Roca on August 17, 2013, 04:33:37 AM
Does O2 generate a log file when there are errors during compiling? I could modify my editor to work with O2, but a log file containing information of the error, the path of the file in which it has happened and the line and column is needed to load the file in the editor and position the caret in the offending line.
Title: Re: The compiler advantage
Post by: Zlatko Vid on August 17, 2013, 01:42:46 PM
Hello Power Rangers.. :)
There are already editor for Oxygen Basic called OxyEdit written by me and there is also editor
written in Oxygen called ASciEdit( still in development)...so IDE is not a problem from my point of view.
However i like your SED editor ..especially older version :)

And to not forget thanks again Jose for this great site which is full of programming resourses!
Title: Re: The compiler advantage
Post by: José Roca on August 17, 2013, 03:12:42 PM
Is not the IDE what worries me. Writing my own, I could add features not available in the compiler like attaching resources on the fly (Windows only, I don't intend to use Linux).
Title: Re: The compiler advantage
Post by: Charles Pegge on August 17, 2013, 05:41:15 PM
OxygenBasic currently produces a composite error message giving a description, a line, and the filename if the file is an INCLUDE.

I will need to provide additional calls to return these components separately, so that the compiler (usually gxo2.exe) can create a compatible logfile of for the IDE.

O2 compilers (front ends) are very easy to produce, so it would be no problem adapting one if necessary.

Including Aurel's we have 4 IDE projects on the go, but nothing as extensive as CSED.

My ultimate dream IDE is Opengl-driven with its own windows-independent controls, code-base, and integral help. The GUI part is now feasible, but there is a mountain of IDE logistics to pile on top.
Title: Re: The compiler advantage
Post by: John Spikowski on August 17, 2013, 06:44:56 PM
QuoteIs not the IDE what worries me. Writing my own, I could add features not available in the compiler like attaching resources on the fly (Windows only, I don't intend to use Linux).

Thanks José for taking a peek at O2!

FYI: O2 supports 64 bit Windows which may extend your reach if needed.



Title: Re: The compiler advantage
Post by: John Spikowski on August 17, 2013, 08:13:25 PM
QuoteMy ultimate dream IDE is Opengl-driven with its own windows-independent controls, code-base, and integral help. The GUI part is now feasible, but there is a mountain of IDE logistics to pile on top.

(http://files.allbasic.info/RTB/rtb_android.png)

C4droid's SDL plug-in has taken that approach with it's Java VM connection to Android.

Title: Re: The compiler advantage
Post by: José Roca on August 17, 2013, 09:10:22 PM
I have been looking at the examples for classes and I think I could do at lot with them, but frankly, without documentation I'm a bit lost.

Suddenly, you find something like


  byte r,g,b,a
  =
  rgba as dword


What is this? Some kind of union?

or


  class stat
    method sum() as double
    method average() as double
    /\
    da(100) as double
    dn as long
  end class


What is /\?

or


'-------------
'THIS AND THAT
'=============

sys v=4

class c
  sys v
  method m()
    this.v=1
    print v
    print that.v
  end method
end class

dim as c d

d.m


What is "that"?

Also, I see examples in the forum using "del" with object variables, but not in the examples that come with the compiler, so I don't know if I have use del to destroy the class or not.

Too many questions.

I know that coding is the funny part and that nobody likes to write documentation, but...

I wrote a monster help file documenting all my wrappers. Knowing that if I had to write it when I had finished the wrappers I would never have done it, each time that I wrote a wrapper I wrote also the documentation before anything else.
Title: Re: The compiler advantage
Post by: John Spikowski on August 17, 2013, 09:51:48 PM
Welcome to Open Source!

O2 is only as good as the sum of it's parts. Charles is the brain, I'm the heart and we need you as a powerful set of lungs to absorb O2 and turn it into life.
Title: Re: The compiler advantage
Post by: Edwin Knoppert on August 17, 2013, 11:43:55 PM
>My ultimate dream IDE is Opengl-driven with its own windows-independent controls

And i by using html5/canvas!
Doable... very!
A combination angular and canvas may do it all..
Just extensive drawing to prepare the controls.
Title: Re: The compiler advantage
Post by: Charles Pegge on August 17, 2013, 11:58:54 PM
There are quite a few experimental constructs in OxygenBasic, which make documentation rather problematic while the rules are continually changing. So examples are the best way to express these constructs in the first instance.

Occasionally some ideas turn out to be unsound and are revoked, along with their examples. But most have survived. The trend has been to eliminate unnecessary syntax and to remove some of the single line restrictions imposed by classical Basic. Anyway, I think the core language is stable enough to do some more detailed documentation now.


To answer the specifics:

This is a simple way to make a union:

type pixel
byte red,green,blue, alpha
=
dword rgba
end type


This is a class header, normally produced automatically from an all-in-one class block The upper part is the static component, including the function address table. The lower part following /\ is the object body. The methods themselves would be contained in a separate methods..end methods block.

class stat
    method sum() as double
    method average() as double
    /\
    da(100) as double
    dn as long
  end class


Oxygen's objects may use 'new' and 'del' to specify that they use heap memory, but objects may also be local, static or global, in which case 'new' and 'del' are not used, and constructor/ destructor methods are not specifically required. These objects work much like a UDT, with all members initially set to null.

A particle class might look like this:

class particle
single posx,posy,posz
single velx,vely,velz
byte red,green,blue,alpha
single duration

method initial
'random ise attributes
...
end method

method update()
'update position etc
end method

method render()
...
end method

end class

particle p[1000]
...



'that' is an override for accessing variables of same name that exist outside the object.




Title: Re: The compiler advantage
Post by: José Roca on August 18, 2013, 05:48:48 AM
Understood. Thanks very much. Now, we have a dichotomy: O2 classes are more suitable for OOP, which is good for Linux users, that don't use COM, and PB is more suitable for COM programming, which is more prevalent in Windows. The ideal, of course, would be to have both in the same compiler.
Title: Re: The compiler advantage
Post by: John Spikowski on August 18, 2013, 06:35:44 AM
I notice very few questions on the PB forum or here about COM usage in PB. What percent of applications built with PB are COM centric? I know you have been able to make PB do everything but make your coffee in the morning but how many others use COM in this way? The other question I have is what percent of your include files are COM related?

I'm truly curious!

Title: Re: The compiler advantage
Post by: Theo Gottwald on August 18, 2013, 07:08:02 AM
Quote from: Zlatko Vid on August 17, 2013, 01:42:46 PM
Hello Power Rangers.. :)
There are already editor for Oxygen Basic called OxyEdit written by me and there is also editor
written in Oxygen called ASciEdit( still in development)...so IDE is not a problem from my point of view.
However i like your SED editor ..especially older version :)

And to not forget thanks again Jose for this great site which is full of programming resourses!

Charles, why don't you include something like this in the package - especially IF it has a SS-Debugger?
This could make things more easy for beginners.

Take the best 3rd Party IDE and put it into the package.

@Jose, the Source code for O2 is available. If you would start at this place you could avoid long discussions and it could start an interesting project here. Drop the Linux part and take it as a Start for something new.
Title: Re: The compiler advantage
Post by: José Roca on August 18, 2013, 07:18:53 AM
> [...] but how many others use COM in this way?

Few, but I no longer care much about what others do. I have other interests now.

> The other question I have is what percent of your include files are COM related?

At least two thirds.
Title: Re: The compiler advantage
Post by: John Spikowski on August 18, 2013, 07:38:26 AM
Thanks for your upfront and honest response!

I still would like to find a way to take advantage of all the hard work you invested in your include files with O2. (which by default would spill over into SB, TB, ...)
Title: Re: The compiler advantage
Post by: José Roca on August 18, 2013, 07:43:47 AM
Quote
@Jose, the Source code for O2 is available. If you would start at this place you could avoid long discussions and it could start an interesting project here. Drop the Linux part and take it as a Start for something new.

What for? Charles is doing an excellent job. Much better than I could do.
Title: Re: The compiler advantage
Post by: John Spikowski on August 18, 2013, 07:50:56 AM
If you could spell out the rules for a conversion from PB to O2, I would write the script in SB. Charles could fill in any holes that might show up in the process.

Title: Re: The compiler advantage
Post by: José Roca on August 18, 2013, 08:13:56 AM
Quote from: John Spikowski on August 18, 2013, 07:38:26 AM
Thanks for your upfront and honest response!

I still would like to find a way to take advantage of all the hard work you invested in your include files with O2. (which by default would spill over into SB, TB, ...)

If I did so much work was because I thought that if PBers weren't using COM was because PB had not a good implementation (just support for Automation and using a syntax that I disliked), and low-level COM needs headers. But I was wrong.

The bad thing is that, since several years ago, almost all of the new Windows technologies are only available as low-level COM servers, and PBers are ignoring them.
Title: Re: The compiler advantage
Post by: José Roca on August 18, 2013, 08:20:09 AM
Quote from: John Spikowski on August 18, 2013, 07:50:56 AM
If you could spell out the rules for a conversion from PB to O2, I would write the script in SB. Charles could fill in any holes that might show up in the process.

It must be easier for Charles to do it directly from the C++ headers. I use a lot of IAutomation interfaces that aren't supported by O2.
Title: Re: The compiler advantage
Post by: John Spikowski on August 18, 2013, 08:25:28 AM
QuoteIt must be easier for Charles to do it directly from the C++ headers.

Charles has already made excellent progress using C headers directly. You're right and an easier way to go.
Title: Re: The compiler advantage
Post by: Charles Pegge on August 18, 2013, 09:45:27 AM
Using and creating COM objects is quite easy. though the sheer scale of the COM system in MS is intimidating enough to put most basic programmers off from tapping into these resources.

Yes, OxygenBasic can use the C++ headers, with very little editing, but all the work that José put into translating those headers and examples, is an awesomely valuable cross-reference.

The essentials for COM programming are built-in to OxygenBasic, namely: guidval and guidtext functions, single-line inheritance, and virtual objects (object pointers). It is also easy to make class factories.

In o2 terms: COM objects are c;ient-side declared extern virtual and server-side implemented as extern.

The word from is used to indicate inheritance from a single class.

Here is is snippet from the voice header: (This would look so much cleaner translated into proper basic :) )


  extern virtual

  '-------------
  class IUnknown
  '=============

    HRESULT QueryInterface(refiid id, pvObject* ppv)
    ULONG   AddRef()
    ULONG   Release()

  end class


  'from sapi.h


  'MIDL_INTERFACE("5EFF4AEF-8487-11D2-961C-00C04F8EE628")
  'ISpNotifySource : public IUnknown
  '
  '--------------------
  class ISpNotifySource
  '====================

    public

    from IUnknown

        HRESULT SetNotifySink(
            /* [in] */ __RPC__in_opt ISpNotifySink *pNotifySink)
       
        HRESULT SetNotifyWindowMessage(
            /* [in] */ HWND hWnd,
            /* [in] */ UINT Msg,
            /* [in] */ WPARAM wParam,
            /* [in] */ LPARAM lParam)
       
        HRESULT SetNotifyCallbackFunction(
            /* [in] */ SPNOTIFYCALLBACK *pfnCallback,
            /* [in] */ WPARAM wParam,
            /* [in] */ LPARAM lParam)
       
        HRESULT SetNotifyCallbackInterface(
            /* [in] */ ISpNotifyCallback *pSpCallback,
            /* [in] */ WPARAM wParam,
            /* [in] */ LPARAM lParam)
       
        HRESULT SetNotifyWin32Event( void)
       
        HRESULT WaitForNotifyEvent(
            /* [in] */ DWORD dwMilliseconds)
       
        HANDLE GetNotifyEventHandle( void)

  end class


Title: Re: The compiler advantage
Post by: José Roca on August 18, 2013, 08:39:12 PM
Charles, can O2 methods return an structure as the result value of a method, not by passing it by reference? I ask it because then classes could be written to add support to VARIANTs and PROPVARIANTs. My headers contain CVariant.inc, that extends PB's VARIANT support with some 180 methods, and CPropVariant.inc. VARIANTs are used extensively in COM programming and PROPVARIANTs are being used extensively in the latest M$ COM servers.
Title: Re: The compiler advantage
Post by: Charles Pegge on August 19, 2013, 12:33:59 AM
Yes, something along these lines:


class cVariant

'   ' =====================================================================================
'   ' Initializes a VARIANT with a 32-bit integer value.
'   ' =====================================================================================
'   METHOD FromInt32 (BYVAL lVal AS LONG) AS VARIANT
'      LOCAL v AS VARIANT
'      LOCAL pv AS tagVARIANT PTR
'      pv = VARPTR(v)
'      @pv.vt = %VT_I4
'      @pv.lVal = lVal
'      METHOD = v
'   END METHOD
'   ' =====================================================================================

method FromInt32(long lval) as VARIANT
let v=new VARIANT
v.vt=VT_I4
v.vd.lval=lval
return &v
end method

'...

end class

cVariant cv

let v=new cv.FromInt32(42)
...
Title: Re: The compiler advantage
Post by: Theo Gottwald on August 19, 2013, 07:36:00 PM
Quoteand PBers are ignoring them.

To me this stuff has something together with chinese characters.
It looks nice, some look like a tree, some like a box but i have no idea why its just at that place.

The programming paradigm behind these so called COM-Objects is so far from "Normal" (NOT object oriented programming),
that the switch between these two needs a total reset in the programmers brain possibly.
At least i could not yet get the idea behind these COM-Objects.

Why should i use Variant for everything if a BYTE is enough?
We just come from a school where we learned that we do not waste memory if we do not have to.
If i can programm it hyperfast, i have a hard time to choose the slow way.
If i can make it DLL independent, i will not use a MS DLL that can be missing or changed in a further OS.

Only if there is no way around i am jumping in that COM bath at least currently.
It looks all so bloated to me. People who learn programming this way will see that different.
We learned in byte-byte Assembler at a time when 8 KB were a lot and with 32 kb you had been the King :-).
Now today things changed and it will take time to understand the new wasteful paradigms.
Title: Re: The compiler advantage
Post by: José Roca on August 19, 2013, 07:42:03 PM
You still don't have the slighhtest idea of what low-level COM is. You're talking of Automation. They are very different animals.
Title: Re: The compiler advantage
Post by: Theo Gottwald on August 19, 2013, 07:44:06 PM
You said in one sentence what i said flowerly in an article  ;D
At least you see that i try to be more diplomatic.
Title: Re: The compiler advantage
Post by: John Spikowski on August 19, 2013, 08:56:20 PM
The world is over populated with brown nosed sheep. Pick something you're good at and master that. I think José's include files is an excellent example of refined passion in action.
Title: Re: The compiler advantage
Post by: José Roca on August 19, 2013, 09:40:22 PM
A total waste of time, as you can see. Pray for Metro failure, because its API is all low-level COM. Time to retire.
Title: Re: The compiler advantage
Post by: John Spikowski on August 19, 2013, 09:51:40 PM
That still doesn't change the fine effort and ongoing resource (as Charles mentioned) to how COM works.

I wish PB could figure how to keep a forum up (seems down once again) before spending any more time on the back room projects we are suppose to start getting excited about.

Title: Re: The compiler advantage
Post by: Charles Pegge on August 19, 2013, 10:52:37 PM
All typeless scripts need something like a variant, so that variable types may be set in run-time, and automatically coverted from one type to another when necessary.

I would be quite tempted to manage variant setting in a single function with a select-case block, rather than use separate methods for each type. At the binary level, case selection is very fast, and you can put the most commonly used types at the top of the case list.
Title: Re: The compiler advantage
Post by: John Spikowski on August 20, 2013, 05:35:56 AM
Why everyone is dreaming how great it would be to see José's include files working with O2, I thought I would give you guys something to play with on your Android device.  8) 

(http://files.allbasic.info/QB45/qb45.png)

Note: The screen copy and reduction didn't do what this really looks like justice.

more ... (http://www.allbasic.info/forum/index.php?topic=224.0)
Title: Re: The compiler advantage
Post by: Frederick J. Harris on August 20, 2013, 03:46:44 PM
Quote
Only if there is no way around i am jumping in that COM bath at least currently.
It looks all so bloated to me. People who learn programming this way will see that different.

I personally don't feel bloat is a necessary part of COM Theo.  To my mind, COM is just a specific architecture with a specific layout of such things as VTables, so on and so forth, that brings some advantages that non COM objects lack.  I think I figured out once what the added baggage was, for example, a visual control in custom control form compared to ActiveX Control form, and its only a few K (3 or 4 or 5 or something like that).  If you would implement all the ActiveX Control interfaces it would be a few more, but not that many. 

I know this is an often mentioned criticism of COM, but I'd have to say my experience substantiates what Jose has said many times about it as not being bloated.  Just to give the example I've been working with for the past couple years, lately I've been replacing the SIGrid custom control in my work apps with the COM based grid control I posted down on my board here.  The SIGrid control was a full featured grid control that came in 49K compressed.  My COM based grid control is 22K compressed.  I don't think of that as being bloated.

It seems to me bloat is more associated with the coder and the tools he/she uses.  It is a bit hard for some of us who started back in the late 70s or early 80s to tolerate some of the code one sees, that's for sure.   My unique circumstance is such that I'm not obligated to use bloatware or deal with it in any way, so I just avoid it as a matter of personal preference.
Title: Re: The compiler advantage
Post by: José Roca on August 20, 2013, 05:34:30 PM
If they tried from themselves, instead of talking from hearsay, they will realize how wrong they are. Anyway, if they are happy renouncing to the access of two thirds of the operating system, so be it. I no longer care.
Title: Re: The compiler advantage
Post by: John Spikowski on August 20, 2013, 05:51:00 PM
QuoteI no longer care.

Can you clarify that for me?

A. I no longer care about trying to convince PB programmers that COM is the framework Windows in built on?

B. I no longer care about COM programming and I'm ready to retire.

C. I need a vacation.

Title: Re: The compiler advantage
Post by: José Roca on August 20, 2013, 06:20:29 PM
A, B and C. If it doesn't happen something exciting, I have better things to do.
Title: Re: The compiler advantage
Post by: John Spikowski on August 20, 2013, 06:36:40 PM
If you want fun and excitement, join us on the the OxygenBasic forum. Charles is more than a wizard behind the curtain and actually comes though with his promises of a better BASIC compiler. How does it feel to have the source of the compiler to do what you think is right?

In a way I've been where you are now. When the best of the best told me there was no hope left and wanted me give authorization to remove my daughter from life support, I told them they didn't try hard enough and I would find the way. My daughter is a functional quadriplegic and minus a lung but she is happy I didn't give up on her and that I found the one in the million second chance at life.

Moral of the story: There isn't anything you can't do if you try hard enough.

Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 12:02:46 AM
Good News! (http://www.allbasic.info/forum/index.php?topic=224.msg2548#msg2548)  (Android users - DOSBox)



Title: Re: The compiler advantage
Post by: Guy Dombrowski on August 21, 2013, 02:11:30 AM
John,

Do you mean that my old QB45 programs could work in an Android OS ?
Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 03:21:57 AM
Running in a DOSBox on Android Linux OS, should work great. All the QB45 examples I tried  (source and compiled) run great.

Samsung Galaxy Tab 2 10.1 tablet - full res portrait mode

(http://files.allbasic.info/DOSBox/qb45_portrait.png)
Title: Re: The compiler advantage - PBDOS Android
Post by: John Spikowski on August 21, 2013, 06:45:03 AM
Works great!

FYI The version of C4droid I'm using hasn't been released yet. Google Play version is SDL 1.2 and I don't know if the DOSBox example is include / works under that version. Feel free to grab my compiled copy until your can generate your own DOSBox APK.

(http://files.allbasic.info/DOSBox/pb35.png)

43/50 mode

(http://files.allbasic.info/DOSBox/pb35_4350.png)

PBDOS 3.5 on fire

(http://files.allbasic.info/DOSBox/pbdos_fire.png)
Title: Re: The compiler advantage
Post by: Chris Holbrook on August 21, 2013, 05:09:27 PM
Quote from: José Roca on August 20, 2013, 05:34:30 PMI no longer care.
Nil carborundum José!

By using COM, often following your examples,  I have proved to myself that it is fast and compact enough - not that my applications are very demanding of the machine. Even though as an OOP coder I had to sulk for a while about the inheritance "problem".

PB has attracted a lot of reactionary users. I blame the licencing model, it is too democratic.
Title: Re: The compiler advantage
Post by: Chris Holbrook on August 21, 2013, 05:12:22 PM
Quote from: Guy Dombrowski on August 21, 2013, 02:11:30 AM
John,

Do you mean that my old QB45 programs could work in an Android OS ?
Yes. My PB ones do, and I carry a demonstration application on my phone. A keyboard is advisable!
Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 05:27:21 PM
Chris,

Have you been running DOSBox prior to my post? Reason I ask is I'm looking for feedback with this cutting edge SDL 2 version and if anyone notices any performance differences with my version being native compiled.


John
Title: Re: The compiler advantage
Post by: José Roca on August 21, 2013, 06:11:13 PM
Quote from: Chris Holbrook on August 21, 2013, 05:09:27 PM
Quote from: José Roca on August 20, 2013, 05:34:30 PMI no longer care.
Nil carborundum José!

By using COM, often following your examples,  I have proved to myself that it is fast and compact enough - not that my applications are very demanding of the machine. Even though as an OOP coder I had to sulk for a while about the inheritance "problem".

PB has attracted a lot of reactionary users. I blame the licencing model, it is too democratic.

I'm not talking about writing COM servers or classes, but about using COM to use the servers provided by the operating system. Once upon a time, M$ used to provide both flat APIs and COM servers for its technologies, but no longer. Therefore, to use them, you have to use COM. There is no choice. In these times of high resolution screens, it is frustrating to see programs that are not High DPI aware and graphic applications that use the obsolete GDI. My headers provide support for DirectX, Direct2D, DirectWrite, Windows Image Component, etc., but only Patrice has tried it.
Title: Re: The compiler advantage
Post by: Edwin Knoppert on August 21, 2013, 06:33:33 PM
And many of us won't care until they get forced..
So give up the 'fight' :)

Anyway, fun to see QB on such a device..
Title: Re: The compiler advantage
Post by: James C. Fuller on August 21, 2013, 06:37:37 PM
José,
  Be it known that there is no better solution, that I am aware, for creating COM object's than PowerBASIC
I believe Fred will attest to that.

James
Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 06:48:15 PM
As I understand it SysWOW64 is an emulation and Windows 64 bit is the predominant code base. Is M$ only investing in 64 bit COM going forward and PB's COM is doomed to a 32 bit emulated COM base?

Quote from: Edwin
Anyway, fun to see QB on such a device.

I think it's more fun than most of the games out there and one app (DOSBox) plays many sub-apps (DOS programs) that you already said goodbye to. Sort of like seeing your first love again after 20 years and realizing she wasn't all that bad.  :)

Karma -79 Looks like a lot of hurting PB'ers out there. Based on what I've seen with Patrice's awaking from being a PB zombie is there still remains a desire to save the rest even though the attempt may be futile.
Title: Re: The compiler advantage
Post by: José Roca on August 21, 2013, 08:15:21 PM
Quote
As I understand it SysWOW64 is an emulation and Windows 64 bit is the predominant code base. Is M$ only investing in 64 bit COM going forward and PB's COM is doomed to a 32 bit emulated COM base?

No. There are 32 bit servers and 64 bit servers. The operating system knows which ones to use.
Title: Re: The compiler advantage
Post by: Chris Holbrook on August 21, 2013, 08:24:31 PM
Quote from: John Spikowski on August 21, 2013, 05:27:21 PMHave you been running DOSBox prior to my post?
Installed on my phone about 18 months ago.
Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 08:27:35 PM
Chris,

Would you be willing to give my version of DOSBox a try and let me know what you think?

John
Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 08:42:40 PM
QuoteNo. There are 32 bit servers and 64 bit servers. The 64 bit operating system knows which ones to use.

José,

Just hear me out. I know you're frustrated and disappointed that your efforts aren't more widely used but if you were willing to try and save your includes, wouldn't a 32/64 bit O2 version be more attractive?  Using an open source compiler will require less magic on your part.

John
Title: Re: The compiler advantage
Post by: José Roca on August 21, 2013, 08:57:20 PM
C++ compilers already have headers and I'm no currently interested in other dialects of BASIC. Besides, I'm not a supporter of open source.
Title: Re: The compiler advantage
Post by: Chris Holbrook on August 21, 2013, 08:59:45 PM
Quote from: José Roca on August 21, 2013, 06:11:13 PMIn these times of high resolution screens, it is frustrating to see programs that are not High DPI aware and graphic applications that use the obsolete GDI. My headers provide support for DirectX, Direct2D, DirectWrite, Windows Image Component, etc., but only Patrice has tried it.
While taking your point about using W$ COM interfaces, I don't share your frustration, because I am not a "leading-edge" guy. For my commercial purposes, hardware could have stopped at any point since 1983, although it hasn't, and I have been dragged along with developments. Innovations in the last eight years - Windows replacing MSDOS, using the PowerBASIC compilers (amongst others), SQLite, Collections, GDI/GDI+ graphics. Currently celebrating the non-demise of PowerBASIC, Inc by writing a character mode framework in which to redevelop feature-poor MSDOS applications for Windows 7, which M$ says is good until 2025.






Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 09:15:44 PM
QuoteC++ compilers already have headers and I'm no currently interested in other dialects of BASIC. Besides, I'm not a supporter of open source.

Thank you for your concise answer to my pestering you in a direction of no interest.

Just the text versions of your includes as a resource will have value for years.

P.S.

Thanks for the karma reset. Rejoining at a -25 was hard to overcome.
Title: Re: The compiler advantage
Post by: Edwin Knoppert on August 21, 2013, 09:37:20 PM
Quote from: John Spikowski on August 21, 2013, 06:48:15 PM
Karma -79 Looks like a lot of hurting PB'ers out there. Based on what I've seen with Patrice's awaking from being a PB zombie is there still remains a desire to save the rest even though the attempt may be futile.

They shouldn't nitpick the nitpicker so much.
I like nitpicking, it brings just a different perspective and often food for thought, even if one is wrong, it doesn't matter..
:)
Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 09:43:39 PM
QuoteThey shouldn't nitpick the nitpicker so much.
I like nitpicking, it brings just a different perspective and often food for thought, even if one is wrong, it doesn't matter..

That's the best definition of what a forum is suppose to be that I have heard in some time. Thanks!

Title: Re: The compiler advantage
Post by: Chris Holbrook on August 21, 2013, 10:31:09 PM
Quote from: John Spikowski on August 21, 2013, 08:27:35 PM
Would you be willing to give my version of DOSBox a try and let me know what you think?
In principle, yes, but best after I get my new keyboard, currently using a remote keyboard app which is ingenious but painful.
I'll let you know when. Do you have a list of enhancements somewhere?
Title: Re: The compiler advantage
Post by: John Spikowski on August 21, 2013, 10:51:23 PM
QuoteI'll let you know when. Do you have a list of enhancements somewhere?

This is what I noticed between the aDosBox version I downloaded pre-compiled and DOSBox I compiled local on Android using the latest CVS source and the latest SDL 2 for Android.


  • Uses maximum screen real estate and reacts to on-the-fly orientation rotations.
  • Uses the latest DOSBox source tree.
  • Uses the latest SDL 2 source tree.
  • Has the C4droid SDL enhancements that will show up in an upcoming release.
  • Fully configurable set of button controls to use as hot keys specific to the app without having to pop the keyboard.
  • Seems to run faster and smother being native compiled. g++ may be taking advantage of ARM RISC features the NDK doesn't offer.
  • Having source and being able to recompile the emulator on the device is a big plus. (meal and the chief for free)
  • Seems to run everything DOS based I've thrown at it. (even low level direct memory addressing stuff)
Title: Re: The compiler advantage
Post by: Chris Holbrook on August 21, 2013, 11:52:41 PM
Quote from: John Spikowski on August 21, 2013, 10:51:23 PM
Seems to run everything DOS based I've thrown at it. (even low level direct memory addressing stuff)
My MSDOS app uses BIOS calls and direct screen memory addressing and inline assembler inside Borland Pascal and that works fine - DosBox version is  precompiled v0.74.
Title: Re: The compiler advantage
Post by: John Spikowski on August 22, 2013, 12:16:23 AM
QuoteDosBox version is  precompiled v0.74.

That is same pre-compiled version I started off with. (see early posts to AllBasic) If that's what your running, you really need to try my native compiled version.

Old pre-compiled version of DOSBox

(http://files.allbasic.info/QB45/dosbox.png)
Title: Re: The compiler advantage
Post by: Frederick J. Harris on August 22, 2013, 04:02:00 PM
Chris Holbrook says ...

Quote
While taking your point about using W$ COM interfaces, I don't share your frustration, because I am not a "leading-edge" guy. For my commercial purposes, hardware could have stopped at any point since 1983, although it hasn't, and I have been dragged along with developments. Innovations in the last eight years - Windows replacing MSDOS, using the PowerBASIC compilers (amongst others), SQLite, Collections, GDI/GDI+ graphics. Currently celebrating the non-demise of PowerBASIC, Inc by writing a character mode framework in which to redevelop feature-poor MSDOS applications for Windows 7, which M$ says is good until 2025.

That's a lot like me too, Chris, and I suspect a lot of others.  I work for a large forestry organization, and I write most of our data processing and database apps.  What it boils down to is should I spend a couple days writing data processing code that could save perhaps a man year of work by others, or spend a couple of days trying to figure out how to make rounded corners on my buttons that won't save anyone one second of time or save one dollar?  Or, alternately, try this ...  Like most coders I prefer to write code over writing help docs.  But most of my mission critical apps we use don't have much in the way of help docs written for them.  So should I spend my time writting help docs for these various apps, or should I spend my limited time pouring over Jose's and Patrice's code figuring out how I can make my apps look like the latest Norton Anti-virus software programs and other commercial offerings with various themes, translucent objects, so on and so forth?  Its certainly not that I think the modern look is without value; its just that for me other things outweigh it in importance.   
Title: Re: The compiler advantage
Post by: Chris Holbrook on August 22, 2013, 06:44:08 PM
Quote from: Frederick J. Harris on August 22, 2013, 04:02:00 PM... should I spend my limited time pouring over Jose's and Patrice's code ...
exactly. Yet I - among many, I'm sure - am so grateful to them for their generosity in sharing that code because I can mine it for the parts I need to do new tricks, and I post my own code "over there" sometimes to interpret, sometimes to stimulate discussion (which usually doesn't happen). The sheer volume of work which Jose has turned out is so impressive. I wish he worked for me, and in a way he does! This sort of thing is why I chose to get into Windows via PowerBASIC, because I saw that there were a few really good programmers (I've been around long enough to recognise the difference) who were both sharing and supportive. It would be a hell of a pity if that contribution was to dry up.
 
Title: Re: The compiler advantage
Post by: Frederick J. Harris on August 22, 2013, 07:43:43 PM
Quote
exactly. Yet I - among many, I'm sure - am so grateful to them ...

Very true.  I'd say the support Jose and others provided was the reason I chose PowerBASIC as my main programming language.  I felt the underlying language itself was extremely good, but at the time I became interested in it - middle to late 90s, there was no support for COM.  Because of the work Jose did in conjunction with Bob Zale's incorporation of COM support into the language with PowerBASIC For Windows Version 7, I decided to make PB my main language over Visual Basic.   
Title: Re: The compiler advantage
Post by: John Spikowski on August 22, 2013, 07:47:42 PM
I'm wondering if it is possible / practical to create a Doxygen (http://www.stack.nl/~dimitri/doxygen/) version of José's include files.

Title: Re: The compiler advantage
Post by: James C. Fuller on August 22, 2013, 07:52:28 PM
From the readme file of the headers.

This project is an effort to translate the C headers of the Microsoft Platform SDK for Windows to PowerBASIC™.
This version has been updated using the SDK for Windows 7.1.
These headers are freeware, not public domain. This means that you can use them for your own purposes, even in
commercial applications, without paying a fee, but not to make derivative works from, sell or redistribute without
permission. Also you must assume the entire risk of using them. Downloading the software indicates that you accept
these terms.

James
Title: Re: The compiler advantage
Post by: José Roca on August 22, 2013, 08:19:42 PM
Open Source supporters should learn the meaning of Freeware.
Title: Re: The compiler advantage
Post by: John Spikowski on August 22, 2013, 08:23:14 PM
QuoteOpen Source supporters should learn the meaning of PB Freeware.

Quote from: Henry FordAny customer can have a car painted any colour that he wants so long as it is black.

Doxygen is a industry standard code documentation system. Are you saying that documenting or even talking about your include files outside the scope to PowerBASIC is a violation of your right to use clause?

For those unfamiliar with Doxygen, here is a very old version of the ScriptBasic source I ran through the Doxygen tool to produce this HTML version (http://www.scriptbasic.org/docs/doxygen/index.html) of the documentation. 
Title: Re: The compiler advantage
Post by: John Spikowski on August 22, 2013, 10:59:03 PM
If documenting include files sounds like a bad idea, how about a RapidQ to PB DDT translator?

RapidQ Windows under Wine
(http://files.allbasic.info/AllBasic/rapidq.png)
Title: Re: The compiler advantage
Post by: Frederick J. Harris on August 23, 2013, 12:40:11 AM
Geez John!  You're down to -1 already from the reset!
Title: Re: The compiler advantage
Post by: John Spikowski on August 23, 2013, 01:11:25 AM
Can you feel the love?  :-*

Never mind. FreeQ (http://rapidq.phatcode.net/FreeQ/) is able to generate Rapid-Q and FreeBASIC source code. Maybe it would be worth someone's time to tweak the source to generate PowerBASIC code.

Rapid-Q

(http://files.allbasic.info/Rapid-Q/rqtest.png)


'
' <Program Name>
'
$APPTYPE GUI
$TYPECHECK ON

$INCLUDE <Rapidq2.inc>

CREATE Form1 AS QFORM
    Caption = "Main Form"
    Center
    CREATE Label1 AS QLABEL
        Left = 30
        Top = 33
        Width = 50
        Caption = "Software"
    END CREATE
    CREATE Edit1 AS QEDIT
        Left = 97
        Top = 34
        Width = 172
    END CREATE
    CREATE Butn1 AS QBUTTON
        Left = 122
        Top = 133
        Caption = "Download"
    END CREATE
END CREATE

SetWindowLong(Form1.Handle, GWL_HWNDPARENT, 0)
SetWindowLong(Application.Handle, GWL_HWNDPARENT, Form1.Handle)

Form1.ShowModal


FreeBASIC

(http://files.allbasic.info/Rapid-Q/fbtest.png)


'-------------------------------------------------------------------------------
' FreeBasic code generated by RapidFRM v1.84
'-------------------------------------------------------------------------------
#INCLUDE "windows.bi"
#INCLUDE "win/commctrl.bi"
InitCommonControls()

#DEFINE __QEDIT
#INCLUDE ONCE "win/richedit.bi"
#INCLUDE "C:/FreeQ/tools/RQInclude.bi"

'-------------------------------------------------------------------------------
' Global data from Form designer sheet
'-------------------------------------------------------------------------------
DIM SHARED AS QFORM Form1
DIM SHARED AS QFORM PTR lpForm1 = @Form1
DIM SHARED AS QLABEL Label1
DIM SHARED AS QLABEL PTR lpLabel1 = @Label1
DIM SHARED AS QEDIT Edit1
DIM SHARED AS QEDIT PTR lpEdit1 = @Edit1
DIM SHARED AS QBUTTON Butn1
DIM SHARED AS QBUTTON PTR lpButn1 = @Butn1

'-------------------------------------------------------------------------------
' Forward declarations for component events
'-------------------------------------------------------------------------------

'-------------------------------------------------------------------------------
' Configure components
'-------------------------------------------------------------------------------
SUB ConfigureComponents

    lpForm1->ObjIndex = 0
    lpForm1->Caption = "Main Form"

    lpLabel1->ObjIndex = 1
    lpLabel1->Left = 30
    lpLabel1->Top = 33
    lpLabel1->Width = 50
    lpLabel1->Caption = "Software"

    lpEdit1->ObjIndex = 2
    lpEdit1->Left = 97
    lpEdit1->Top = 34
    lpEdit1->Width = 172

    lpButn1->ObjIndex = 3
    lpButn1->Left = 122
    lpButn1->Top = 133
    lpButn1->Caption = "Download"

END SUB

'-------------------------------------------------------------------------------
' Create components
'-------------------------------------------------------------------------------
SUB CreateMainMenu
END SUB

SUB CreatePopupMenus
END SUB

SUB CreateComponents
DIM AS UINT StdStyle, ExtStyle=0
DIM AS string ObjCaption

    lpForm1->PreSetConfig()
    StdStyle=lpForm1->objStyle
    IF lpForm1->BorderStyle > bsDialog THEN ExtStyle=WS_EX_TOOLWINDOW

    lpForm1->Handle = CreateWindowEx(ExtStyle, "RQClass", lpForm1->Caption, StdStyle, _
                    lpForm1->Left, lpForm1->Top, lpForm1->Width, lpForm1->Height, _
                    0, 0, Application.hInstance, 0)
    Application.hMainForm = lpForm1->Handle
    lpForm1->PostConfig()

    lpLabel1->PreSetConfig()
    ObjCaption=lpLabel1->Caption
    StdStyle=lpLabel1->objStyle
    IF lpLabel1->Visible THEN StdStyle OR= WS_VISIBLE
    ExtStyle=0

    lpLabel1->Handle=CreateWindowEx(ExtStyle,lpLabel1->objClass, ObjCaption, WS_CHILD OR StdStyle, _
                    lpLabel1->Left, lpLabel1->Top, lpLabel1->Width, lpLabel1->Height, _
                    lpForm1->Handle, CAST(HMENU, lpLabel1->objIndex), 0, 0)

    lpLabel1->Parent = lpForm1->Handle
    lpLabel1->PostConfig()
    EnableWindow(lpLabel1->Handle, lpLabel1->Enabled)

    lpEdit1->PreSetConfig()
    ObjCaption=""
    StdStyle=lpEdit1->objStyle
    IF lpEdit1->Visible THEN StdStyle OR= WS_VISIBLE
    IF lpEdit1->BorderStyle=bsNone THEN ExtStyle=0 ELSE ExtStyle=WS_EX_CLIENTEDGE

    lpEdit1->Handle=CreateWindowEx(ExtStyle,lpEdit1->objClass, ObjCaption, WS_CHILD OR StdStyle, _
                    lpEdit1->Left, lpEdit1->Top, lpEdit1->Width, lpEdit1->Height, _
                    lpForm1->Handle, CAST(HMENU, lpEdit1->objIndex), 0, 0)

    lpEdit1->Parent = lpForm1->Handle
    lpEdit1->PostConfig()
    EnableWindow(lpEdit1->Handle, lpEdit1->Enabled)

    lpButn1->PreSetConfig()
    ObjCaption=lpButn1->Caption
    StdStyle=lpButn1->objStyle
    IF lpButn1->Visible THEN StdStyle OR= WS_VISIBLE
    ExtStyle=0

    lpButn1->Handle=CreateWindowEx(ExtStyle,lpButn1->objClass, ObjCaption, WS_CHILD OR StdStyle, _
                    lpButn1->Left, lpButn1->Top, lpButn1->Width, lpButn1->Height, _
                    lpForm1->Handle, CAST(HMENU, lpButn1->objIndex), 0, 0)

    lpButn1->Parent = lpForm1->Handle
    lpButn1->PostConfig()
    EnableWindow(lpButn1->Handle, lpButn1->Enabled)

    CreateMainMenu()
    CreatePopupMenus()
END SUB

'-------------------------------------------------------------------------------
' Remove Timers on Exit
'-------------------------------------------------------------------------------
SUB KillAllTimers
    KillTimer(Application.hMainForm, SYS_TIMER_IDX)
END SUB

'-------------------------------------------------------------------------------
' System timer - Display hints
'-------------------------------------------------------------------------------
SUB SysDisplayHint(Parent AS HWND, HintString AS string)
DIM AS TOOLINFO ti

    ti.cbSize=sizeof(ti)
    ti.uFlags=TTF_SUBCLASS: ti.hwnd=Parent
    ti.hinst=NULL: ti.lpszText=STRPTR(HintString)
    GetClientRect(Parent, @ti.rect)
    SendMessage(Application.hWndTTip, TTM_ADDTOOL, 0, CAST(LPARAM, @ti))
END SUB

SUB CheckSystemTimers
STATIC AS HWND TT_LastHWND
DIM AS HWND TT_hWnd
DIM AS Point TT_pnt

    TT_pnt.X=Screen.MouseX: TT_pnt.Y=Screen.MouseY
    TT_hWnd=WindowFromPoint(TT_pnt)
    IF TT_LastHWND<>TT_hWnd THEN
        TT_LastHWND=TT_hWnd
        SELECT CASE TT_hWnd
            CASE lpForm1->Handle
                IF lpForm1->ShowHint THEN
                    SysDisplayHint(lpForm1->Handle, lpForm1->Hint)
                END IF
            CASE lpLabel1->Handle
                IF lpLabel1->ShowHint THEN
                    SysDisplayHint(lpLabel1->Handle, lpLabel1->Hint)
                END IF
            CASE lpEdit1->Handle
                IF lpEdit1->ShowHint THEN
                    SysDisplayHint(lpEdit1->Handle, lpEdit1->Hint)
                END IF
            CASE lpButn1->Handle
                IF lpButn1->ShowHint THEN
                    SysDisplayHint(lpButn1->Handle, lpButn1->Hint)
                END IF
        END SELECT
    END IF
END SUB

'-------------------------------------------------------------------------------
' Start of Main WndProc code
'-------------------------------------------------------------------------------

SUB CheckWmTimers(hWnd AS HWND, wMsg AS UINT, wParam AS WPARAM, lParam AS LPARAM)
    SELECT CASE wParam
        CASE App_Timer.ObjIndex:  CheckSystemTimers
    END SELECT
END SUB

SUB CheckWmCommandMsg(wParam AS WPARAM, lParam AS LPARAM)
    SELECT CASE LOWORD(wParam)
        CASE lpLabel1->ObjIndex
            IF lpLabel1->OnClick>0 THEN lpLabel1->OnClick(lpLabel1)
        CASE lpEdit1->ObjIndex
            IF lpEdit1->OnChange>0 THEN lpEdit1->OnChange(lpEdit1)
        CASE lpButn1->ObjIndex
            IF lpButn1->OnClick>0 THEN lpButn1->OnClick(lpButn1)
    END SELECT
END SUB

SUB CheckWmNotifyMsg(wParam AS WPARAM, lParam AS LPARAM)
END SUB

SUB CheckWmPaintMsg(hWnd AS HWND, wMsg AS UINT, wParam AS WPARAM, lParam AS LPARAM)
    IF lpForm1->OnPaint>0 THEN lpForm1->OnPaint(lpForm1)
END SUB

FUNCTION CheckBtnColor(wParam AS WPARAM, lParam AS LPARAM) AS LRESULT
DIM AS HBRUSH hBrush=NULL
' Only for OwnerDraw buttons
    RETURN CAST(LRESULT, hBrush)
END FUNCTION

FUNCTION CheckStaticColor(wParam AS WPARAM, lParam AS LPARAM) AS LRESULT
DIM AS HBRUSH hBrush=NULL
DIM AS HDC hDC=CAST(HDC, wParam)
DIM AS HWND Handle=CAST(HWND, lParam)

    SELECT CASE Handle
        CASE lpLabel1->Handle
            SetBKMode(hDC, 1)
            SetTextColor(hDC, CAST(COLORREF, lpLabel1->Font.Color))
            hBrush=CreateSolidBrush(CAST(COLORREF, lpLabel1->Color))
    END SELECT
    RETURN CAST(LRESULT, hBrush)
END FUNCTION

FUNCTION CheckEditColor(wParam AS WPARAM, lParam AS LPARAM) AS LRESULT
DIM AS HBRUSH hBrush=NULL
DIM AS HDC hDC=CAST(HDC, wParam)
DIM AS HWND Handle=CAST(HWND, lParam)

    SELECT CASE Handle
        CASE lpEdit1->Handle
            SetBKMode(hDC, 1)
            SetTextColor(hDC, CAST(COLORREF, lpEdit1->Font.Color))
            hBrush=CreateSolidBrush(CAST(COLORREF, lpEdit1->Color))
    END SELECT
    RETURN CAST(LRESULT, hBrush)
END FUNCTION

FUNCTION CheckListBoxColor(wParam AS WPARAM, lParam AS LPARAM) AS LRESULT
DIM AS HBRUSH hBrush=NULL
    RETURN CAST(LRESULT, hBrush)
END FUNCTION

SUB CheckWmObjScroll(hWnd AS HWND, wMsg AS UINT, wParam AS WPARAM, lParam AS LPARAM)
END SUB

SUB CheckSocketEvent(hWnd AS HWND, wMsg AS UINT, wParam AS WPARAM, lParam AS LPARAM)
END SUB

' Hook into the Popup menus for all of your components here
SUB CheckWmContextMenu(hWnd AS HWND, wMsg AS UINT, wParam AS WPARAM, lParam AS LPARAM)
END SUB

SUB CheckWmHitTest(hWnd AS HWND, wMsg AS UINT, wParam AS WPARAM, lParam AS LPARAM)
END SUB

SUB CheckWmDrawItem(wParam AS WPARAM, lParam AS LPARAM)
END SUB

FUNCTION MainWndProc(hWnd AS HWND, wMsg AS UINT, wParam AS WPARAM, lParam AS LPARAM) AS LRESULT
STATIC AS integer Sizing
   
    SELECT CASE wMsg
        CASE WM_CREATE
            Sizing=False

        CASE WM_COMMAND
            IF lParam<>0 THEN
                CheckWmCommandMsg(wParam, lParam)
            ELSE
                ' IF HIWORD(wParam)=0 THEN
                '     Menu message code goes here.....
                ' ELSE
                '     Accelerator message code goes here...
                ' END IF
            END IF

        CASE WM_NOTIFY
            CheckWmNotifyMsg(wParam, lParam)

        CASE WM_PAINT
            CheckWmPaintMsg(hWnd, wMsg, wParam, lParam)

        CASE WM_TIMER
            CheckWmTimers(hWnd, wMsg, wParam, lParam)

        CASE WM_NCHITTEST
            CheckWmHitTest(hWnd, wMsg, wParam, lParam)

        CASE WM_HSCROLL, WM_VSCROLL
            IF lParam<>0 THEN CheckWmObjScroll(hWnd, wMsg, wParam, lParam)

        CASE WM_CTLCOLORBTN
            RETURN CheckBtnColor(wParam, lParam)

        CASE WM_CTLCOLOREDIT
            RETURN CheckEditColor(wParam, lParam)

        CASE WM_CTLCOLORSTATIC
            RETURN CheckStaticColor(wParam, lParam)

        CASE WM_CTLCOLORLISTBOX
            RETURN CheckListBoxColor(wParam, lParam)

        CASE WM_DRAWITEM
            CheckWmDrawItem(wParam, lParam)

        CASE WM_CONTEXTMENU
            CheckWmContextMenu(hWnd, wMsg, wParam, lParam)

        CASE WM_SOCK_NOTIFY
            CheckSocketEvent(hWnd, wMsg, wParam, lParam)

        CASE WM_MOUSEMOVE
            IF lpForm1->Cursor<>crDefault THEN
                DIM AS HCURSOR oldCursor=SetCursor(lpForm1->hCursor)
            END IF
            IF lpForm1->OnMouseMove>0 THEN
                lpForm1->OnMouseMove(LOWORD(lParam), HIWORD(lParam), 0, lpForm1)
            END IF

        CASE WM_LBUTTONDBLCLK
            IF lpForm1->OnClick>0 THEN lpForm1->OnClick(lpForm1)

        CASE WM_LBUTTONDOWN
            IF lpForm1->OnMouseDown>0 THEN
                lpForm1->OnMouseDown(MK_LBUTTON, LOWORD(lParam), HIWORD(lParam), 0, lpForm1)
            END IF

        CASE WM_LBUTTONUP
            IF lpForm1->OnMouseUp>0 THEN
                lpForm1->OnMouseUp(MK_LBUTTON, LOWORD(lParam), HIWORD(lParam), 0, lpForm1)
            END IF
            IF lpForm1->OnClick>0 THEN lpForm1->OnClick(lpForm1)

        CASE WM_RBUTTONDOWN
            IF lpForm1->OnMouseDown>0 THEN
                lpForm1->OnMouseDown(MK_RBUTTON, LOWORD(lParam), HIWORD(lParam), 0, lpForm1)
            END IF

        CASE WM_RBUTTONUP
            IF lpForm1->OnMouseUp>0 THEN
                lpForm1->OnMouseUp(MK_RBUTTON, LOWORD(lParam), HIWORD(lParam), 0, lpForm1)
            END IF

        CASE WM_KEYDOWN
            IF lpForm1->OnKeyDown>0 THEN lpForm1->OnKeyDown(LOWORD(wParam), 0, lpForm1)

        CASE WM_KEYUP
            IF lpForm1->OnKeyUp>0 THEN lpForm1->OnKeyUp(LOWORD(wParam), 0, lpForm1)

        CASE WM_CHAR
            IF lpForm1->OnKeyPress>0 THEN lpForm1->OnKeyPress(LOBYTE(wParam), lpForm1)

        CASE WM_SYSCOMMAND
            IF (wParam AND &hfff0) = SC_CLOSE THEN
                DIM AS integer Action=1                                      ' Default Action is quit
                IF lpForm1->OnClose>0 THEN lpForm1->OnClose(Action, lpForm1) ' Action passed by reference so
                IF Action=0 THEN RETURN 0                                    ' user can change default action
            END IF

        CASE WM_ENTERSIZEMOVE
            Sizing=True

        CASE WM_EXITSIZEMOVE
            lpForm1->FormReSize()
            Sizing=False
            IF lpForm1->OnResize>0 THEN
                lpForm1->OnResize(lpForm1)
                InvalidateRect(hWnd, NULL, True)
                RETURN 0
            END IF

        CASE WM_SIZE
            IF Sizing THEN RETURN 0
            IF (wParam=SIZE_MAXIMIZED) OR (wParam=SIZE_RESTORED) THEN
                IF wParam=SIZE_MAXIMIZED THEN
                    lpForm1->WindowState=wsMaximized
                ELSE
                    lpForm1->WindowState=wsNormal
                END IF
                lpForm1->FormReSize()
                IF lpForm1->OnResize>0 THEN
                    lpForm1->OnResize(lpForm1)
                    RETURN 0
                END IF
            END IF

        CASE WM_CLOSE

        CASE WM_DESTROY
            KillAllTimers()
            PostQuitMessage(0)

    END SELECT

    RETURN DefWindowProc(hWnd, wMsg, wParam, lParam)
END FUNCTION

'-------------------------------------------------------------------------------
' Create new window class for project
'-------------------------------------------------------------------------------
FUNCTION CreateWindClass(hInst AS HINSTANCE) AS integer
DIM AS WNDCLASSEX wc

WITH wc
    .cbSize = SizeOf(WNDCLASSEX)
    .style = CS_HREDRAW OR CS_VREDRAW
    .lpfnWndProc = @MainWndProc
    .hInstance = hInst
    .hIcon = LoadIcon(0, IDI_APPLICATION)
    .hCursor = LoadCursor(0, IDC_ARROW)
    .hbrBackground = GetSysColorBrush(COLOR_BTNFACE)
    .lpszClassName = @"RQClass"
    .hIconSm = .hIcon
END WITH

    RETURN RegisterClassEx(@wc)
END FUNCTION

'-------------------------------------------------------------------------------
' Main startup code
'-------------------------------------------------------------------------------
FUNCTION WinMain(hInst AS HINSTANCE, hPrevInstance AS HINSTANCE, _
                            szCmdLine AS string, iCmdShow AS integer) AS integer
DIM AS integer Result=0

    IF CreateWindClass(hInst) = 0 THEN
        ShowMessage("Register class error")
        RETURN 0
    END IF

    ConfigureComponents()
    CreateComponents()
    InitSystemTimers(lpForm1->Handle)
    HookTheMouse()

    lpForm1->Center                         ' You may wish to delete this line

    IF lpForm1->OnShow>0 THEN lpForm1->OnShow(lpForm1)

    Result = lpForm1->ShowModal             ' Show form & call default message handler

    ' You may want to change the above line to lpForm1->Show, and then provide
    ' your own function that, amongst other things, handles all window messages.

    UnHookTheMouse()

    RETURN Result
END FUNCTION

'-------------------------------------------------------------------------------
' *** MAIN ENTRY POINT ***
'-------------------------------------------------------------------------------
END WinMain(Application.hInstance, NULL, Command(0), SW_NORMAL)


'-------------------------------------------------------------------------------
' Code for the component events
'-------------------------------------------------------------------------------
Title: Re: The compiler advantage
Post by: Brice Manuel on August 23, 2013, 07:43:06 AM
Quote from: José Roca on August 21, 2013, 06:11:13 PMThere is no choice. In these times of high resolution screens, it is frustrating to see programs that are not High DPI aware and graphic applications that use the obsolete GDI. My headers provide support for DirectX, Direct2D, DirectWrite, Windows Image Component, etc., but only Patrice has tried it.

I have used your headers.  But the problem with Direct2D and DirectWrite is DirectX itself.  DirectX is a minefield on Windows due to the lack of proper support and compatibility issues.  Most Vista and 7 systems sold did NOT properly support the operating system they shipped with.  Most Vista systems were reduced to using 10Level9 to pull of the graphical effects.  7 was still down converting to 9 or 10 for many systems due to compatibility issues.  It wasn't until around the time that 7 SP1 hit that Intel based systems finally had an inbuilt GPU that would properly handle DX11 which is what 7 is supposed to have.  Systems shipping with Windows 8 are better in this regards, unfortunately, nobody is buying them.

Unless you are using the industry standard which is OpenGL which simply just works and is highly compatible, if you want something that just works on Windows and does not suffer compatibility issues, you have no choice but to use GDI or GDI+ in some cases (which is in itself old).  Everything started moving towards being hardware accelerated with Vista.  With 8, virtually everything is now hardware accelerated.  If you are using GDI on 8, it is now fully hardware accelerated just as newer APIs like D2D are.
Title: Re: The compiler advantage
Post by: Brice Manuel on August 23, 2013, 07:52:58 AM
Quote from: John Spikowski on August 22, 2013, 07:47:42 PM
I'm wondering if it is possible / practical to create a Doxygen (http://www.stack.nl/~dimitri/doxygen/) version of José's include files.

It would depend on what license MS released their code under, as Jose converted MS's C++ headers to PB, IIRC.  Jose can't impose new restrictions on code that belongs to somebody else that he merely modified.
Title: Re: The compiler advantage
Post by: Brice Manuel on August 23, 2013, 07:58:24 AM
Quote from: John Spikowski on August 23, 2013, 01:11:25 AM
Can you feel the love?  :-*

Never mind. FreeQ (http://rapidq.phatcode.net/FreeQ/) is able to generate Rapid-Q and FreeBASIC source code. Maybe it would be worth someone's time to tweak the source to generate PowerBASIC code.


People are still using RapidQ?  Egads!  ???
Title: Re: The compiler advantage
Post by: Brice Manuel on August 23, 2013, 08:25:17 AM
Quote from: John Spikowski on August 22, 2013, 12:16:23 AM
QuoteDosBox version is  precompiled v0.74.

That is same pre-compiled version I started off with. (see early posts to AllBasic) If that's what your running, you really need to try my native compiled version.

Old pre-compiled version of DOSBox

(http://files.allbasic.info/QB45/dosbox.png)


DOSBox is the only thing I miss on my Kindle Fire.
Title: Re: The compiler advantage
Post by: John Spikowski on August 23, 2013, 09:44:48 AM
QuotePeople are still using RapidQ?  Egads!

Not me. I use IUP with ScriptBasic and DLLC for my Windows development. I don't normally use fixed position placement and use the natural sizing and alignment features IUP offers. I'm posting this example to show that IUP can do direct placement of controls if that is your preference.

(http://files.allbasic.info/ScriptBasic/cboxw.png)


' IupCbox Example - fixed positioning

INCLUDE "iupinc.sb"

img_bits1 = """
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,0,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,0,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,0,2,0,2,0,2,2,0,2,2,2,0,0,0,2,2,2,0,0,2,0,2,2,0,0,0,2,2,2
,2,2,2,0,2,0,0,2,0,0,2,0,2,0,2,2,2,0,2,0,2,2,0,0,2,0,2,2,2,0,2,2
,2,2,2,0,2,0,2,2,0,2,2,0,2,2,2,2,2,0,2,0,2,2,2,0,2,0,2,2,2,0,2,2
,2,2,2,0,2,0,2,2,0,2,2,0,2,2,0,0,0,0,2,0,2,2,2,0,2,0,0,0,0,0,2,2
,2,2,2,0,2,0,2,2,0,2,2,0,2,0,2,2,2,0,2,0,2,2,2,0,2,0,2,2,2,2,2,2
,2,2,2,0,2,0,2,2,0,2,2,0,2,0,2,2,2,0,2,0,2,2,0,0,2,0,2,2,2,0,2,2
,2,2,2,0,2,0,2,2,0,2,2,0,2,2,0,0,0,0,2,2,0,0,2,0,2,2,0,0,0,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,0,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,0,2,2,2,0,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,0,0,0,2,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
"""

img_bits2 = """
2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3
,3,3,3,0,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3
,3,3,3,0,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3
,3,3,3,0,3,0,3,0,3,3,0,3,3,3,1,1,0,3,3,3,0,0,3,0,3,3,0,0,0,3,3,3
,3,3,3,0,3,0,0,3,0,0,3,0,3,0,1,1,3,0,3,0,3,3,0,0,3,0,3,3,3,0,3,3
,3,3,3,0,3,0,3,3,0,3,3,0,3,3,1,1,3,0,3,0,3,3,3,0,3,0,3,3,3,0,3,3
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,3,3,3,0,3,0,3,3,0,3,3,0,3,0,1,1,3,0,3,0,3,3,0,0,3,0,3,3,3,0,3,3
,3,3,3,0,3,0,3,3,0,3,3,0,3,3,1,1,0,0,3,3,0,0,3,0,3,3,0,0,0,3,3,3
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,0,3,3,3,3,3,3,3,3
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,0,3,3,3,0,3,3,3,3,3,3,3,3
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,0,0,0,3,3,3,3,3,3,3,3,3
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,1,1,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3
,2,2,2,2,2,2,2,3,3,3,3,3,3,3,1,1,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,3,3,3,3,3,3,3,3,1,1,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
"""

FUNCTION create_mat
  mat = dllcall(IupMatrix, "")
  dllcall(IupSetAttribute, mat, "NUMCOL", "1")
  dllcall(IupSetAttribute, mat, "NUMLIN", "3")
  dllcall(IupSetAttribute, mat, "NUMCOL_VISIBLE", "1")
  dllcall(IupSetAttribute, mat, "NUMLIN_VISIBLE", "3")
  dllcall(IupSetAttribute, mat, "EXPAND", "NO")
  dllcall(IupSetAttribute, mat, "SCROLLBAR", "NO")

  dllcall(IupSetAttribute, mat, "0:0", "Inflation")
  dllcall(IupSetAttribute, mat, "1:0", "Medicine ")
  dllcall(IupSetAttribute, mat, "2:0", "Food")
  dllcall(IupSetAttribute, mat, "3:0", "Energy")
  dllcall(IupSetAttribute, mat, "0:1", "January 2000")
  dllcall(IupSetAttribute, mat, "1:1", "5.6")
  dllcall(IupSetAttribute, mat, "2:1", "2.2")
  dllcall(IupSetAttribute, mat, "3:1", "7.2")

  dllcall(IupSetAttribute, mat, "BGCOLOR", "255 255 255")
  dllcall(IupSetAttribute, mat, "BGCOLOR1:0", "255 128 0")
  dllcall(IupSetAttribute, mat, "BGCOLOR2:1", "255 128 0")
  dllcall(IupSetAttribute, mat, "FGCOLOR2:0", "255 0 128")
  dllcall(IupSetAttribute, mat, "FGCOLOR1:1", "255 0 128")

  dllcall(IupSetAttribute, mat, "CX", "600")
  dllcall(IupSetAttribute, mat, "CY", "250")

  create_mat = mat

END FUNCTION

FUNCTION createtree
  tree = dllcall(IupTree)
  dllcall(IupSetAttributes, tree, "FONT=COURIER_NORMAL_10, " & _
                         "NAME=Figures, " & _
                         "ADDBRANCH=3D, " & _
                         "ADDBRANCH=2D, " & _
                         "ADDLEAF1=trapeze, " & _
                         "ADDBRANCH1=parallelogram, " & _
                         "ADDLEAF2=diamond, " & _
                         "ADDLEAF2=square, " & _
                         "ADDBRANCH4=triangle, " & _
                         "ADDLEAF5=scalenus, " & _
                         "ADDLEAF5=isosceles, " & _
                         "ADDLEAF5=equilateral, " & _
                         "RASTERSIZE=180x180, " & _
                         "VALUE=6, " & _
                         "CTRL=ON, " & _
                         "SHIFT=ON, " & _
                         "CX=600, " & _
                         "CY=10, " & _
                         "ADDEXPANDED=NO")
  createtree = tree
END FUNCTION

SUB func_1
  img_1 = dllcall(IupImage, 32, 32, SB_CreateImg(img_bits1))
  dllcall(IupSetHandle, "img1", img_1)
  dllcall(IupSetAttribute, img_1, "0", "0 0 0")
  dllcall(IupSetAttribute, img_1, "1", "BGCOLOR")
  dllcall(IupSetAttribute, img_1, "2", "255 0 0")

  img_2 = dllcall(IupImage, 32, 32, SB_CreateImg(img_bits2))
  dllcall(IupSetHandle, "img2", img_2)
  dllcall(IupSetAttribute, img_2, "0", "0 0 0")
  dllcall(IupSetAttribute, img_2, "1", "0 255 0")
  dllcall(IupSetAttribute, img_2, "2", "BGCOLOR")
  dllcall(IupSetAttribute, img_2, "3", "255 0 0")

  _frm_1 = dllcall(IupFrame, _
    dllcall(IupVbox, _
      dllcall(IupSetAttributes, dllcall(IupButton, "Button Text", ""), "CINDEX=1"), _
      dllcall(IupSetAttributes, dllcall(IupButton, "", ""), "IMAGE=img1,CINDEX=2"), _
      dllcall(IupSetAttributes, dllcall(IupButton, "", ""), "IMAGE=img1,IMPRESS=img2,CINDEX=3"),0))
  dllcall(IupSetAttribute, _frm_1, "TITLE", "IupButton")
  dllcall(IupSetAttribute, _frm_1, "CX", "10")
  dllcall(IupSetAttribute, _frm_1, "CY", "180")

  _frm_2 = dllcall(IupFrame, _
    dllcall(IupVbox, _
      dllcall(IupSetAttributes, dllcall(IupLabel, "Label Text"), "CINDEX=1"), _
      dllcall(IupSetAttributes, dllcall(IupLabel, ""), "SEPARATOR=HORIZONTAL,CINDEX=2"), _
      dllcall(IupSetAttributes, dllcall(IupLabel, ""), "IMAGE=img1,CINDEX=3"), 0))
  dllcall(IupSetAttribute, _frm_2, "TITLE", "IupLabel")
  dllcall(IupSetAttribute, _frm_2, "CX", "200")
  dllcall(IupSetAttribute, _frm_2, "CY", "250")

  _frm_3 = dllcall(IupFrame, _
    dllcall(IupVbox, _
      dllcall(IupSetAttributes, dllcall(IupToggle, "Toggle Text", ""), "VALUE=ON,CINDEX=1"), _
      dllcall(IupSetAttributes, dllcall(IupToggle, "", ""), "IMAGE=img1,IMPRESS=img2,CINDEX=2"), _
      dllcall(IupSetAttributes, dllcall(IupFrame, dllcall(IupRadio, dllcall(IupVbox, _
        dllcall(IupSetAttributes, dllcall(IupToggle, "Toggle Text", ""), "CINDEX=3"), _
        dllcall(IupSetAttributes, dllcall(IupToggle, "Toggle Text", ""), "CINDEX=4"), 0))), "TITLE=IupRadio"), 0))
  dllcall(IupSetAttribute, _frm_3, "TITLE", "IupToggle")
  dllcall(IupSetAttribute, _frm_3, "CX", "400")
  dllcall(IupSetAttribute, _frm_3, "CY", "250")

  _text_1 = dllcall(IupText, "")
  dllcall(IupSetAttribute, _text_1, "VALUE", "IupText Text")
  dllcall(IupSetAttribute, _text_1, "SIZE", "80x")
  dllcall(IupSetAttribute, _text_1, "CINDEX", "1")
  dllcall(IupSetAttribute, _text_1, "CX", "10")
  dllcall(IupSetAttribute, _text_1, "CY", "100")

  _ml_1 = dllcall(IupMultiLine, "")
  dllcall(IupSetAttribute, _ml_1, "VALUE", "IupMultiline Text\nSecond Line\nThird Line")
  dllcall(IupSetAttribute, _ml_1, "SIZE", "80x60")
  dllcall(IupSetAttribute, _ml_1, "CINDEX", "1")
  dllcall(IupSetAttribute, _ml_1, "CX", "200")
  dllcall(IupSetAttribute, _ml_1, "CY", "100")

  _list_1 = dllcall(IupList, "")
  dllcall(IupSetAttribute, _list_1, "VALUE", "1")
  dllcall(IupSetAttribute, _list_1, "1", "Item 1 Text")
  dllcall(IupSetAttribute, _list_1, "2", "Item 2 Text")
  dllcall(IupSetAttribute, _list_1, "3", "Item 3 Text")
  dllcall(IupSetAttribute, _list_1, "CINDEX", "1")
  dllcall(IupSetAttribute, _list_1, "CX", "10")
  dllcall(IupSetAttribute, _list_1, "CY", "10")

  _list_2 = dllcall(IupList, "")
  dllcall(IupSetAttribute, _list_2, "DROPDOWN", "YES")
  dllcall(IupSetAttribute, _list_2, "VALUE", "2")
  dllcall(IupSetAttribute, _list_2, "1", "Item 1 Text")
  dllcall(IupSetAttribute, _list_2, "2", "Item 2 Text")
  dllcall(IupSetAttribute, _list_2, "3", "Item 3 Text")
  dllcall(IupSetAttribute, _list_2, "CINDEX", "2")
  dllcall(IupSetAttribute, _list_2, "CX", "200")
  dllcall(IupSetAttribute, _list_2, "CY", "10")

  _list_3 = dllcall(IupList, "")
  dllcall(IupSetAttribute, _list_3, "EDITBOX", "YES")
  dllcall(IupSetAttribute, _list_3, "VALUE", "3")
  dllcall(IupSetAttribute, _list_3, "1", "Item 1 Text")
  dllcall(IupSetAttribute, _list_3, "2", "Item 2 Text")
  dllcall(IupSetAttribute, _list_3, "3", "Item 3 Text")
  dllcall(IupSetAttribute, _list_3, "CINDEX", "3")
  dllcall(IupSetAttribute, _list_3, "CX", "400")
  dllcall(IupSetAttribute, _list_3, "CY", "10")

  _cnv_1 = dllcall(IupCanvas, "")
  dllcall(IupSetAttribute, _cnv_1, "RASTERSIZE", "100x100")
  dllcall(IupSetAttribute, _cnv_1, "POSX", "0")
  dllcall(IupSetAttribute, _cnv_1, "POSY", "0")
  dllcall(IupSetAttribute, _cnv_1, "BGCOLOR", "128 255 0")
  dllcall(IupSetAttribute, _cnv_1, "CX", "400")
  dllcall(IupSetAttribute, _cnv_1, "CY", "150")

  _ctrl_1 = dllcall(IupVal, "")
  dllcall(IupSetAttribute, _ctrl_1, "CX", "600")
  dllcall(IupSetAttribute, _ctrl_1, "CY", "200")

  _cbox = dllcall(IupCbox, _
                  _text_1, _
                    _ml_1, _
                  _list_1, _
                  _list_2, _
                  _list_3, _
                   _cnv_1, _
                  _ctrl_1, _
             createtree(), _
             create_mat(), _
                   _frm_1, _
                   _frm_2, _
                   _frm_3, _
                        0)
  dllcall(IupSetAttribute, _cbox, "SIZE", "480x200")

  hbox = dllcall(IupSetAttributes, dllcall(IupHbox, _cbox, 0), "MARGIN=10x10")

  dlg = dllcall(IupDialog, hbox)
  dllcall(IupSetHandle, "dlg", dlg)
  dllcall(IupSetAttribute, dlg, "TITLE", "Cbox Test")
END SUB


FUNCTION main(pProg)
  dllcall(IupOpen, 0, 0)
  dllcall(IupControlsOpen)
  func_1()
  dllcall(IupShowXY, dllcall(IupGetHandle, "dlg"), IUP_CENTER, IUP_CENTER)
  dllcall(IupMainLoop)
  dllcall(IupClose)
  main = TRUE
END FUNCTION


ScriptBasic and IUP under Ubuntu 64 bit.

(http://files.allbasic.info/ScriptBasic/cbox_u64.png)
Title: Re: The compiler advantage
Post by: John Spikowski on August 23, 2013, 09:47:37 AM
QuoteDOSBox is the only thing I miss on my Kindle Fire.

Are you saying Kindle won't allow off market apps or the Kindle doesn't have what it takes to run DOSBox?


@Brice - Since we are both known for our negative karma on this forum, lets solve this with the buddy system. I will keep your karma at zero and you do the same for me. If we get lucky José will disable the karma feature and members will actually have to post their opinions or gripes rather than the simple click of the (stone throwing) smite button.
Title: Re: The compiler advantage
Post by: Brice Manuel on August 23, 2013, 10:31:35 AM
Quote from: John Spikowski on August 23, 2013, 09:47:37 AM
Are you saying Kindle won't allow off market apps or the Kindle doesn't have what it takes to run DOSBox?

There is a way to side load apps without jail breaking it, but it does not always work.  I bought a Fire because I love Amazon and I have bought many apps and games for the Kindle Fire, and I trust Amazon with credit card info.  I could never go straight android as I will NOT order any apps via Google's service as I could never trust them with my credit card info.  Unfortunately, some things like emulators for old systems and such that I would like to purchase, are only available for purchase via Google's service and they can't be installed on a Fire without jail breaking it.  There is not a SD slot though, so you are fairly limited with space as I have a first generation Fire.


Quote from: John Spikowski on August 23, 2013, 09:47:37 AM@Brice - Since we are both known for our negative karma on this forum, lets solve this with the buddy system. I will keep your karma at zero and you do the same for me. If we get lucky José will disable the karma feature and members will actually have to post their opinions or gripes rather than the simple click of the (stone throwing) smite button.

The irony is leaving negative karma for somebody, is in itself an act of bad karma.  Unlike most forums where the people leaving the karma are identified in your profile, here they are allowed to hide their identity and be cowardly.  The idea of a karma system on any forum is laughable as it speaks to the frailty of the human ego where people perceive somebody having thoughts they do not agree with as something that should be punished.  Thought crimes are very Orwellian and speak to the wider social issues this world is facing.
Title: Re: The compiler advantage
Post by: Patrice Terrier on August 23, 2013, 02:54:16 PM
What made this forum a valuable place, was the quality of the contributions posted here.

I don't see any useful contributions in this thread for those that are accustomed to the usual José Roca's forum topics.

I never considered free exotics as a viable alternative to the professionnal tools i am using.
I like to have full control on my code and i avoid like the plague extra level of encapsulations. There is only one exception to my moto: WinDev, because it is a tool of exception to build quickly modern looking applications, using hundreds of windows.

...
Title: Re: The compiler advantage
Post by: Brice Manuel on August 23, 2013, 03:31:18 PM
Quote from: Patrice Terrier on August 23, 2013, 02:54:16 PM
I don't see any useful contributions in this thread for those that are accustomed to the usual José Roca's forum topics.

Your posts would be a perfect example as they are often promoting WinDev or C++.  Luckily this is the General Discussion category, so it it is not limited to contributions.

Technically, there is no place to make contributions here, as the forums for contributions are labeled for Jose, Patrice, Fred, Theo, Charles.  Unless you are one of those people, there is not a specific place for somebody to make a code contribution, tutorials, etc.  There is only a place for third-party add-ons, nothing else.  People might contribute if there was a way, and a place, for them to actually contribute.
Title: Re: The compiler advantage
Post by: Chris Holbrook on August 23, 2013, 03:33:38 PM
Quote from: Brice Manuel on August 23, 2013, 10:31:35 AMThe irony is leaving negative karma for somebody, is in itself an act of bad karma.
Agreed. You can make a better case for +ve, for example, to indicate approval when to post a message would add nothing more.
Title: Contributions
Post by: Patrice Terrier on August 23, 2013, 04:14:57 PM
Brice

You can create a new thread named "Contributions" inside "General Discussion", this is the way i started, before José gave me the status of moderator, and allowed me to create my own section.

By the way, i think the number of people reading a specific thread is also a good indicator of popularity, but you can never know if it is an indicator of good or bad karma until you read it yourself ;)

...
Title: Re: The compiler advantage
Post by: John Spikowski on August 23, 2013, 08:45:05 PM
QuoteI don't see any useful contributions in this thread for those that are accustomed to the usual José Roca's forum topics.

Define useful contributions. That's like saying I'm having a bad day and walk away. I think this thread has been very enlightening.


  • José has come out and declared his position with COM/PB and his disappointment in the PB community not taking advantage of the tools he and Bob spent years creating.
  • My stroll down Android alley and what can be done off main street.
  • There is life beyond PowerBASIC.
  • Everyone needs someone to blame.
  • Realizing that people buy/use a BASIC language because they don't want to learn Java or C. Trying to turn PB (QB on steroids) in to a PB.net framework done right is a dream that should have become a reality more than 10 years ago.
  • I like hearing about the real life adventures of the guys I've known (via forums) for years and the stuff they do outside the PB realm.
QuoteMicrosoft CEO Steve Ballmer has announced his intentions to step down.

Best news I have heard coming out of the M$ camp in years.
Title: Re: The compiler advantage
Post by: Patrice Terrier on August 23, 2013, 09:34:36 PM
John

May be i was in a bad day, in my good days i did applaud you several times, and i smite you once.

The funny thing is, that most of those smiting are also those who never post contributions.

It would be nice, if instead of karma, we could use something similar to the code project, where people have to explain why they post a low or high rating for a contribution, that would be more fair for sure, but the current karma is the way it works on most forum.

My definition of a useful contribution, is something more like those found on the Code Project.

...

Title: Re: The compiler advantage
Post by: John Spikowski on August 23, 2013, 09:42:00 PM
Patrice,

I agree that Code Projects is a great site and well managed. Each topic is a project and it would be senseless to pollute the subject matter with anything other than related content.  José has opened his forum to a wide verity of topics with the intent of being a valuable resource to compliment his include files.

I also agree we shouldn't turn this forum into a social network and respect José's intent.

John
Title: Re: The compiler advantage
Post by: Theo Gottwald on August 24, 2013, 04:43:18 PM
Its like this. "How you shout out - thats how it comes back to you".


We have soon elections in germany, and many friends tell me that if they post things critical about Mrs. Angela Merkel or her CDU Party on the "CDU Forums" or on her Facebook site, that its alltogether deleted.
Even in the forums of the bigger medie, newspapers cirtical voices are ging to be removed.

Reading some posts from John there is often bad speach on PB and people get the impression that he does not like PB possibly because of private reasons that are not our bussiness.
So think a moment. If you go to Party A Forum and say that you do not like Party A, you will be kicked.
I don't know what John will do if he get people into the Scriptbasic Forum who will constantly post about the shortcomings and bad sides of Scriptbasic. Will he provide them with lots of good karma?
If i would post here the mails from people who asked me remove "John", others would say "never post private mails".
And in this case i will not do it. But Jose is my withness he got these mails also.
They exist and thats why i ask people from time to time to read their "contributions" two times before promoting that they do not like PB and at the same time tell that they can not offer PB code because they do not know about PB.

Title: Re: The compiler advantage
Post by: John Spikowski on August 24, 2013, 07:45:21 PM
I already know I wouldn't be a good politician. I don't waste my time thinking I'm going to make everyone happy with everything I do and say. I don't have to worry about covering up lies and don't wear knee pads as my standard attire. If you don't like what I have to say, move on, I won't chase you.


Title: Re: The compiler advantage
Post by: Chris Holbrook on August 24, 2013, 09:37:33 PM
Funny how discussions get more interesting as they approach the outer limits of the host forum.

My suggestion for a long life. Noodles. And, "respect your hosts, read their mission statement".



Title: Re: The compiler advantage
Post by: John Spikowski on August 25, 2013, 09:17:16 PM
I have fallen into the trap of folks seeing ScriptBasic as a console mode interpreter rather than an embeddable scripting API. (author's intent) I created a BaCon (BASIC to C translator) example showing some of the basic API interface calls to ScriptBasic from a host language. This could just as easily have been done in PowerBASIC as I have demonstrated in a previous post.

sbembed.bac

' BaCon embedding ScriptBasic example

PRAGMA OPTIONS -I/home/jrs/sb/source
PRAGMA LDFLAGS scriba pthread
PRAGMA INCLUDE scriba.h getopt.h

PROTO scriba_destroy scriba_DestroySbArgs

DECLARE pProgram TYPE pSbProgram
DECLARE ReturnData TYPE SbData
DECLARE ArgData TYPE pSbData
DECLARE bob TYPE pSbData

' Create ScriptBasic object and load script
pProgram = scriba_new(malloc, free)
ok = scriba_LoadConfiguration(pProgram, "/home/jrs/sb/sb22/bin/basic.conf")
ok = scriba_SetFileName(pProgram, "sbembed.sb")
ok = scriba_LoadSourceProgram(pProgram)
ok = scriba_Run(pProgram,"")

' Call SUB pass no arguments
t_sub_1 = scriba_LookupFunctionByName(pProgram, "main::t_sub_1")
ok = scriba_Call(pProgram, t_sub_1)
PRINT

' Retrieve SB global variable
vsn = scriba_LookupVariableByName(pProgram, "main::bob")
ok = scriba_GetVariable(pProgram, vsn, &bob)
PRINT "bob var type: ", bob[0].type
PRINT "bob var size: ", bob[0].size
PRINT "bob var value: ", bob[0].v.l
PRINT

' Call SUB pass SB global as an argument
t_sub_2 = scriba_LookupFunctionByName(pProgram, "main::t_sub_2")
ok = scriba_CallArg(pProgram, t_sub_2, "i", bob[0].v.l)
PRINT

' Call script FUNCTION passing arguments and returning a result
sb_long = 123
sb_real = .321
sb_str$ = "ScriptBasic"
t_func_3 = scriba_LookupFunctionByName(pProgram, "main::t_func_3")
ArgData = scriba_NewSbArgs(pProgram, "i r s", sb_long, sb_real, sb_str$)
ok = scriba_CallArgEx(pProgram, t_func_3, &ReturnData, 3, ArgData)
scriba_DestroySbArgs(pProgram, ArgData, 3)
PRINT "Arguments Passed: ", ReturnData.v.l

scriba_destroy(pProgram)


sbembed.sb

' Embed test script

bob = 99

SUB t_sub_1
  PRINT "SUB with no arguments passed.\n"
END SUB

SUB t_sub_2(this_bob)
  PRINT this_bob," bottles of beer on the wall.\n"
  this_bob -= 1
  PRINT "Take one down, pass it around, ",this_bob," bottles of beer on the wall.\n"
END SUB

FUNCTION t_func_3(longarg, realarg, strarg)
  PRINT longarg,"\n"
  PRINT FORMAT("%g",realarg),"\n"
  PRINT strarg,"\n"
  t_func_3 = 3
END FUNCTION


Results

jrs@laptop:~/BaCon/2302$ ./sbembed
SUB with no arguments passed.

bob var type: 2
bob var size: 0
bob var value: 99

99 bottles of beer on the wall.
Take one down, pass it around, 98 bottles of beer on the wall.

123
0.321
ScriptBasic
Arguments Passed: 3
jrs@laptop:~/BaCon/2302$

Charles mentioned in this thread about scripting languages needing a variant type variable storage system. I think ScriptBasic's SbData structure emulates that well. (memory manager was designed to be thread safe)


typedef struct _SbData {
  unsigned char type;
  unsigned long size;
  union {
    double d;
    long   l;
    unsigned char *s;
    } v;
  } SbData, *pSbData;

// ScriptBasic data TYPE

#define SBT_UNDEF  0
#define SBT_DOUBLE 1
#define SBT_LONG   2
#define SBT_STRING 3
#define SBT_ZCHAR  4
Title: Re: The compiler advantage
Post by: John Spikowski on August 28, 2013, 05:38:21 AM
I'm trying to convert the example above to PBCC 5 and having a problem getting by this function. (missing argument) The function allows a variable number of arguments after the argument definition string. How do I declare this in PB?


ArgData = scriba_NewSbArgs(pProgram, "i r s", sb_long, sb_real, sb_str$)


Title: Re: The compiler advantage
Post by: John Spikowski on August 28, 2013, 05:56:25 PM
Should I assume that the reason for a no response to this issue is PowerBASIC is unable to handle functions with a variable number of arguments? This ability is also required if PowerBASIC is to interface with IUP.

I hope that the reason no one replied is due to my karma rating and I'm not worth a response rather than a fatal flaw with PB.


Title: Re: The compiler advantage
Post by: José Roca on August 28, 2013, 06:23:54 PM
You haven't said how many parameters do you need. If limited, add as many OPTIONAL BYREF AS ANY as you need, up to a maximum of 32 total parameters; if unlimited, it can't be done.

BTW I don't see any need to interface PB with IUP.
Title: Re: The compiler advantage
Post by: James C. Fuller on August 28, 2013, 06:52:33 PM
Quote from: José Roca on August 28, 2013, 06:23:54 PM
BTW I don't see any need to interface PB with IUP.

Me either.
Been there done that just on a whim.

James
Title: Re: The compiler advantage
Post by: John Spikowski on August 28, 2013, 06:54:36 PM
scriba_NewSbArgs is how SB sets up its embedded arguments to call a script function. I need to declare it once and be able to pass a variable number of various type arguments depending on what the requirements of the script function. These aren't optional arguments they are based on the function argument definition string. This isn't uncommon and used in many C libraries. (Variadic Function (http://en.wikipedia.org/wiki/Variadic_function))

QuoteBTW I don't see any need to interface PB with IUP.

What cross platform GUI tool kit do you recommend?  You would have to be a fool to develop any new GUI apps that uses a proprietary single platform solution. (like DDT) It's a new day and people aren't blindly trusting companies that think they own the market and set the standards.
Title: Re: The compiler advantage
Post by: José Roca on August 28, 2013, 07:21:10 PM
Quote
scriba_NewSbArgs is how SB sets up its embedded arguments to call a script function. I need to declare it once and be able to pass a variable number of various type arguments depending on what the requirements of the script function. These aren't optional arguments they are based on the function argument definition string. This isn't uncommon and used in many C libraries. (Variadic Function)

And a source of endless security holes. M$ no longer uses it, now that it is concerned about security.

Quote
What cross platform GUI tool kit do you recommend?  You would have to be a fool to develop any new GUI apps that uses a proprietary single platform solution. (like DDT) It's a new day and people aren't blindly trusting companies that think they own the market and set the standards.

None. Since PB only works with Windows, use the Windows SDK. If you want cross platform, use something else.

But you already know that, so why don't you stop posting malicious questions? I'm getting tired or your behavior.


Title: Re: The compiler advantage
Post by: John Spikowski on August 28, 2013, 07:49:52 PM
QuoteAnd a source of endless security holes. M$ no longer uses it, now that it is concerned about security.

Thanks! I'll e-mail the author of IUP and tell him that his IUP 3.8 release is flawed and using variable number of argument functions doesn't work in Windows and therefore all the Windows libraries that seem to compile successfully won't work. (even though I haven't notice this with my use of the IUP libraries in SB)

How would adding arguments to a function call that the function ignores be a security risk? I would think it would be easier to find a DIM directive in PB and change it to a REDIM and use the extra buffers space to inject my code and GOTO (jump) to it.

If this forum is based on solutions that don't work with the tools I use, I'm wasting my time here.

Thanks for the reply and I'll take PowerBASIC off the compatibility list of ANSI C supported high level languages.

My take from your comment is if you use anything other than Windows and PB, you are running software with by design security holes.

I hear there is an opening as the leader of Zale's Zombies and you have been selected to be one of the final candidates.

Feel free to remove my account.

Title: Re: The compiler advantage
Post by: José Roca on August 28, 2013, 09:06:18 PM
You don't even read the links you post, do you?

Quote
Variadic functions can expose type-safety problems in some languages. For instance, C's printf, if used incautiously, can give rise to a class of security holes known as format string attacks. The attack is possible because the language support for variadic functions is not type-safe; it permits the function to attempt to pop more arguments off the stack than were placed there—corrupting the stack and leading to unexpected behavior.

> If this forum is based on solutions that don't work with the tools I use, I'm wasting my time here.

And ours too.

> My take from your comment is if you use anything other than Windows and PB, you are running software with by design security holes.

No, if you use safe code, but Variadic functions are unsafe.

> Feel free to remove my account.

Bye.
Title: Re: The compiler advantage
Post by: Charles Pegge on August 28, 2013, 10:30:13 PM
All things are possible with a little assembly code hacking.

What you need to do is declare scribaNewSbArgs as a function without arguments.

To make the call:

First record the stack pointer value.

Push the args onto the stack in reverse order.

Call the function

Store the returned value

Restore the prior stack pointer value.


You will also need to build some logic around this to interpret the string for formatting args (long, double, string or charbyte). So it is quite a lot of baggage if you require a generic system for handling this type of call. Using variants with a wrapper function is a possibility.

With Assembler, nothing is type-safe :)
Title: Re: The compiler advantage
Post by: José Roca on August 28, 2013, 11:02:27 PM
Many C programmers use variadic functions just because that language allows to do it, but it is no the best way. With languages like PB, it is much easier (and safe) to use an array of variants.

The lack of safety of variadic functions is not something that I believe, but a fact:

Quote
A variable argument function (variadic function) is a function that can accept an undefined number of arguments. In many programming languages, formatted output functions are defined as variadic functions.

In C++, variable argument functions are declared with the ellipsis (...) in the argument list field. The compiler checks types only for explicitly defined arguments. To get access to the variable argument list macros va_arg, va_end and va_start from the STDARG.H header file are used. The printf function family is one of the well-known examples of variable argument functions.

In some languages using variable argument functions might cause type safety troubles. For example, C/C++ functions of the printf family may create uncontrolled string format vulnerabilities when used carelessly. Mismatch of the format string and passed arguments may cause unpredictable behavior, buffer overflows, stack smashing and execution of unsafe code and lead to destruction of dynamic memory areas.

Although these troubles related to the use of variadic functions are known for a long time, they were identified as serious security vulnerabilities only in 1999. Considering that such vulnerabilities were thought to be rather harmless for many years, this is one of the most widespread classes of errors today.
Title: Re: The compiler advantage
Post by: Charles Pegge on August 29, 2013, 11:47:21 AM

There are quite a few unsafe constructs in PB, which prove to be very useful, especially for low-level coding, so I think ellipsis is a useful construct to have in the toolbox, if only to access libraries which deploy variadic functions.
Title: Re: The compiler advantage
Post by: Patrice Terrier on August 29, 2013, 12:01:35 PM
What about using a pointer to a structure, only one 32/64-bit LONG_PTR parameter, but plainty of options to customize it the way you want :)
Title: Re: The compiler advantage
Post by: Charles Pegge on August 29, 2013, 04:06:23 PM
This is the obvious alternative, using some form of variant structure. In fact ScriptBasic has such a function called scriba_SbCallArgEx which takes arguments byref as an array of sbData, which contains type, length and value. This takes more coding to setup a call  but is slightly more efficient than interpreting a format-string, and an indeterminate bunch of args.