Oxygen Basic

Information => Open Forum => Topic started by: JRS on October 14, 2014, 03:50:30 PM

Title: VB6 Extended
Post by: JRS on October 14, 2014, 03:50:30 PM
Charles,

Dave's sb_engine.dll isn't a COM interface but a standard DLL. My goal was to use Dave's code for my SBT Linux project. I think the best thing to do is use DLLC to prototype the SB IUP based IDE/Debugger in Windows before moving on to Linux.

I may need to ask a question or two as I have gotten rusty with DLLC.  :(

Nice to see SB + O2 + VB all playing well together.



.
Title: Re: VB6 Extended
Post by: JRS on October 18, 2014, 08:55:33 PM
I have made some progress on the VB6 theming front. Using this Manifest Creator Add-in (http://www.vbforums.com/showthread.php?661054-Calling-XP-Vista-Win7-Manifest-Creator-from-VB6-Add-Ins&p=4070511&viewfull=1#post4070511) makes the process painless.

If your interested in giving VB6 a bit of a DLL/OCX overhaul, this thread is for you.

CommonControls (Replacement of the MS common controls) (http://www.vbforums.com/showthread.php?698563-CommonControls-(Replacement-of-the-MS-common-controls))

.
Title: Re: VB6 Extended
Post by: JRS on October 18, 2014, 09:23:43 PM
I seem to be on a roll. Here is the Script BASIC IDE/Debugger themed. (XP & Win7)

Another plus is the IDE now supports theming for IUP controls. I going to see if I can get the IUP dialog layout feature working from within the IDE.


.
Title: Re: VB6 Extended
Post by: JRS on October 19, 2014, 09:10:44 AM
Hi Mike,

Can you give this themed version of the Script BASIC IDE/Debugger a try on Win10? I'm curious if the theming manifest has changed going to Win8 / Win10.

TIA

John

.
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 19, 2014, 09:50:55 AM
Hi John,

Scintilla and its common controls seem to be themed while the VB6 Tab and Toolbar controls aren't.

.
Title: Re: VB6 Extended
Post by: JRS on October 19, 2014, 10:01:41 AM
Thanks Mike !

Windows theming only works with tabs at the top. Bottom and side revert to Win2000 style.  :-\ This is noted on the IUP site as a BTW.

I'm digging into the update and work (see prior link) of common controls for VB6 and getting my environment up to date.
Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 01:51:16 AM
I have been reading about the ActiveX Control version (http://www.vbforums.com/showthread.php?698563-CommonControls-(Replacement-of-the-MS-common-controls)&p=4716949&viewfull=1#post4716949) replacement for the MS common controls.

This should give VB6 a little more of an extended life.
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 20, 2014, 07:21:56 AM
The thread is very interesting indeed, and the effort to replace VB6's long-outdated control palette is really worthwhile.

I'd however rather not rely on the supplied ActiveX .DLL's but compile the needed .CTL files/bundles directly into the resultant VB6 .EXE file. The reason is .OCX's are huge (it happens very often when an .OSX is written in VB6 rather than C/C++) while .CTL's allow for selective compilation of features useful for the actual project, and you can even delete irrelevant features of the individual controls to further reduce the final .EXE size.

I've looked through the sources and I confirm that the author does know his way around vbAccelerator.com (http://www.vbaccelerator.com/home/VB/index.asp) -- the VB6 gurus' Mecca of hardcore VB6 programming. :)
Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 10:39:42 AM
Thanks for taking a look Mike. You're right, the guy seems to know his VB way around. I think it's cool that the community has come together to keep VB classic relevant and forcing MS to continue supporting the VB classic runtime.
Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 04:09:41 PM
Hi Mike,

Sorry to bother you again but if you have a moment can you test this new build of the SB IDE/Debugger. It's using the VBCCR11.OCX and VBCCR11SideBySideAndVisualStyles.res files. Can you also explain what you mean when you said the tool-bar wasn't themed. It's flat button style and difficult to distinguish between the new Win10 and the old Win2k styles. MS seems to have reverted back to their roots.

FYI - You shouldn't have to register the OCX and just put it in the same directory as SB_Debug.exe .


.
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 20, 2014, 05:30:35 PM
Hi John,

Sorry to say but the OSX doesn't theme the debugger either. See the attached picture (top to bottom): i) how themed toolbar button, tooltip, and tab should look in Win'7; ii) same, in Win'10; and iii) how unthemed toolbar button, tooltip, and tab look under both Win'7 and Win'10 for all the three SB_Debug versions that I currently have.

BTW this last SBDebug.exe still seems to be dependent on stock mscomctl.ocx rather than VBCCR11.OCX! IIRC there must be a message in that thread that would describe how to re-arrange an existing VB6 project (SBDebug in your case) for this custom OSX set... :-\

.
Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 05:38:00 PM
Thanks!

I must of missed something. At least now I know what I'm suppose to be seeing.

Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 06:20:34 PM
I believe my missing step was not adding the common controls replacement OCX to the project. Duh. Still no luck getting the toolbar to look like your IDE. Everything else seems modern and up to date with how other applications look. (non-VB) I need to do more digging on this problem specifically as it might be something as simple as a property setting or this control doesn't theme.  ???

.
Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 07:29:12 PM
The answer seems to be to use the VBCCR11.ToolBar rather than the MSComctlLib.Toolbar. I tried to cheat and change the name in the .frm file. It gave an error when I loaded the project again. Looks like I'll have to rebuild the forms again using the new OCX common controls.  :-\



.
Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 08:39:50 PM
Here is an example of using some of the controls of the replacement OCX.



.
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 20, 2014, 09:45:12 PM
John,

The thread attempts to set forth some general guidelines to be followed in order to upgrade an existing project with the replacement controls from Krool's library, starting with this message (http://www.vbforums.com/showthread.php?698563-CommonControls-(Replacement-of-the-MS-common-controls)&p=4448447&viewfull=1#post4448447).

It looks like you will need some manual work done on your main form to upgrade it by eliminating the stock mscomctl.ocx controls altogether and replacing them with Krool's counterparts. That's the downside of it. But there's also an advantage: you can fix your control placement in the meantime to allow for somewhat different metrics in Vista+ environments and you can also flip the tabs to the tab control's top to let them get their theming right together with the other controls on the main form.
Title: Re: VB6 Extended
Post by: JRS on October 20, 2014, 10:21:48 PM
Quote
But there's also an advantage: you can fix your control placement in the meantime to allow for somewhat different metrics in Vista+ environments and you can also flip the tabs to the tab control's top to let them get their theming right together with the other controls on the main form.

You read my mind. Dave's beta release was to get functionality going. It was my job to put it in a pretty dress.  8) I got wrapped up in SBLisp and should have been working with Dave on this.  :-\
Title: Re: VB6 Extended
Post by: JRS on October 21, 2014, 09:29:54 PM
Mike,

It seems that the new common controls OCX only works with .exe based forms and not ActiveX OLE interfaced forms. On a positive note, the new OCX allowed me to remove the theming SUB and .rc which the new OCX seems to handle even if I'm not using the OCX's specific controls.

Any ideas how I might be able to get the new OCX to work with my ActiveX created forms?

Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 21, 2014, 11:41:22 PM
Sorry John,

Can't give you any clues right away; it's been a long time since I fiddled with VB6 last. I need two or three days to finish off my current freelance contract and I'm planning to be free by this weekend. Can it wait till then, do you think?
Title: Re: VB6 Extended
Post by: JRS on October 21, 2014, 11:48:58 PM
No rush. Real life always comes first. Thanks for the offer to have a peek.
Title: Re: VB6 Extended
Post by: JRS on October 24, 2014, 10:48:47 AM
Mike,

Update

I joined VBForums and was able to get a response from Krool and he pointed me to someone that may have had success using his OCX with ActiveX form controls. (DLL). I sent him a PM and hope to hear back.

(See Krool's thread for current activity)

While I'm waiting ...

I'm wondering if I create an  ActiveX DLL from scratch using the new OCX, maybe I'll have better luck. Worth a try.
Title: Re: VB6 Extended
Post by: JRS on October 25, 2014, 07:32:15 PM
Here is the link to get your mouse wheel working in the VB6 IDE.

Mouse wheel events do not work in the Visual Basic 6.0 IDE (http://support.microsoft.com/kb/837910)
Title: Re: VB6 Extended
Post by: JRS on October 26, 2014, 04:21:31 PM
No word from Krool but I have been chatting with Dave and found out the SB COM ext. module should handle ActiveX .exe controls as well. (wasn't tested) I'm happy to report that it worked but was unable to get it to work with the new OCX common controls replacement. I was able to get theming to work with the Manifest Creator add-in. (see attached)

The listbox add item caused an exception error (but recovered) and it didn't show the form with the old OCX MSCAL (calendar) control.

I'm just about to call this a lost cause unless Mike can pull some magic from his VB hat.

At least I have a way to create modern looking .exe VB classic applications. (SB IDE/Debugger)

.
Title: Re: VB6 Extended
Post by: JRS on October 26, 2014, 09:30:03 PM
I have come to the conclusion that the only sane path to take with this is to use VB6 as a GUI designer and generate an IUP cross platform GUI solution. My hope is that using Dave's COM/VB connection I can get the pixel scale values for control sizes and placement using the defined scale. (.frm defaults to twips) I can then dynamically translate that to IUP under SB program control. It's all theory at the moment but I can't see investing a bunch of time into trying to extend VB classic as a side project of SB.

I would compare the VB classic fan club to bunch of Harley Davidson hobbyists that can't let the old girl go.

Attached is what the SB COM object  browser is returning for the SB_Example.dll. (ActiveX DLL example)

.
Title: Re: VB6 Extended
Post by: JRS on October 27, 2014, 06:09:36 PM
VB6 makes adding a web browser control to your project like adding a button.

Code: Visual Basic
  1. Private Sub Form_Load()
  2.   WebBrowser1.Navigate "www.scriptbasic.org/forum/index.php"
  3. End Sub
  4.  

VBForums Statistics

Threads  670,772   Posts  4,235,229   Members  170,707


Another example of ageless beauty. (see attached - for Mike)

.
Title: Re: VB6 Extended
Post by: JRS on October 28, 2014, 08:35:21 PM
For those running Vista and beyond, here is a nice enhanced message dialog project for VB6.

cTaskDialog 0.6 (http://www.vbforums.com/showthread.php?777021-VB6-TaskDialogIndirect-Complete-class-implementation-of-Vista-Task-Dialogs)

(http://i.imgur.com/m1mx9ja.jpg)
Title: Re: VB6 Extended
Post by: JRS on October 29, 2014, 10:48:22 PM
I ran into a nice VB6 add-in called CodeView. A very handy tool for finding things quickly.

Download (http://planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=75397&lngWId=1)

FWIW This second round with VB6 and the enhancements by the community is like running into an old girl friend and realizing there still might be something there.  :-*

.
Title: Re: VB6 Extended
Post by: JRS on October 30, 2014, 01:42:46 PM
I have a thread going on the VBForums (http://www.vbforums.com/showthread.php?779695-Script-BASIC-IDE-Debugger-and-COM-VB6-extention-module) site in the Other BASIC board. (180+ views < 12 hours) One of the members that seems to be a VP pro is showing interest in the project.

FYI: Here is what my current VB6 IDE looks like on XP. (see attached)

.
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 30, 2014, 01:59:54 PM
(http://www.ntnusymbiosis.com/wp-content/uploads/2011/09/thumbs-up.jpg)

VB6 is cool and has always been. :D

Try to use the Google Translator to follow this post (http://bbs.vbstreets.ru/viewtopic.php?f=28&t=44358). It will enable you to generate true Windows console applications in VB6 easily as well -- a feature that's never been supported by VB6 natively.
Title: Re: VB6 Extended
Post by: JRS on October 30, 2014, 02:35:07 PM
Thanks Mike for the console app toolkit. I used Google Translate to read it but had to go back to the original to download the files.

EasyConsole - create a console application in VB in just a few steps

In this theme, new version, bug reports and questions on the use of brick.
In the "Projects" is the theme of a satellite - it reasoning technology, praise and criticism.

This brick allows you to create a VB (VB6) full console application, attaching to this record minimum of effort, adding to the project about 10 lines of code:!:

Brick itself - the usual module EasyConsole (easycons.bas):
Latest version:

     easycons_1.0.0.zip (http://bbs.vbstreets.ru/download/file.php?id=9937)
         version 1.0.0
         (656 bytes) Downloads: 104


In order to take advantage of a brick, you need to perform only three steps:

     Add EasyConsole module into your project.

     Connect to Project → References type library «Microsoft Scripting Runtime», known to some as the townsfolk FSO.

(http://bbs.vbstreets.ru/download/file.php?id=9938)

Note that before you add it, the item must look somewhere in the middle of the list.

Making VB generate "console» EXE-Schnick. When my plugin ACM-Tools will be made, it would require all-only install one checkbox in the properties of the VB-project. But until I made this plugin, you will need to edit the VBP-file (the project file) manually in Notepad and add the following two lines:

Code: Visual Basic
  1. [VBCompiler]
  2. LinkSwitches = -subsystem: console
  3.  
(http://bbs.vbstreets.ru/download/file.php?id=9939)

You can then use the module and compile the full console applications to VB6!

The use is as follows:

     You call the function once EasyconInitialize of module EasyConsole.
     You from anywhere in your project accesses objects stdin, stdout or stderr for its management console.
     For example the following code:

Code: Visual Basic
  1. stdout.WriteLine "Hello Wolrd! Long Live VBStreets!"
  2.  

     Displays in the console line «Hello Wolrd! Long Live VBStreets! ».

Deal with brick examples will help you:

examples.zip (http://bbs.vbstreets.ru/download/file.php?id=9940)
     Archive with examples (4 examples)
     (22.12 KB) Downloads: 89

The archive 4 examples:

     HelloWorld - simply displays some welcome text to the console.
(http://bbs.vbstreets.ru/download/file.php?id=9941)


Reversor - you type in the console word or sentence, and the program displays it in the console in otzerkalennom (strreverse) form.
(http://bbs.vbstreets.ru/download/file.php?id=9942)

SimpleShell - stupid primitive command-line shell (type cmd.exe). Supports about 9 teams and launch external programs.
(http://bbs.vbstreets.ru/download/file.php?id=9943)

VbGrep - a simplified version of the utility grep - the command line specified search words (separated by spaces), the utility reads text from stdin-a, and outputs to stdout only those rows where the search text. At the same time, and displays the line number in which the search term is found. The example does not need to run the utility itself, and the batch file TEST_VBGREP.BAT, which feeds the utility text file with the text of the song Jingle Bells, as well as the words to search for specified words «the» and «fun».
(http://bbs.vbstreets.ru/download/file.php?id=9944)

Template (Template)
Also, for your convenience, so that every time you do not have to create a project, add a module, add the item to the Project → References and edit the project file in notepad, I made a template that will immediately create a project with the right screwing:
(http://bbs.vbstreets.ru/download/file.php?id=9945)

You may be familiar with the mechanism of templates when added template from FNDLL. To install the template, you need to download this file here:

template_1.0.0.zip (http://bbs.vbstreets.ru/download/file.php?id=9949)
     Project Template (with the module with version 1.0.0)
     (1.51 KB) Downloads: 75


And extract its contents to a folder with the project templates.

For example, if you have VB6 installed on a standard location:
c: \ program files \ Microsoft Visual Studio \ VB98 \
Then you need to extract the files in this folder:
c: \ program files \ Microsoft Visual Studio \ VB98 \ Template \ Projects

Lows
This solution has one drawback. Console applications can not be debugged. Rather, debug, of course you can, but try to write something to stdout when running under debugging (or read anything from stdin-a) privedё error (which, nevertheless, can be treated).

If you are debugging is critical, I see two possible solutions to this problem:

     Make a copy of the file and name it VB6.EXE, say, VB6CON.EXE. Then use a utility EDITBIN edit the file, changing the value of the field on the subsystem console. That is something like this:
(http://bbs.vbstreets.ru/download/file.php?id=9947)

After that, to work on your console project, use it as an IDE VB6CON.EXE, rather than just VB6.EXE. In this case, together with the environment will create a console window, and debugged your console programs will work fully, just as would behave in a compiled form.
Editbin utility included with Visual Studio, and 6, and the Platform SDK, so it must be you, unless you are one of those strange people who put only VB6, but not the whole VS6. But in any case, you can edit any other editor vb6con.exe PE-files.

Quite another option. You can create a class or form CDbgConsoleEmulator, which Implements ITextStream write and implement this interface. The module also EasyConsole using technology I have described an elegant determine under debugging if the project works, you need to work while under debugging instead of FSO-shnyh objects slip an instance of your class CDbgConsoleEmulator (which can be not just a class, but also the form in particular) . This instance will handle calls himself Read / ReadLine / Write / WriteLine and do something. For example, if it is a form - fully emulate the console interface.

Title: Re: VB6 Extended
Post by: JRS on October 30, 2014, 07:38:35 PM
Dave converted an ASM/DisASM DLL project by Oleh Yuschuk to work with VB6.

Quote
Disassembler understands all standard 80x86 commands, FPU, MMX, AMD's MMX extensions, Athlon/PIII MMX extensions and 3DNow! instructions. It does not decode SSI or SSI2 commands. Disassembler assumes 32 bit code and data segments but correctly decodes prefixed 16-bit commands. Several decoding modes allow you to select the amount of returned information (which is inversely proportional to execution speed): command length only, basic information useful for code analysis, or full decoding with dump and assembler form. Multiple options select desired format. Disassembler and Assembler support both MASM and Borland's IDEAL modes.

Assembler converts single command from the ASCII form to the binary code. It allows to find several possible encodings, or even to create search patterns with undefined operands.

(http://files.allbasic.info/ScriptBasic/COM/vbasm.png)

Documentation (http://files.allbasic.info/ScriptBasic/COM/Olly_Readme.html)

Generic DLL project site (http://www.ollydbg.de/) (see attached OllyDBG screen shot)

OllyDbg Quick start (http://www.ollydbg.de/quickst.htm)

.
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 30, 2014, 10:43:53 PM
Olly's Assembl.c is mostly sufficient to create, with some effort, a simple 32-bit JIT Asm compiler for ScriptBASIC. :)
Title: Re: VB6 Extended
Post by: JRS on October 30, 2014, 10:48:24 PM
I'm thinking the same but I have no ASM experience. It would be a great way to learn. :)

I'm thinking that using DLLC would the quickest way to get a prototype working.

@Charles - Would you have time to create a simple framework for a JIT assembler for SB?
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 30, 2014, 11:21:26 PM
You don't need to know anything about assembly for that, John. assembl.c provides a recursive descent parser and a line-by-line line compiler while asmserv.c contains a lookup table for a fair subset of asm instructions (many are still missing and some are faulty though). The developer will have to design a "linker" function that will supply lines of asm code to Assemble() and will receive assembled byte sequences and copy them into a sequential buffer in executable memory. Then the "linker" will have to run a brief second pass to imprint the numeric values of actual label offsets into the jump and call instruction blanks left over during the first pass for that purpose. The entry point addresses of the resultant assembled procs can be used for calling from the C code of SB engine proper.

The entire thing could be compiled as a DLL extension module. Perhaps Dave can accept the challenge? :)
Title: Re: VB6 Extended
Post by: JRS on October 30, 2014, 11:35:30 PM
Quote
Perhaps Dave can accept the challenge?

Dave is out of commission with tendinitis in his arms. (too painful to code anymore)

If you would be willing to mentor this along, I would be wiling to do as much of the leg work as possible. If you, Charles and I  put our heads together on this, everyone would benefit in the end. It would be a great way to get BASIC programmers introduced to ASM. I have already put a similar effort into C BASIC.

 
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 31, 2014, 12:18:29 AM
Oh, I'm sorry, I didn't know that. :(

I started fiddling with asm in FBSL v3 a decade ago with such an Olly-based DLL. I'll see if I can find the sources and I will send them to you if I can.

Title: Re: VB6 Extended
Post by: JRS on October 31, 2014, 12:24:53 AM
I would be happy with an ASM stub function that does the setup for a in-line ASM routine that is created with the Olly DLL on the fly.

That would seem to be a good first step. You would call the function with something similar to bes_CallArgsEx() that describes the arguments being passed.

Title: Re: VB6 Extended
Post by: JRS on October 31, 2014, 12:43:34 AM
Attached it the current source for Krool's replacement common controls OCX.


.
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 31, 2014, 07:57:50 AM
Hello John,

Luckily I've found the sources so your OllyASM effort is feasible. Attached please find the DLL (compiled with MinGW GCC v4.3.3), two FBSL scripts to get an idea of how to deploy it, and two precompiled executables to see it in action jumping around happily and calling external and internal functions.

Be forewarned however that IIRC the DLL is not bugless nor is its asm instruction LUT complete.

I will send you the sources as a Code::Blocks project in an e-mail.


Be sure to have your DEP service disabled because it JIT-compiles the code into conventional, not executable, memory!

.
Title: Re: VB6 Extended
Post by: JRS on October 31, 2014, 11:15:39 AM
Thanks Mike for the download and e-mail. I'm probably the last person of our group to be spearheading this effort. My plan is to understand Dave's version in VB first, before looking at any possible migration to SB. My hope is Charles will whip up an ASM stub function in DLLC to give this some legs.

Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 31, 2014, 04:06:35 PM
You're welcome, John.

Though the assembl.c and asmserv.c files are still bearing their original Olly names, they have been revised to contain code that's only relevant to assembler. It also includes my debug helper functions that enable you to inspect the assembly process in your console. Those can be safely deleted or better compiled conditionally in order to reduce the DLL size. Moreover, the project doesn't need -O3 optimization and can be compiled with a -Os (optimize for size) switch to minify the DLL still further. The resultant machine code isn't dependent on source code optimization and the compilation speed will stay very high regardless. Finally, exepacking the resultant DLL with UPX (http://upx.sourceforge.net/) in a -force --ultra-brute mode will make it absolutely tiny.

If Charles or somebody else in the know agrees to develop the stub functions, here's an absolute minimum of what should be done:

1. Memory allocation in Build() should be changed from HeapAlloc() to VirtualAlloc() with a WRITABLE attribute that should then be changed again to READABLE+EXECUTABLE once the compilation process is successfully over. This will enable you to bypass the existing DEP restrictions.

2. Alternatively, the Build() function's buffer which is always 64KB large may be memcpy-ed into a buffer of exact size VirtualAlloc-ated by the procedure that's supposed to call Build() on the SB side. The exact byte size of resultant machine code is returned by Build() on successful compilation. The pointer to the 64KB buffer may be returned in an additional argument to the function and should be free-d on copying.

3. The call-by-pointer stub functions should be variadic to allow for an arbitrary number of arguments to be passed to the JIT assembled routines. The machine code entry pointer value is returned in the second argument to Build().

4. The last argument to Build() was meant for syncing the line numbers in the FBSL source script with the debug output in the compilation console. It may be omitted if this functionality is irrelevant to SB.
Title: Re: VB6 Extended
Post by: JRS on October 31, 2014, 07:17:24 PM
Mike,

I wish I had the experience and understanding of ASM like you and Charles has. I'm just being honest and saying up front that I'm not capable of integrating Olly with SB. The JIT linking part is beyond my reach.
Title: Re: VB6 Extended
Post by: JRS on October 31, 2014, 07:54:57 PM
I ran into this tutorial about how to make .NET forms COM visible.

Making a .NET Dll COM-Visible (http://jumbloid.blogspot.co.uk/2009/12/making-net-dll-com-visible.html)

Script BASIC .NET example (http://www.scriptbasic.org/forum/index.php/topic,323.msg1445.html#msg1445)
Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 31, 2014, 08:35:09 PM
John,

If I understand the purpose of DLLC correctly, you can use it as it is to call Build() in OllyASM.dll passing to it the pointer to the asm source string and getting back the pointer to the corresponding JIT compiled procedure. This is where DLLC's usability in its current form ends.

Now you must also have a mechanism to bind the JIT compiled asm procedure's pointer returned by Build() with a C prototype of this procedure, which would allow you to call this procedure in a usual C way passing (in fact, pushing on the stack) the required arguments and accepting its return if the procedure is a function rather than a sub.

This should be a trivial task for the person who has already done similar things in DLLC. This is why let us request Charles together to help you out with this because I can hardly afford studying the SB sources from scratch reinventing the wheel whose plot Charles should still be keeping in his head. :)
Title: Re: VB6 Extended
Post by: JRS on October 31, 2014, 08:54:26 PM
Your observation and research is dead on. As you say it's up to Charles to fill in the missing piece in DLLC. I'm a user of DLLC, not it's author. Charles has created a low level C interface with DLLC. It brings out the multi-threading features of SB and does some fancy footwork sharing the IUP message pump between threads.

I would love to have a ASM JIT option for SB as it would fill out the offering nicely.

Title: Re: VB6 Extended
Post by: Mike Lobanovsky on October 31, 2014, 09:00:37 PM
OK then, let's wait for Charles' response while I'm changing the guard on his magic flying carpet and flying off to the warm dreamlands for the coming 7 or 8 hours.

Z-z-z...
Title: Re: VB6 Extended
Post by: JRS on October 31, 2014, 09:59:11 PM
Charles,

If incorporating the Olly DLL as a stub function looks like it would take some work, I'm happy with using the existing O2 JIT virtual DLL feature. This would allow staying up to date with your current technologies and you would have to do nothing.  8)

It's concerning that Mike feels the library isn't solid and may frustrate a BASIC programmer more than it would help.

I thought I remembered you showing someone how they could enter ASM code in O2 and it would convert it to a binary executable string. Isn't that what Olly does?