Using SQLite LIB on all platforms

Discussions related to database technologies, file handling, directories and storage
headcrash
Posts: 1
Joined: Sat 30 Oct 2021, 16:40

Using SQLite LIB on all platforms

Post by headcrash »

Hi,
after searching the forum and the wiki, I give up and ask for your help:
In "BBC BASIC for Windows" using the SQLite library works out of the box - downloading SQLite.bbc, dll and def -files, copying in the @LIB$-folder and go.
Using SDL-Version on Windows did not work. And I suppose that Linux is an other story .

So please can someone tell me, how to adapt the original library, so that sqlite works with the SDL-Version for Windows too ?

Here the code of the Library:

Code: Select all

      REM SQLite3 Library for BB4W by Jon Ripley
      REM Release 1 03/09/2009
      ;
      REM Load the SQLite DLL and set up functions and constants
      DEF PROCsqlite_initialise
      PRIVATE ps{}
      PROCsqlite_private(ps{})
      LOCAL _%,_hdll%
      SYS "GetModuleHandle", "kernel32.dll" TO _hdll%
      SYS "GetProcAddress", _hdll%, "GetProcAddress" TO _%
      SYS "LoadLibrary", @lib$+"sqlite3.dll" TO _hdll%
      IF _hdll%=0 THEN SYS "LoadLibrary", @dir$+"sqlite3.dll" TO _hdll%
      IF _hdll%=0 THEN ERROR 100, "Warning: A required DLL 'sqlite3.dll' could not be found."
      ps.sqlite3%=_hdll%
      SYS _%, _hdll%, "sqlite3_aggregate_context" TO sqlite3_aggregate_context%
The first error is thrown in the "SYS "GetModuleHandle", "kernel32.dll" TO _hdll%" - Call
How can I call this Windows-API in SDL ?

The second error takes place when the dll should be loaded with "LoadLibrary".
I learned, that in SDL there ist the "SDL_LoadObject" - function - but that did not work either.

So please, how can I adapt the two function-calls, so that the sqlite3.dll would work ?
Thanks a lot!

Greetings,
headcrash
Hated Moron

Re: Using SQLite LIB on all platforms

Post by Hated Moron »

headcrash wrote: Sun 31 Oct 2021, 12:50 The first error is thrown in the "SYS "GetModuleHandle", "kernel32.dll" TO _hdll%" - Call
How can I call this Windows-API in SDL ?

The second error takes place when the dll should be loaded with "LoadLibrary".
I learned, that in SDL there ist the "SDL_LoadObject" - function - but that did not work either.
Assuming you only need your program to work in Windows (not the other platforms supported by BBC BASIC for SDL 2.0) the answer to your question is trivial - you simply need to change "GetModuleHandle" to "GetModuleHandleA" and "LoadLibrary" to "LoadLibraryA".

The addition of the 'A' to the function names is to tell Windows that the string(s) passed as parameters are ANSI strings, not Unicode (UTF-16) strings (in the latter case you would change the A to W).

Sorry it has taken so long to receive this reply, I'm disappointed that nobody else responded earlier. I would have expected that the significance of the A suffix in Windows API function names was common knowledge.
User avatar
hellomike
Posts: 192
Joined: Sat 09 Jun 2018, 09:47
Location: Amsterdam

Re: Using SQLite LIB on all platforms

Post by hellomike »

The reason that the significance of the A suffix in Windows API function names isn't common knowledge is because BB4W happily works the same with or without using the suffix in both API's.

I.e., in BB4W (6.15a):

Code: Select all

      PRINT SYS("GetModuleHandle") - SYS("GetModuleHandleA")
prints 0.
Hated Moron

Re: Using SQLite LIB on all platforms

Post by Hated Moron »

hellomike wrote: Tue 14 Jun 2022, 16:06 The reason that the significance of the A suffix in Windows API function names isn't common knowledge is because BB4W happily works the same with or without using the suffix in both API's.
Perhaps it would have been better to include the A suffix explicitly whenever Windows API functions are referenced in the BB4W documentation, such as the 'Accessing the Windows API' section of the Help manual. Doing that would also speed the SYS calls up, slightly, because I think the 'non-A' version is tried before the 'A' version, so it would avoid that necessity.

Still, with BB4W being more than 20 years old and the total number of users having fallen to single figures, it's hardly worth worrying about it now!
User avatar
hellomike
Posts: 192
Joined: Sat 09 Jun 2018, 09:47
Location: Amsterdam

