Ahhh, I didn't realize this, but apparently Gimp is also based on Cairo. That makes sense given that it's a multi-platform piece of software. But, to the point being discussed herein, they distribute what they call a Gimp Toolkit (or GTK+) that has yet another distribution of the Cairo Graphics package. On that page, here's what they have to say about licensure:
You are welcome to redistribute GTK+ binaries, including applications that bundle them, on other web sites, CD-ROM, and other media. You don't have to ask for permission. That's one of the points of Free Software. One important thing that the GNU licenses require is that you must also redistribute the source code. [emphasis in original]
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
And, in an attempt to be clear about the legality of things, I've attempted to pull out the pertinent parts.
Then at least be correct about it...
Originally Posted by Elroy
This next quote is from the GPLv2:
Cairo is not under GPLv2 - it's under LGPL v 2.1... (the LGPL differs in many things from the GPL)
And yes, cairo is dual-licensed - it also comes under Mozillas MPL 1.1, which you cited below:
The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license. … Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License.
And your implication (as well as DexWerx's for that matter) is wrong, that I'm under any obligation
to release any sources for vb_cairo_sqlite.dll...
Yes, according to MPL 1.1 modifications have to be released in source (along with binaries you distribute) -
but I did not make any mods on the Original Cairo-Sources...
So, modifications (as per MPL) are all about "changing Original Source-Files" - and I did none of that.
@wqweto
As Colin has pointed out already - what's going on here has not really much to do with "trust issues".
(Elroy is apparently perfectly fine in using a Dll which I have compiled - but "shuns" for no reason the second one in the bundle,
which would offer cairo-acces over convenient COM-Class-Wrappers - which ensure all the necessary UTF8-conversions as well as automatic "Handle-Freeing").
I'm not sure how often you spend time in NewsGroups, MailingLists and public Forums,
but I can ensure you (having read hundreds of thousands messages on public boards over the last 25 years),
that most of the petty viciousness is caused by:
"pissing someone off, by correcting their wrong statements before the eyes of "everyone else" in the given discussion-group".
And I *have* seen (in other tech-discussion-groups), what pettiness (which too often ensues exactly between people
who consider themselves the "knowledgeable leaders" of certain groups) - can do to "published sources" (if there are any) -
(where stuff was "forked away" out of spite - disrupting a formerly whole community into "enemy camps").
So no, I will not risk, putting the RC5 (which shall provide interface-stable and backward-compatible runtime-classes for a new compiler)
under that kind of threat (of fragmentation) until the compiler and new IDE is ready...
(and as this thread shows quite clearly, there's a few people here - who'd like nothing better than doing exactly that).
Elroy is apparently perfectly fine in using a Dll which I have compiled
Olaf (and Colin), you know quite well that's extremely out of context, and not a correct statement. Sure, I'd be fine using a DLL you compiled so long as the source for it was available. I think everyone paying the least attention to this thread is clear on that point. Sure, I explored your DLL and brainstormed a bit about possibilities, but that's a far cry from actually using it in anything that's production.
And, you may be right (I don't really know) about the various licensing issues. However, the whole point is rather moot, because I'm certainly not going to legally challenge you on those points.
So, your position is that we use the whole RC5 enchilada or nothing at all?
Okay, I'm completely done with exploring that avenue.
----------------------------------
I've explored but haven't found anything. Apparently Cairo Canvas was once open-source, but they took it private. It would be very nice if we could find a compiled Cairo DLL with the stdcall calling convention, that was open sourced, and had a modicum of documentation. I'm still thinking that a TypeLib and one of the CDECL DLLs might be the way to go.
I suspect Olaf is correct that making calls through DispCallFunc might be slow (with all the Variants it tosses around). But I'm thinking a TypeLib may solve this problem. That's just not my strongest suit.
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
why always talk about RC5? isent this thread about cairo?
Im so tired that the second someone discuss cairo, automatically RC5 is there, like a symbiosis.
what im interested, after following this thread is Cairo. can we use it? can a typelib be made? the cairo.dll, how to use it or we need a compiled vb6 friendly version?
what im not interested is: RC5, UTF8-conversions, Handle-Freeing and actually anything else about how to manage cairo (for now) this will be interesting "after" the cairo is available for us to use.
right now i feel cairo is a hostage and the only way to use it is by converting into a religion and follow its doctrine and rules.
Baka,
The best is to use VS 6 C++ and declare __stdcall everywhere in the C sources of cairo and then compile.
Then it can be used like any other flat-dll in VB6 without typelib.
Wqweto did this approach already with sqlite successfully.
Modifications _include_ build files used to create the binary... I've posted this in previous threads on this topic.
So not only is releasing a binary using custom build scripts without releasing the scripts against the letter of the law per both licenses (LGPL and MPL), and the spirit of them, it's just intellectually dishonest.
I'd like to offer my deepest apologies. I truly started this thread with the full intent to stay far away from any discussion of RC5. But I got sucked in, thinking that vb_cairo_sqlite.dll, along with its source, would be an excellent answer. However, I now realize I shouldn't have pursued that.
Now, regarding a re-group, as I see it, there are two alternatives:
Use one of the available DLLs (to which source is available) that have the CDECL calling convention, and develop a TypeLib that converts our StdCall convention to CDECL.
To take the Cairo source code, modify it so that it doesn't expose the CDECL calls, write a wrapper that exposes an API with the StdCall convention that calls the private CDECL calls, and then compile it and release it all including the source.
Trick, Wqweto, & Krool have suggested approach #2. However, that's certainly somewhat beyond what I'm currently setup to do. It'd be beyond cool if someone actually did this (including the "release the source" piece).
However, I'm now wondering about approach #1 (a TypeLib). I've only dabbled with TypeLibs in the past, and I'm far from the expert. However, with some long-ago experience with C, this is something that seems like I could do. So, here are a couple of question:
Can a TypeLib be used to translate StdCall calls to CDECL calls?
If above is true, would this be just as fast as a C++ compiled wrapper that wrapped the CDECL calls and exposed StdCall calls?
And, a TypeLib should be much faster than using the DispCallFunc, correct?
-----
And again, I apologize for my participation in this thread veering off-course. Unless its Olaf talking about releasing the source to his vb_cairo_sqlite.dll, I will do my best to ignore all future discussion of anything RC5 related in this thread.
Best To ALL,
Elroy
EDIT1: And BTW, I've got a good idea on how to assemble a good working list of all the Cairo calls with their arguments. I'll be looking into that, and report back. I'm thinking that, if we can get a "Declare Function" type list, that turning that into a TypeLib shouldn't be huge.
Last edited by Elroy; Aug 16th, 2018 at 08:09 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Can a TypeLib be used to translate StdCall calls to CDECL calls?
Don't think so. I think The trick debunked the myth that cdecls in typelibs work in compiled projects not so long ago -- the disassembly read "NO-T IMP-LE-M-ENT-ED" with op-codes :-))
Once again: cdecl declares from typelibs do *not* work both in IDE and compiled. Cdecl declares might have been working in VBA for *Mac* but don't think this is available there as of now too.
Can a TypeLib be used to translate StdCall calls to CDECL calls?
Don't think so. I think The trick debunked the myth that cdecls in typelibs work in compiled projects not so long ago -- the disassembly read "NO-T IMP-LE-M-ENT-ED" with op-codes :-))
Once again: cdecl declares from typelibs do *not* work both in IDE and compiled. Cdecl declares might have been working in VBA for *Mac* but don't think this is available there as of now too.
Hmm, well that's certainly disappointing to hear. I'd need to re-read it, but I thought there was a way to do it so long as things were compiled. But even if that's possible, it's certainly not an optimal solution.
I was just composing a post, thinking/hoping we'd start off simple. The following are a couple of declarations for Cairo.
Code:
Private Declare Function cairo_version Lib "cairo.dll" () As Long
Private Declare Function cairo_win32_surface_create Lib "cairo.dll" (hDC As Long) As Long
Private Declare Function cairo_win32_surface_get_dc Lib "cairo.dll" (surface As Long) As Long
However, the only open source DLLs I've got for those are using the CDECL convention. I've already got them working using the DispCallFunc function. But I fear that'll be slow, especially when it comes to other Cairo functions where speed may matter.
If someone has ideas on another way to make those calls from VB6, translating to the CDECL convention, I'm sure willing to do the testing.
But it's beginning to look like a C++ recompile is the only reasonable answer?
Best,
Elroy
Last edited by Elroy; Aug 16th, 2018 at 08:54 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
You can work with the CDECL functions from VB6 using a type library but it works only in the compiled form (i already made the example with printf seems). Unfortunately it causes the crash in IDE.
<offtop>I don't have something against RC5 and i think it's the best solution but i also think we should have the alternatives.</offtop>
The best approach is just make the dll with the proper calling convention (seems the cairo lib is open source). I think such dll should already exists. What's the problem to compile such dll?
The second approach is to make the wrapper to transmit the calls from STDCALL to CDECL (using dll, DispCallFunc, ASM, etcetera). You can automatize that process.
The third approach is using conditional compilation and using wrapper when debugging in IDE and using the typelib in compiled form. If you select that approach you'll have the troubles with callback (if any).
The fourth one is the same except using static linking (no dlls/dependencies).
I'd also be willing to do another test, if there's someone who's easily setup to do C++ compiles.
I'm just wondering about the true speed-hit from using DispCallFunc. Here's the only way I'd know to test that: Create two DLLs, one with CDECL convention, the other with the StdCall convention.
Just say, something like:
Declare Function TestCall Lib "TestDll.dll" (TestArg1 As Long, TestArg2 As Long) As Long
Two input Long arguments and a single Long return would be pretty representative of the the typical Cairo call. But for the test, just always return, say, TestArg1 + TestArg2.
Then, I'd be willing to take each of those DLLs and do some timing tests on them, using DispCallFunc for the CDECL one of course.
Take Care,
Elroy
EDIT1: I'm willing to continue my work to make a VB6 wrapper for a cairo.dll that uses DispCallFunc (which I'm already somewhat into). It'd just be nice to know that it didn't take a huge timing hit because of the DispCallFunc.
Last edited by Elroy; Aug 16th, 2018 at 09:05 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
To take the Cairo source code, modify it so that it doesn't expose the CDECL calls, write a wrapper that exposes an API with the StdCall convention that calls the private CDECL calls, and then compile it and release it all including the source.
There is no wrapper needed. The functions inside the C source would be compiled as __stdcall instead __ cdecl.
It's just a bunch of work to do this manually.
I'd like to offer my deepest apologies. I truly started this thread with the full intent to stay far away from any discussion of RC5. But I got sucked in, thinking that vb_cairo_sqlite.dll, along with its source, would be an excellent answer.
I'm sorry that that has proven not to be the case - you can chalk that one up to ignorance on my part. It was suggested, in good faith, believe me...
If you don't know where you're going, any road will take you there...
Option Explicit
Private Sub Form_Load()
Dim pSurf As Long
Dim pCr As Long
pSurf = cairo_win32_surface_create(Me.hDC)
pCr = cairo_create(pSurf)
cairo_set_line_width pCr, 3
cairo_set_source_rgb pCr, 1, 0.5, 0.5
cairo_rectangle pCr, 10, 10, 300, 200
cairo_stroke pCr
cairo_destroy pCr
cairo_surface_destroy pSurf
End Sub
Result:
All works correctly in the compiled form. All calls are processed correctly with CDECL:
But it crashes in IDE therefore you need to use a wrapper to debugging.
Well Trick, that's truly pretty cool. It all worked for me right-out-of-the-box.
It's a shame it doesn't work in the IDE. I suppose the wrapper could actually be a VB6 ActiveX DLL though. That doesn't seem like a bad alternative at all.
It might be possible to design things such that DispCallFunc is used when this wrapper DLL is running in the IDE, and the TypeLib info is used when running from compiled. That would make testing the wrapper DLL much easier.
I don't think callbacks are an issue. But there are a few Cairo functions with Strings (char) as returns and/or input arguments. I'll need some help with those, both in terms of DispCallFunc and the TypeLib.
There's also the issue of translation between UTF-8 and UCS-2, but I think I can handle that one if I could just get a byte-array into and out-of these CDECL calls.
Ahhh, there's also the issue of some structures. Specifically, the matrix structure. In VB6, it would look something like the following:
Code:
Public Type cairo_matrix_t
xx As Double
yx As Double
xy As Double
yy As Double
x0 As Double
y0 As Double
End Type
I know, I'm biting off a lot. I just want to make sure I can get this done to completion before I get tremendous amounts of time into it.
Thanks To All,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
BTW we can just include supporting CDECL functions to Declare statement. In fact we need only call ADD ESP, ARGS_SIZE after each call to update the stack. How to do that? We can use firehacker's approach where he used declare statement to call functions by pointer.
What's needed to achieve that?
Scan all the modules (EbGetExecutingProj/TipGetTypeLibOfHProject/TipGetModuleCount/TipGetModule/EbGetModuleFlags or using COM implementation);
Scan all the procedures in each modules (EbMemberBeginQuery/EbMemberGetCount/EbMemberGetMemberkind/TipGetFunctionIdOfMod/TipGetLpfnOfFunctionId or using COM method);
Check if the procedure is the Declare one (VB6 generates a small code thunk for each Declare function. This thunk calls DllFunctionCall):
ZZZZZZZZ - Address of DllFunctionCall you can replace to your hooker procedure.
YYYYYYYY - Pointer to EB_DELAYED_IMPORT_LOOKUP_ENTRY. You can check if a procedure is CDECL or not (for example you can use specific name or something like that)
Intercept DllFunctionCall inside the needed thunks.
Inside hooker you call the original DllFunctionCall and then call ADD ESP, ARGS_SIZE. ARGS_SIZE - you can determine from the typeinfo.
Now you can call CDECL functions in IDE (you can also make it in compiled form as well, but i would prefer the CDECL-typelib usage).
@Krool: I just went here and downloaded what looked like a good set of source-code. I believe the file named LATEST-cairo-1.14.12 should be a good source-code set.
And then, from everything I can tell, it looks like this is a fairly complete set of instructions for how they see it compiled. However, that doesn't appreciate the changes to make it StdCall compatible.
@Trick: That's quite interesting. As part of this, I'll probably keep pursing the gathering of a complete list of API declarations. They'll be needed if Krool gets a re-compile going.
This is actually getting somewhat exciting.
Y'all Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Also, I just did a test of an ActiveX wrapper, and it works perfectly.
Here's the ActiveX DLL class I put together for the test:
Code:
VERSION 1.0 CLASS
BEGIN
MultiUse = -1 'True
Persistable = 0 'NotPersistable
DataBindingBehavior = 0 'vbNone
DataSourceBehavior = 0 'vbNone
MTSTransactionMode = 0 'NotAnMTSObject
END
Attribute VB_Name = "clsCairoWrapper"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = True
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = True
Option Explicit
Public Function win32_surface_create(hDC) As Long
win32_surface_create = cairo_win32_surface_create(hDC)
End Function
Public Function create(surface As Long) As Long
create = cairo_create(surface)
End Function
Public Sub set_line_width(cairo As Long, Width As Double)
cairo_set_line_width cairo, Width
End Sub
Public Sub set_source_rgb(cairo As Long, Red As Double, Green As Double, Blue As Double)
cairo_set_source_rgb cairo, Red, Green, Blue
End Sub
Public Sub rectangle(cairo As Long, x As Double, y As Double, Width As Double, Height As Double)
cairo_rectangle cairo, x, y, Width, Height
End Sub
Public Sub stroke(cairo As Long)
cairo_stroke cairo
End Sub
Public Sub destroy(cairo As Long)
cairo_destroy cairo
End Sub
Public Sub surface_destroy(surface As Long)
cairo_surface_destroy surface
End Sub
I posted all of it, and not just what you'd paste into a new CLS in the IDE. So, if you wish to "play", save with notepad as CLS, and then load into an ActiveX DLL project, and then compile that project. Startup is "none". You will also need Trick's cairo.tlb from post #55. And I used the cairo.dll found here in the cairo-windows-1.15.12.zip file. Although, there are several compiles of the cairo source which look good.
CAUTION: Don't even try to run this ActiveX DLL in the VB6 IDE. It'll crash. All you can do is compile it.
And then, I just started a new Form1, referenced my newly created ActiveX DLL, dropped the following code into it, and voila, Cairo Graphics.
Code:
Option Explicit
Private Sub Form_Click()
Dim cw As New clsCairoWrapper
Dim pSurf As Long
Dim pCr As Long
pSurf = cw.win32_surface_create(Me.hDC)
pCr = cw.Create(pSurf)
cw.set_line_width pCr, 3
cw.set_source_rgb pCr, 1, 0.5, 0.5
cw.rectangle pCr, 10, 10, 300, 200
cw.stroke pCr
cw.destroy pCr
cw.surface_destroy pSurf
End Sub
And, that code immediately above runs absolutely fine in the IDE.
This is looking like a workable solution.
But Krool, please make a straight-up compile with StdCall if you're so motivated. I agree that that would be the ideal.
Best,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
[entry("cairo_version_string")]
long cairo_version_string (void);
You can skip cdecl because there is no parameters. In DispCallFunc just return a long value.
Then you can get string using such code (no error checking, bufer overrun etc.):
Code:
Option Explicit
Private Declare Function MultiByteToWideChar Lib "kernel32" ( _
ByVal CodePage As Long, _
ByVal dwFlags As Long, _
ByRef lpMultiByteStr As Any, _
ByVal cchMultiByte As Long, _
ByRef lpWideCharStr As Any, _
ByVal cchWideChar As Long) As Long
Private Sub Form_Load()
Dim sVersion As String
sVersion = BSTRFromLPSTR(cairo_version_string())
End Sub
Private Function BSTRFromLPSTR( _
ByVal pStr As Long) As String
Dim lSize As Long
lSize = MultiByteToWideChar(0, 0, ByVal pStr, -1, ByVal 0&, 0)
BSTRFromLPSTR = Space$(lSize - 1)
MultiByteToWideChar 0, 0, ByVal pStr, -1, ByVal StrPtr(BSTRFromLPSTR), Len(BSTRFromLPSTR)
End Function
There's also the issue of translation between UTF-8 and UCS-2
MultiByteToWideChar/WideCharToMultiByte. You should use byte array to UTF-8 (don't use String).
dang, this is great, in just a couple of hours its like a huge step forward.
my concern is speed, to compare against gdi32/+ and the rendering filters (as in the end its about that, to use a graphic method that is better, as im not convinced about the death of gdi at all)
another question is the activex and compiled version. when running IDE, we will use the activex, but when compiling the activex should not be used at all right?
I'll agree that I have no immediate plans of abandoning GDI32/+ stuff. However, Cairo is also an interesting option. And, from what I read, they've worked pretty hard to use all the GPU acceleration options available to them. So it's speed should be competitive with those other approaches.
Now here's what I see as how it would all work (with my current understanding of how to get it done. We'll need to identify a good cairo.dll. I've been leaning on the one found here. According to preshing's notes, he just followed the compile instructions from Cairo Graphics seen here.
So, to use that DLL, we'll need a wrapper (or the slower way of going through DispCallFunc, which I'm moving away from). So, for me to get the wrapper done, I'll be writing an ActiveX DLL in VB6. I already did a concept-test in post #60. I'll probably name that wrapper CairoWrapper.dll. It'll either need to be registered, or loaded with methods illustrated by The Trick as illustrated here. The Trick also has more complete examples of his code posted in other posts. But if you're willing to register, any ActiveX DLL will also work just fine that way.
So, we'd just need two files (cairo.dll and CairoWrapper.dll) and we'll be off and running. Since all the arguments are straight-forward pass-throughs, it should all be close to as fast as if we were directly using CDECL calls.
I'm not going to make any promises regarding timeframe, but I'll be working on this CairoWrapper DLL. And I'll absolutely post all the source to it when it's done, including the IDL for the TypeLib that Trick started. Just as an FYI, only compiling the CairoWrapper DLL will need to concern itself with this TypeLib. Once you've got the CairoWrapper DLL all setup, you should be able to directly reference that, and you'll be set.
Best Regards,
Elroy
EDIT1: And just to be clear, you won't be able to start a VBG with the CairoWrapper in it. I'm not sure why, but every time I just breath on the VB6 IDE's run button when a TypeLib with CDECL declarations in it is referenced, the IDE crashes. But compiling it and using it as a compiled ActiveX DLL seems to completely solve that problem.
Last edited by Elroy; Aug 16th, 2018 at 11:58 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
that means we need to create a setup program if we want to share a project using cairo? it will be the same Olaf has with his rc5.
hm. not optimal.
i did hope we could have 2 options, a compiling version where we are not using the activex, as it works compiled and one version that we use together with the IDE, adding the activex to it.
Well, if you're unwilling to use Trick's CreateObjectEx2, yeah, you'll need a setup. Don't forget it'll all be open-source, and specific to Cairo Graphics. Here's a better link to Trick's work.
It'd take a bit for me to get it done, but maybe someone will also pick up the mantle for a pure StdCall compile of the Cairo Graphics source. We'll see.
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Modifications _include_ build files used to create the binary... I've posted this in previous threads on this topic.
You are wrong - the MPL 1.1 does not mention any "build-files" specifically ...
all the MPL 1.1 talks about in the context of "modifications", is:
"changes on the original Source-Files"
...which I did not make and neither did I write "my own build-script" to produce the binary from the unchanged original sources.
Yes, we had that same discussion some time ago already -
but still you continue to make these wrong and dishonest claims
(implying on a *public board*, that I do something illegal...)
BTW - in Germany I could sue you for this.
(because it's not me - it's you who's breaking the law with an unjustified insult, slandering my credibility, please stop this nonsense).
👎👎
I've made the cairo.dll with the stdcall calling convention but i didn't test it (just changed declarations, i didn't work with cairo ever and don't know if i made all correctly). Just couple tests (works in IDE and compiled form):
Code:
Option Explicit
Private Declare Function cairo_win32_surface_create Lib "cairo_stdcall.dll" ( _
ByVal hdc As Long) As Long
Private Declare Function cairo_create Lib "cairo_stdcall.dll" ( _
ByVal psurf As Long) As Long
Private Declare Function cairo_set_line_width Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByVal width As Double) As Long
Private Declare Function cairo_set_source_rgb Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByVal red As Double, _
ByVal green As Double, _
ByVal blue As Double) As Long
Private Declare Function cairo_rectangle Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByVal x As Double, _
ByVal y As Double, _
ByVal width As Double, _
ByVal height As Double) As Long
Private Declare Function cairo_stroke Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long) As Long
Private Declare Function cairo_destroy Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long) As Long
Private Declare Function cairo_surface_destroy Lib "cairo_stdcall.dll" ( _
ByVal psurf As Long) As Long
Private Declare Function cairo_move_to Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByVal x As Double, _
ByVal y As Double) As Long
Private Declare Function cairo_line_to Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByVal x As Double, _
ByVal y As Double) As Long
Private Declare Function cairo_arc Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByVal xc As Double, _
ByVal yc As Double, _
ByVal radius As Double, _
ByVal angle1 As Double, _
ByVal angle2 As Double) As Long
Private Declare Function cairo_text_path Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByRef putf8 As Any) As Long
Private Declare Function cairo_set_font_size Lib "cairo_stdcall.dll" ( _
ByVal pcr As Long, _
ByVal size As Double) As Long
Private Sub Form_Load()
Dim psurf As Long
Dim pcr As Long
psurf = cairo_win32_surface_create(Me.hdc)
pcr = cairo_create(psurf)
cairo_set_line_width pcr, 3
cairo_set_source_rgb pcr, 1, 0.5, 0.5
cairo_rectangle pcr, 10, 10, 300, 200
cairo_stroke pcr
cairo_set_line_width pcr, 1
cairo_set_source_rgb pcr, 0.3, 0.5, 1
cairo_move_to pcr, 50, 50
cairo_line_to pcr, 320, 250
cairo_arc pcr, 100, 100, 80, 0, 6.28
cairo_set_font_size pcr, 32
cairo_text_path pcr, ByVal StrPtr(StrConv("Hello world!", vbFromUnicode))
cairo_stroke pcr
cairo_destroy pcr
cairo_surface_destroy psurf
End Sub
omg. this is incredible The trick! i knew it, if anyone it is you that can do it. im amazed of your knowledge of anything really. i wish i where that good!
this is a very good base, and from here, learn and add more commands to compare with gdi32/+ and see the gain and quality improvement.
does this mean we can skip the activex completely and focus on this dll that The trick created?
(i tried the test project and it works without a problem) both in IDE and compiled.
WOW, and here I was feverishly working away on a wrapper.
But it's all good.
So, all we need now is the declarations, correct? You didn't do anything toward a full TypeLib, right? I can do that part.
Also, Trick, if you don't mind, can you outline/document what you did to change it for the StdCall convention? Just so we have it documented. It might be worth sending it to the Cairo Graphics people so they can include it on their website.
THANK You,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
@Olaf
FACT: You've been distributing LGPL/MPL binaries without *the source, *without build instructions, or even *clear instructions of how to obtain the sources / build instructions, which is required by both licenses.
FACT: You don't include the *copyrights or the *licenses with your distributed binaries.
FACT: You said you would open source vbRichClient5.dll "in the next months" how many years ago was that now?
anyone can download your distribution to verify this.
Originally Posted by Schmidt
You are wrong - the MPL 1.1 does not mention any "build-files" specifically ...
all the MPL 1.1 talks about in the context of "modifications", is:
"changes on the original Source-Files"
...which I did not make and neither did I write "my own build-script" to produce the binary from the unchanged original sources.
Oh but it does.
Originally Posted by MPL 1.1
1.11. "Source Code"
means the preferred form of the Covered Code for making modifications to it, including all modules it contains, plus any associated interface definition files, scripts used to control compilation and installation of an Executable, or source code differential comparisons against either the Original Code or another well known, available Covered Code of the Contributor's choice. The Source Code can be in a compressed or archival form, provided the appropriate decompression or de-archiving software is widely available for no charge.
So which is it? Are you arguing that MPL 1.1 doesn't cover scripts used to compile, or are you arguing that you don't use "scripts" to compile every revision of vb_cairo_sqlite.dll
Trying to argue both, is doubly weak. Next you're going to try and argue that pasting a command from a text file is not part of the applicable "Source".
Originally Posted by Schmidt
BTW - in Germany I could sue you for this.
Is that some form of intimidation? "You know we can hear you, right?"
You can just using the c-headers to make the type library for that dll. It's simplest than using declare statement.
I just add __stdcall keywords to all the external public procedures and make the def file to avoid name mangling. If you need i can provide the changed sources but I think it makes no sense because I just changed the declaratons.
@baka, yes we can use only that native dll if it's correct. You can also link the library to the exe
Sorry I type from the phone...
Last edited by The trick; Aug 16th, 2018 at 05:29 PM.
@Trick: That's perfect. I just wanted a bit of documentation so nobody could claim it wasn't open-source. I'll just put this comment in the file I'm creating:
__stdcall keyword was added to all the external public procedures, and then the instructions provided by Cairo Graphics were used for compilation.
Should we put the compiler version you used? Or anything else? If someone else wants to recompile, I'd like to give them enough information to do what you did. I do see that you used version 1.14.12.
I'll probably go ahead and work up a BAS file with all the enumerations and declarations, and the cairo_matrix_type.
I've already tested String returns, and your BSTRfromLPSTR handles them just fine.
Again THANK you,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I couldn't manage to compile There are several sources to be compiled first *statically* and then at end compile all as stand-alone cairo.
Maybe The Trick can make a how-to guide.
I couldn't manage to compile There are several sources to be compiled first *statically* and then at end compile all as stand-alone cairo.
Maybe The Trick can make a how-to guide.
Yes, I'm hoping he has the time for that. It would really be wonderful.
And also, the declarations are coming along nicely, maybe close to half-done. I do have one problem that I'm not sure about. Trick, you gave some advice on this in post #61 (top of page 2). I could probably figure it out, but you can probably do it in 1/10th the time. It's calls like these:
Code:
Public Declare Sub cairo_tag_end Lib "cairo_stdcall.dll" (ByVal cairo As Long, ByVal char tag_name)
- or -
Public Declare Sub cairo_text_path Lib "cairo_stdcall.dll" (ByVal cairo As Long, ByVal char utf8)
Some even have two strings going in ... but if I could see how one was done, I'm sure I could figure out the rest.
Anyone is certainly willing to help. There are basically two issues: 1) we've got to get from UCS-2 to UTF-8, and then we've got to get it in a form we can pass as an argument.
Also, I'll be testing the cairo_matrix_type shortly. Hopefully, that'll just work.
Thanks,
Elroy
Last edited by Elroy; Aug 16th, 2018 at 08:32 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
FACT: You've been distributing LGPL/MPL binaries without *the source, *without build instructions, or even *clear instructions of how to obtain the sources / build instructions, which is required by both licenses.
No, not a "fact" - the MPL allows only a hint (or a link) to the site which contains the Original Code and the Original License(s),
when there were no changes to the Original Source the binary was produced from.
Originally Posted by DEXWERX
FACT: You don't include the *copyrights or the *licenses with your distributed binaries.
No, not a "fact" ... a hint "in a prominent place of a binary distribution-package" is enough -
and the file _Library-Licenses.txt (which is included in my binary-zip) mentions the Licenses as well as the Website(s).
The MPL states very clearly - that the "original License-Text" of the MPL has only to be included in case of Source-Distributions
(which I'm not required to provide with my binary, because the Original Source was not changed).
Originally Posted by DEXWERX
FACT: You said you would open source vbRichClient5.dll "in the next months" how many years ago was that now?
The vbRichClient.dll doesn't have anything to do with cairo-licensing -
and no, since more than 4 years now, I didn't have that much time for the whole (compiler-)project as before (when I was still self-employed).
The compiler-project would be long finished by now, if I'd had more time on my hands than only "the weekends".
Originally Posted by DEXWERX
Are you arguing that MPL 1.1 doesn't cover scripts used to compile...
As long as I did not change the original compile-scripts, then no -
stuff I created entirely myself - whilst not violating the Points a.) and b.) of the MPLs "Modification-Section1.9"
is not a "Modification" - and therefore a hint, where to retrieve the Original Sources (which were not changed) is sufficient.
So again, stop that nonsense - it's getting ridiculous by now
(it's not exactly rocket-science to compile a new cairo-version from scratch - given the website where the sources reside -
which is an information I did not hide at all, in my "binary-distro-zip").
Feel free to "make a case" at the FSF though - until then I seriously ask you again (since you're not a lawyer),
to stop slandering somebody due to your own mis-understanding of license-law - and until the time you're proven
right with an official statement made by a lawyer, you have no place to imply here, that I'm breaking the law in any way.
I've never in my whole time at VBForums contacted a Mod "to tell about somebody" - but this stuff
is going way too far by now.
Should we put the compiler version you used? Or anything else? If someone else wants to recompile, I'd like to give them enough information to do what you did. I do see that you used version 1.14.12.
Not exactly. I make the preprocessor definition like that:
You can download the sources (with described changes) from there. I don't know if i violate something if it's need i can delete it.
Should we put the compiler version you used? Or anything else? If someone else wants to recompile, I'd like to give them enough information to do what you did. I do see that you used version 1.14.12.
I don't know exactly, i attached the sources and anyone can compile it. Also i don't know if should i add something to README/NEWS/etc files.
I've already tested String returns, and your BSTRfromLPSTR handles them just fine.
You can just rewrite the sources to all the required functions accepts the BSTR strings.
Maybe The Trick can make a how-to guide.
You need to have the next static libraries (i'm not sure with proper naming (i mean versions 16/256)):
You should before compile it as described in the guide (although i didn't use the command line compiler and the scripts). All the libraries includes VS solutions except pixman and cairo ones. You can compile zLib, then libpng (it requires the compiled zLib and the sources), then the pixman (i manually made the project) one and eventually freetype library. Then you can start to compile the cairo library like the pixman one. There are the prepared VS projects like that you can just drop the sources to the certain folders.
Some even have two strings going in ... but if I could see how one was done, I'm sure I could figure out the rest.
See my example there is already cairo_text_path function BUT it has the incorrect call. Why? Because it'll work perfectly in the showed example but it won't work in the others cases (if you'll use non-ascii symbols)because as far as i understand cairo uses UTF-8 strings. You should use WideCharToMultiByte (with CP_UTF8 flag) to convert VB6-strings to UTF-8 ones and MultiByteToWideChar to reverse conversion. If a function accepts an ansi string you can use standard StrConv function.