Index
> Windows > SQLite - interesting for ASM applications... |
| Author |
|
|
JohnFound 04 Jun 2004, 07:48
I found very interesting SQL database: SQLite - http://www.sqlite.org/
It is very small (well, relatively  ) -approx. 250kbytes.
IMHO, until we make native FASM SQL database, SQLite is good alternative... if someone needs database engine for assembly programs. 
Regards. |
|||
04 Jun 2004, 07:48 |
|
|
f0dder 04 Jun 2004, 15:07
Just compile SQLite to a DLL, linked statically against the MSVC runtimes - tada, no dependency on msvcrt.dll
 |
|||
|
04 Jun 2004, 15:07 |
|
|
JohnFound 04 Jun 2004, 15:44
f0dder wrote: Just compile SQLite to a DLL, linked statically against the MSVC runtimes - tada, no dependency on msvcrt.dll ...and have another extra 300k
But the best is: SQLite site wrote: Sources are in the public domain. Use for any purpose. Regards |
|||
|
04 Jun 2004, 15:44 |
|
|
ronware 04 Jun 2004, 16:31
FWIW, I use SQLite for a project for a non-profit I am a member of; it works great, is fast and the developer fixes problems very quickly. I use the DLL version of it, MSVCRT dependent... and my prog is in C++.
|
|||
|
04 Jun 2004, 16:31 |
|
|
f0dder 04 Jun 2004, 23:01
Quote:
Not really... the base overhead of ms libc is around 28kb or so, and then of course the various library routines needed. Statically linked sqlite.dll is ~264kb, and only imports from kernel32.dll. The footprint of including sqlite statically should be almost the same as the dll footprint. |
|||
|
04 Jun 2004, 23:01 |
|
|
pelaillo 05 Jun 2004, 15:03
But what about the legal aspects concerning a reverse of the MS portion of the code?
I came into the task because my final idea is to have a fasm written standalone sql library to be used in MenuetOS and SolOS. And I have a fasm equivalent (and improved) for near all of the functions imported by SQLite from MSVCRT. The dependency is too marginal to be considered critical. And the second reason is that I want to do it . |
|||
|
05 Jun 2004, 15:03 |
|
|
f0dder 05 Jun 2004, 22:34
Quote:
The only "legal aspects" would be if you used a pirate copy of VC++ to build the DLL... and since vc2003 is now free, well... So, did you improve on the MS libc code, or did you just write assembly equivalents - there's quite a difference |
|||
|
05 Jun 2004, 22:34 |
|
|
pelaillo 06 Jun 2004, 04:20
f0dder wrote: The only "legal aspects" would be if you used a pirate copy of VC++ to build the DLL... and since vc2003 is now free, well... Free, but not open source. You cannot disassemble it even if you are a proud owner. (Sorry, there is no such a possibility, you cannot own MS software) Quote: So, did you improve on the MS libc code, or did you just write assembly equivalents - there's quite a difference You will be able to judge by yourself. I do like really the open source so if it is not the case, you could contribute to improve it. |
|||
|
06 Jun 2004, 04:20 |
|
|
f0dder 06 Jun 2004, 14:25
Quote:
And does that really matter? If you legally own [a license for] VC, you have the runtime library source. Besides, for something like sqlite.dll, the runtime library source wouldn't be very interesting, if you're going to change anything it would be the sqlite source... not that many people around here would have any interest in modifying those sources. So I still don't really see the issue |
|||
|
06 Jun 2004, 14:25 |
|
|
JohnFound 06 Jun 2004, 15:09
f0dder wrote: So I still don't really see the issue Well, IMHO, using SQLite for assembly programming can be only temporary solution. The final goal is to have portable SQL database written fully in FASM, with idea to port it to MenuetOS and to ensure that the SQL part of application will be consistent with the remaining assembler part. Well, I don't like some issues in SQLite - mainly the approach to convert everything to strings back and forth... Regards. |
|||
|
06 Jun 2004, 15:09 |
|
|
f0dder 06 Jun 2004, 23:04
Well, there's a whole bunch of issues with SQLite... it isn't typed, uses strings, is _certainly_ not safe with multiple accesses to the database (well, at least not over a network), etc. But it's easy to use and relatively fast
|
|||
|
06 Jun 2004, 23:04 |
|
< Last Thread | Next Thread > |
Forum Rules:
|