Re: Using SQLite LIB on all platforms

Post by hellomike »

I have far better results coding with BB4W than BBSDL. I'm still proud Richard made my 2048 game part of the BBSDL distribution however, apart from a small Android App, I didn't do much more with BBSDL.
Hated Moron

Re: Using SQLite LIB on all platforms

Post by Hated Moron »

hellomike wrote: Tue 14 Jun 2022, 19:03 I have far better results coding with BB4W than BBSDL. I'm still proud Richard made my 2048 game part of the BBSDL distribution however, apart from a small Android App, I didn't do much more with BBSDL.
As I've said before, BB4W represents the past, BBCSDL represents the future. Although they are both 'maintained', I don't expect there to be any more releases of BB4W, whereas BBCSDL continues to be actively developed with new releases every six weeks or so. I invariably use BBCSDL myself now; the only times I've used BB4W in the recent past have been when a program I'm writing is compatible with, and needs to be tested on, both versions.

The other important factor, which again I've mentioned before, is that because BB4W is Closed Source nobody else will be able to maintain it when I cannot, which realistically is virtually the case already and will only get worse as Cognitive Decline robs me of my memory and faculties. BBCSDL however, being Open Source, has the prospect of being maintained when I no longer can - twelve people have already forked the project.

I've tried very hard to ensure that BBCSDL can do everything that BB4W can, bar a few features that are too tightly tied to the Windows API (so that includes things like Text-To-Speech, COM Automation and access to databases - although I'm working on the latter). A lot of what I do involves graphics, and the speed advantage of BBCSDL (because of the hardware acceleration) can be significant.

So if anybody is reluctant to move to BBCSDL, please let me know why. I would want to emphasise that the User Interface is much more amenable to tweaking and enhancing than BB4W's is, because it's written in BASIC rather than being part of the OS (or coded in C). So if there's any aspect of the IDE that you don't like, or some GUI feature that's missing, you can probably very easily implement it yourself!
User avatar
hellomike
Posts: 192
Joined: Sat 09 Jun 2018, 09:47
Location: Amsterdam

Re: Using SQLite LIB on all platforms

Post by hellomike »

Well.... the plain simple answer is, you made the BB4W product too good! Because it is so stable, bug-free and accessible, i have no fear whatsoever that there is anything I need in the future that I can't do using BB4W.

It would take a considerable effort to migrate and thoroughly test, all code that I access regularly (about 1MB of source lines) to BBCSDL. Many of the programs have Windows UI programming. For example, one source has these Windows Constants:

Code: Select all

      REM!WC
      CB_ADDSTRING = 323
      CB_GETCURSEL = 327
      CB_SETCURSEL = 334
      CBN_SELCHANGE = 1
      CBS_DROPDOWNLIST = 3
      _COLORONCOLOR = 3
      CW_USEDEFAULT = &80000000
      DS_CENTER = &800
      EM_SETBKGNDCOLOR = &443
      EM_SETEVENTMASK = &445
      EN_CHANGE = 768
      EN_MSGFILTER = &700
      ENM_MOUSEEVENTS = &20000
      ES_AUTOHSCROLL = &80
      ES_AUTOVSCROLL = 64
      ES_MULTILINE = 4
      ES_NUMBER = 8192
      ES_READONLY = &800
      ES_SUNKEN = &4000
      GWL_STYLE = -16
      IDCANCEL = 2
      IMAGE_BITMAP = 0
      LB_ADDSTRING = 384
      LB_DELETESTRING = 386
      LB_FINDSTRING = 399
      LB_GETCURSEL = 392
      LB_GETTEXT = 393
      LB_RESETCONTENT = 388
      LB_SELECTSTRING = 396
      LB_SETCURSEL = 390
      LBN_SELCHANGE = 1
      LBS_SORT = 2
      LBS_USETABSTOPS = &80
      LR_LOADFROMFILE = 16
      LVCF_FMT = 1
      LVCF_SUBITEM = 8
      LVCF_TEXT = 4
      LVCF_WIDTH = 2
      LVCFMT_CENTER = 2
      LVCFMT_FIXED_WIDTH = 256
      LVIF_STATE = 8
      LVIF_TEXT = 1
      LVIS_SELECTED = 2
      LVM_ENSUREVISIBLE = 4115
      LVM_GETNEXTITEM = 4108
      LVM_INSERTCOLUMN = 4123
      LVM_INSERTITEM = 4103
      LVM_SETCOLUMN = 4122
      LVM_SETEXTENDEDLISTVIEWSTYLE = 4150
      LVM_SETITEMSTATE = 4139
      LVM_SETITEMTEXT = 4142
      LVM_SETTEXTCOLOR = 4132
      LVN_ITEMCHANGED = -101
      LVNI_SELECTED = 2
      LVS_EX_FULLROWSELECT = 32
      LVS_EX_GRIDLINES = 1
      LVS_NOSORTHEADER = &8000
      LVS_REPORT = 1
      LVS_SHOWSELALWAYS = 8
      LVS_SINGLESEL = 4
      MF_CHECKED = 8
      SS_BITMAP = &E
      SS_CENTER = 1
      SS_NOPREFIX = &80
      SS_NOTIFY = 256
      SS_SUNKEN = 4096
      STM_SETIMAGE = 370
      SWP_NOACTIVATE = 16
      SWP_NOSIZE = 1
      SWP_NOZORDER = 4
      SWP_SHOWWINDOW = 64
      TA_BOTTOM = 8
      TTM_ADDTOOL = &404
      TTM_TRACKACTIVATE = &411
      TTM_UPDATETIPTEXT = &40C
      TTS_NOPREFIX = 2
      UDM_SETRANGE = &465
      VERTRES = &A
      VERTSIZE = 6
      WM_COMMAND = 273
      WM_LBUTTONDOWN = 513
      WM_NOTIFY = 78
      WS_BORDER = &800000
      WS_CAPTION = &C00000
      WS_GROUP = &20000
      WS_MAXIMIZEBOX = 65536
      WS_POPUP = &80000000
      WS_SYSMENU = &80000
      WS_THICKFRAME = &40000
      WS_VISIBLE = &10000000
      WS_VSCROLL = &200000
If I would manage after many many hours to make the BBCSDL equivalent, I would end up with a program that I'm not comfortable with (i.e. "did I test enough?") compared to a program that I'm very comfortable with currently in BB4W.
Hated Moron

Re: Using SQLite LIB on all platforms

Post by Hated Moron »

hellomike wrote: Wed 15 Jun 2022, 07:51 i have no fear whatsoever that there is anything I need in the future that I can't do using BB4W.
Here are some reasons why it is probable that you will not be able to do "anything you need" in the future using BB4W:
  • Windows may not remain the dominant desktop OS it has been for the last few decades.
  • Windows may cease to be compatible with 32-bit apps. Most other Operating Systems have already dropped such support (e.g. MacOS).
  • Windows may move away from x86-compatible CPUs and switch to a different architecture, as MacOS has with the M1 CPU.
  • Windows may tighten up on adherence to API standards, breaking programs like BB4W that do not fully comply (this has already happened with the SetWindowLong issue).
  • The BB4W executable may stop running if its Code Signing Certificate is no longer considered secure, which will happen when Quantum Computers are large enough, if not sooner.
  • The BB4W Certificate could be revoked if it was compromised, and I was no longer around to resolve the situation.
  • BB4W already frequently triggers (false) virus alerts causing it to be quarantined, and this is likely to get worse.
  • Serious bugs may be discovered in BB4W, making it unsafe to use if it can't be fixed (remember that a horrendous memory leak was discovered as recently as last year, and fixed in v6.15a).
It would take a considerable effort to migrate and thoroughly test, all code that I access regularly (about 1MB of source lines) to BBCSDL.
Nobody is suggesting that you port existing, working, programs to BBCSDL if you have no reason to. That would be extremely difficult, and pointless; it wouldn't achieve anything except frustration!

When I say that I don't use BB4W any longer, of course I don't mean that I don't run utilities that were originally written and 'compiled' in BB4W. They are just executables, the language they were originally written in isn't relevant and I will continue to run them for as long as they work.

But I don't write new programs in BB4W, and I don't recommend that anybody else does either.
Many of the programs have Windows UI programming. For example, one source has these Windows Constants:
Again, that's an existing program, so the only reason for attempting to port it to BBCSDL would be if you wanted it to run on a different platform like MacOS, Linux, Android, iOS or in-browser. If you did want to do that you would have to substitute the Windows GUI features it relies on with an equivalent that can work across those platforms.
User avatar
hellomike
Posts: 192
Joined: Sat 09 Jun 2018, 09:47
Location: Amsterdam

Re: Using SQLite LIB on all platforms

Post by hellomike »

Thanks for the advise. Realizing the different potential scenarios will help me better to decide what to use for future development.