Page 1 of 3 123 LastLast
Results 1 to 40 of 117

Thread: [RESOLVED] Assuming VB6 goes multi-platform...APIs?

  1. #1

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Resolved [RESOLVED] Assuming VB6 goes multi-platform...APIs?

    Assuming that sometime in the future VB6 goes multi-platform through the continued efforts of RADBasic and TwinBasic then perhaps we ought to start, well in advance, identifying the various APIs we use in our VB6 programs and identify the corresponding API that might do a similar task on the target o/s we have in mind.

    I know that for at least one of my VB6 programs the amount of APIs that I utilise is considerable, especially when I want my program to perform operating system style GUI functionality.

    It seems sensible to know which APIs we may have to transfer to when all this comes about.

    Assuming this all occurs then the main oses that are likely to be targetted I am guessing would be Linux in its various flavours and Mac/osX?

    Is my approach completely wrong, would it be wiser to create and use some middleware to allow past and future versions of BASIC to access 'foreign' o/s APIs?

    Should we start coding replacements for those APIs we know and love? To be ready for this time?

    Is this an effort that this community could do as a whole rather than just bicker about what should be done?
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  2. #2
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by yereverluvinuncleber View Post
    Is this an effort that this community could do as a whole rather than just bicker about what should be done?
    No, you need to bicker.

    I've always felt that this question is the reason that cross platform exists so poorly.
    My usual boring signature: Nothing

  3. #3
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Shaggy Hiker View Post
    I've always felt that this question is the reason that cross platform exists so poorly.
    For VB6, the reason it could not be cross platform is because it has a native code compiler but more importantly, it heavily depends on COM. There is no COM in Linux. There is no COM in Android.

    As for why cross platform implementations historically tended to be poor is for one simple reason, user interfaces. The only real cross platform UI implementation is HTML/CSS. It is almost impossible to translate a native Windows UI to say, an Android native UI. The plumbing is too different. However, when we exclude UI code, cross platform support is actually quite decent. .Net 5 and 6 are good examples. You could run non-UI .Net 5 code on any platform with no problem, even with complicated things like Sockets. TwinBASIC could achieve the same if Wayne can figure out what to do about COM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  4. #4
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Assuming VB6 goes multi-platform...APIs?

    VB6 isn't "going" anywhere.

    Threads about OtherBasic already have their own forum here. Move along.

  5. #5
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by dilettante View Post
    VB6 isn't "going" anywhere.

    Threads about OtherBasic already have their own forum here. Move along.
    Yea, this should have been raised in the TwinBASIC thread.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  6. #6
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Assuming VB6 goes multi-platform...APIs?

    I think it should have been raised in a second thread about TwinBasic in the Other Basic forum. We need more threads on that topic rather than one monster thread. I haven't touched it, aside from asking people to start new threads, because people can choose for themselves in this. But I'm not above pushing for a new thread when I can.
    My usual boring signature: Nothing

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Assuming VB6 goes multi-platform...APIs?

    I think what's going on is that fans of VaporBasic are really just advertising/proselytizing. Their boring threads aren't getting as many eyeballs as desired, so they put on their short skirts and lean against the lamppost here until the cops chase them away.

  8. #8
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Assuming VB6 goes multi-platform...APIs?

    What's really odd about that post is that I read as far as "short skirts" and my mind went immediately to wondering how you were going to tie them to the Scots. I was thinking that you were headed for something like caber tossing, lifting large stones, or something like that. Fortunately, you went a different way, cause that would have been a really weird analogy.
    My usual boring signature: Nothing

  9. #9
    The Idiot
    Join Date
    Dec 2014
    Posts
    2,721

    Re: Assuming VB6 goes multi-platform...APIs?

    I think this is both for VB6 and OtherBasics.
    why?

    when I installed TwinBasic and did try it out I also thought, I would like to code purely internal commands, no typelibs, no API, no 3rd party.

    and immediately I found problems.
    a lot of sources do use API, and its almost impossible to find "advanced" pure VB6 code out there.

    to have a thread with advanced coding that allows only the use of internal commands would be really nice.

  10. #10
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by baka View Post
    when I installed TwinBasic and did try it out I also thought, I would like to code purely internal commands, no typelibs, no API, no 3rd party.
    VB6 is exactly the same. VB6 is little more than a runtime of functions like Len, Mid, Asc etc. What makes VB6 seem like so much more than this is actually two things, the compiler and the IDE. The compiler is capable of bonding together a complicated mixture of Win32 APIs and COM classes. The IDE then further enhances the experience by making a lot of this drag and drop or 1 click operations. The TwinBASIC compiler is already nearly as capable as the VB6 compiler. You can already write complete applications in TwinBASIC as it is. The major difference is the IDE. TwinBASIC doesn't yet have a drag and drop style IDE like VB6 for building UIs so making a UI in TwinBASIC as of this date is going to be quite tedious. My clock sample is an example of this. I had to create the UI manually which is why it takes a tonne of code. All of this is taken care of automatically in VB6 by the IDE and compiler.

    This will change though. I believe that Wayne already gave a preview of a Forms engine that promises to bring VB6's RAD features to TwinBASIC. I think it's slated for a January release if I'm not mistaken.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  11. #11
    The Idiot
    Join Date
    Dec 2014
    Posts
    2,721

    Re: Assuming VB6 goes multi-platform...APIs?

    yeah. I saw the video of the form. and like u say, it will get there.

    now, if we want to be ahead of time and create applications without using any API, we also need to prepare with tons of useful functions, purely basic.

    from time to time we get those, some of the experts gives a "u can do this in vb6 without api and its actually as fast or even faster than calling API"

    thats what Im looking for, a more specific thread with "no api/3rd party" allowed. lets get serious.

    but, since TB is evolving all the time, and also adding additional functions Im not 100% sure if its worth it. could be this is useless if TB creates its own commands that we can use.

    what I usually need that I also call API/typelibs are:
    - load/save/render png
    - music and sound (mp3)
    - memory operation copymemory
    - subclassing/peekmessage the mouse/keys
    - unicode helpers (to get command$, filenames, folders etc)

    and all those could be added eventually in TB, if Wayne is serious about cross-platform to be able to do those things in a cross platform application.

  12. #12
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by baka View Post
    now, if we want to be ahead of time and create applications without using any API, we also need to prepare with tons of useful functions, purely basic.
    Ah I get where you're coming from. What you actually want is typically referred to as a standard library. For example, the .Net Framework for those of us in VB.Net. We almost never have to use Win32 APIs or 3rd party libraries in .Net applications.

    I actually think that for the TwinBASIC/VB6 ecosystem, Olaf's RichClient can fill this need almost perfectly, if only he could be convinced to document the damn thing!

    However, if RichClient is a no-go, then I suggest all of the VB6 programmers and the TwinBASIC developers come together and raise a discussion towards starting work on a standard library. Then all of you guys can contribute whatever code you want in the form of functions and classes to this library and then you have Wayne include it as a standard library for TwinBASIC. I'm actually surprised none of you have brought this up already. I think one of you should bring it up in GitHub to see if at least Wayne is open to this.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  13. #13
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: Assuming VB6 goes multi-platform...APIs?

    Yeah, I'm also a vote for this being in the Other Basic forum.

    In this forum, many (if not the vast majority) of us are tied to things like DirectX, GDI+, the advapi32 crypt functions, the specifics of how COM works, and so many more things that are forever tied to Windows, that I seriously doubt we're looking hard at other OS platforms. As such, I personally enjoy this forum keeping that focus.

    Let them start sub-threads with TwinBasic (or whatever) in the title, if they want ... the way we've had to deal with RC stuff here.
    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.

  14. #14
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    I think this should have been in the TwinBASIC thread because lets be real here, RADBasic is probably fiction. Any topic that mentions any BASIC product with 100% VB6 compatibility should be about TwinBASIC.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  15. #15

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: Assuming VB6 goes multi-platform...APIs?

    OK, a potentially nice thread, one bit of name calling and some calls to move the thread. That doesn't bode well but let's persist.

    I think that TwinBasic has some credibility bearing in mind Wayne's previous involvement in VB, he has already shown more than just his intentions by creating something very tangible. Wayne's positivity is far in excess of that shown by the initial detractor here who seems to have lost his positivity on the way through life. I know he's been through some tough times but to call TwinBasic and RADBasic Vapourware isn't fair. I know RADBasic seems more spurious in some of the more knowledgeable minds here but Carles is delivering real and usable trialware so please give them both at least the positivity they require to complete their offerings. No need for denigration at this stage as it is subtle sabotage.

    I imagine that to allow VB6 code to be transplanted to other oses APIs, these calls would have to be caught, the capture implemented as some sort of middleware on those systems. I am guessing some of us could write those as discrete modules in C. Thinking aloud - being on a 'foreign' platform could they be written in some sort of BASIC native to that specific o/s... Gambas springs to mind for example, do this locally initially and then when TB/RB matures, it could compiled using 'our' products instead? This would have the benefit of keeping it BASIC.

    I don't care where this thread goes but I do think that like Krool's controls some of the 'pure' basic methods of implementing alternatives to what we currently use for APIs would be useful to VB6 coders directly.

    This thread won't benefit VB6 itself as a product as such but it will benefit VB6ers programming in VB6 if it allows their pure WIN APIs calls to run on another o/s without code change. I think let it stay here for the moment and see if it gets any traction (I doubt it will as getting this community to move in any one direction is like herding soup - next to impossible), if it becomes particularly orientated toward TB or RB then the mods can move it later.
    Last edited by yereverluvinuncleber; Dec 22nd, 2021 at 07:44 AM. Reason: modified "allows their pure WIN APIs [U]calls[/U] to run on another o/s "
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  16. #16
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by yereverluvinuncleber View Post
    This thread won't benefit VB6 itself as a product as such but it will benefit VB6ers programming in VB6 -
    if it allows their pure WIN APIs to run on another o/s without code change.
    It's already in "the description", that there's no "Win-APIs" which will run on another platform than Windows
    (aside from a few exceptions like e.g. the OpenGL-APIs and some of the "file- and socket-stuff").

    The usual solution for that is, when "normal Users" (as in: "not Library-Authors") -
    start developing their own "User-Code" (their own Apps) against an "Abstraction-layer"
    (usually reachable through dedicated Classes, which act as the "bags of certain functionality-types").

    And only when these "bunch of Classes" are "quite complete in their coverage of topics"
    (which is the point, where one usually applies the term "framework" for the lib(s) which contain(s) them),
    "normal Users" will reach the point, where their own UserCode-Modules will not have a single API-declaration in them.

    That's the usual way to solve the problem of writing platform-independent Apps.

    And of course this leaves the Authors of these Class-Frameworks with the responsibility,
    to make the *internally* used "flat-APIs" work on "most of the foreign platforms".
    (ideally they think about this stuff beforehand, before they even start developing such a larger lib).

    And that's the reason, why framework-authors usually use "already platform-independent flat-libs"
    (and not the WinAPI) - for most of their *internal* implementations, which work *behind* these
    "abstracting-Classes, a normal User will be able to work through without any platformspecific-codechanges".

    Olaf
    Last edited by Schmidt; Dec 22nd, 2021 at 06:57 AM.

  17. #17

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: Assuming VB6 goes multi-platform...APIs?

    Actually, rather than implying that the WIN APIs might be available elsewhere, what I meant to say was that the WIN API calls might be identified, intercepted and then redirected to allow the code to stay somewhat similar on multiple platforms.

    I do get your point though Olaf but I think what I am looking for is compatibility with the format of WIN API calls that helps existing VB6 code to migrate seamlessly. This isn't specifically for me. Conversion or migration to other technologies seems like a potential stumbling block for others with big code bases, using a lot of WINAPI calls, whereas a conversion of one existing WIN API call to a similar one on another o/s (on a one by one basis) seems to me a less challenging leap of faith.

    In my javascript code if I wanted a bit of functionality that later versions of .js had by default, I would write a polyfill, also in javascript. I might also write it in jscript and call it externally or even a bit of C code sitting there as a external binary.

    I just think, if we have the BASIC programming skills and there is a native implementation of BASIC on the foreign o/s then we could use this to write 'polyfills' that replicate that API functionality, perhaps with a scanner that scans our existing VB6 code and modifies each WIN API call to redirect it to the polyfill, however that is achieved...

    As before I am merely thinking aloud and I think thinking is allowed, forgive me if I am doing it wrong.

    PS. With regard to TB/RB coming up with functionality that might supercede what we might have to offer, perhaps we could set up a table where the community would be able to provide support in the form of code. I do not imagine for a moment that RB/TB will be offering full replacements for the whole WINAPI. but we could collaborate to ensure that there is an alternative for the most familar and widely used APIs.
    Last edited by yereverluvinuncleber; Dec 22nd, 2021 at 07:48 AM.
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  18. #18

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: Assuming VB6 goes multi-platform...APIs?

    This is grist to the mill.

    https://lwn.net/Articles/824380/

    https://www.linuxquestions.org/quest...-linux-307939/

    It seems to me that the best approach is Olaf's but that won't be an option for many, so the direction might be Wine with some BASIC middleware? We might find ourselves wanting to contribute to the WINE project but not able to as we are using the wrong language...
    Last edited by yereverluvinuncleber; Dec 22nd, 2021 at 08:55 AM.
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  19. #19
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by yereverluvinuncleber View Post
    ...what I meant to say was that the WIN API calls might be identified, intercepted and then redirected to allow the code to stay somewhat similar on multiple platforms.
    Stuff like that (the intercepting and re-delegating of Win32-calls -> to the matching system-APIs of a given target-platform),
    this is exactly what the Wine-project tries to accomplish.

    Which - by comparison - is a huge project with a lifespan of nearly two decades now (driven by multiple developers) -
    and stuff like that simply doesn't fit into the "workload, caused by the development of a normal compiler".

    Quote Originally Posted by yereverluvinuncleber View Post
    ...we could use this to write 'polyfills' that replicate that API functionality...
    These "writing efforts" are already done -
    and the "polyfills" (ordered "by category") are available behind "categorized Class-Names".

    You under-estimate by far how deep the "Win32-Flat-API-dependency-tree" is reaching,
    until you see for example a properly rendered Unicode-TextString on "some Rectangle" on "your Screen".

    Olaf
    Last edited by Schmidt; Dec 22nd, 2021 at 10:01 AM.

  20. #20
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Assuming VB6 goes multi-platform...APIs?

    Got it right on the first line of the first reply.
    My usual boring signature: Nothing

  21. #21
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Shaggy Hiker View Post
    Got it right on the first line of the first reply.
    That reply is (IMO) completely backwards.

    There's absolutely no need to "bicker", because true platform-independence:
    - is real and it works for millions of developers
    - and it is achieved to 99.9% always via framework- or larger runtime-libs
    ..(which then provide an abstraction for the implementing language, usually via classes)

    Olaf

  22. #22

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: Assuming VB6 goes multi-platform...APIs?

    I think Olaf is right, we have Wine and perhaps that is what we need to do, perhaps push TB/RB to work (somehow) with Wine providing access to those WinAPIs that Wine has already implemented - not running as a Windows app on Linux but natively, somehow with access to Wine's implementation of those APIs. I don't even know if that is possible.

    I did like the idea of a 'trampoline' that handled Linux API calls natively but redirected any WIN API calls to some other handler, in this case the Wine implementation.

    I had hoped that there might be a simpler path and perhaps there might still be for some of them. Some might have direct equivalents that we could simply identify and call.

    The only other alternative is a rewrite using cross platform technologies that already exist. That is what I was hoping to avoid but it might be inevitable.
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  23. #23
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Assuming VB6 goes multi-platform...APIs?

    Cross platforms projects will have to be limited to what the languages offer intrinsically. No APIs available.
    And if the developer nevertheless wants to use APIs, he will have to write alternative code for each OS, like:

    Code:
    #If RunningOS = osWindows Then
        ' Call Windows APIs 
    #ElseIf RunningOS = osLinux Then
        ' Call Linux APIs here
    #ElseIf RunningOS = osAndroid Then
        ' Call Android APIs here (OK, Android is based on Linux, but has already evolved)
    #ElseIf RunningOS = osMac Then
        ' Call Mac APIs here 
    #End If
    Trying to convert Win APIs to other platforms... we will have to wait for an AI to do that. But at that time programming will be done automatically too, so...

  24. #24
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Schmidt View Post
    You under-estimate by far how deep the "Win32-Flat-API-dependency-tree" is reaching
    Forgive me but why do you make this claim for the Win32 API but not for COM. You've often disagreed with me vehemently whenever I raised the idea that COM is a major hinderance to cross-platform implementations of Windows development tools. The COM ABI and data structures are also just Win32 implementations, many of which reside in OleAut32.Dll. For example, SafeArrayCreate, CoTaskMemoryAlloc, SysAllocString, about 20 or so VarCy functions, CoCreateInstance along with dozens of other co-class related functions, DispCallFunc and a whole lot of others.

    What am I missing here?
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  25. #25
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Assuming VB6 goes multi-platform...APIs?

    I think there is no point of comparison between COM and the API.
    COM is a lot simpler.
    The API is almost to recreate Windows.

  26. #26

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: Assuming VB6 goes multi-platform...APIs?

    Let's not turn this into a battle please. Niya...

    Olaf, you do not need to answer. We have the answer.
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  27. #27
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Eduardo- View Post
    I think there is no point of comparison between COM and the API.
    COM is a lot simpler.
    The API is almost to recreate Windows.
    Picture this. They send one man to Mars and ask him to build an exact copy of the entire USA by himself. He sends back word that it's too much work for him alone. They replay with "ok, just build the state of New York then"...

    You get what I'm saying here?
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  28. #28
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Niya View Post
    You've often disagreed with me vehemently whenever I raised the idea that COM is a major hinderance to cross-platform implementations of Windows development tools.
    I did indeed, because the following...

    Quote Originally Posted by Niya View Post
    The COM ABI and data structures are also just Win32 implementations
    ...is still as wrong as can be.

    You can cobble together "the proof" for that easy enough all on your lonesome:
    - implementing your first lighweight COM-Class in a plain VB6 *.bas module
    - and then telling me, where the problem with platform-independence is, when you re-write that *.bas in plain C

    Olaf

  29. #29
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by yereverluvinuncleber View Post
    Let's not turn this into a battle please. Niya...
    I'm asking a simple question...

    Also, how did you even see that? Weren't you ignoring my posts or some such thing?
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  30. #30
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Schmidt View Post
    ...is still as wrong as can be.

    You can cobble together "the proof" for that easy enough all on your lonesome:
    - implementing your first lighweight COM-Class in a plain VB6 *.bas module
    - and then telling me, where the problem with platform-independence is, when you re-write that *.bas in plain C

    Olaf
    Ok I still don't get what you're really saying. Let me see if I can illustrate what I mean.

    Ok lets take this in VB6:-
    Code:
        Dim b() As Byte
        
        ReDim b(0 To 0)
        
        b(0) = 255
    Now I would imagine that VB6 would call SafeArrayCreate to create the array. Then it would make a call to SafeArrayRedim to re-dimension the array. So now what I'm thinking is that if I want COM based code like this to work on say, Linux then SafeArrayCreate and SafeArrayRedim would have to be implemented by whatever cross-platform framework is being used. I imagine this would have to be done for every COM based function in a library like OleAut32.DLL. I'm just asking, am I wrong about this or is there something I haven't thought of? I'm just curious. We went back and forth about this over the years but I have never really understood why you think it's so doable with COM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  31. #31
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Niya View Post
    Picture this. They send one man to Mars and ask him to build an exact copy of the entire USA by himself. He sends back word that it's too much work for him alone. They replay with "ok, just build the state of New York then"...

    You get what I'm saying here?
    Yes, but I don't think that's even close.
    It would is like building a house.

  32. #32
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Eduardo- View Post
    Yes, but I don't think that's even close.
    It would is like building a house.
    I think you're seriously underestimating how many COM functions are in the Win32 API. It's easy to think it's small when you're mostly concerned with the ones concerning VARIANTS, BSTRS and SAFEARRAYS but COM is a lot and I mean a whole lot more than that. The COM API contains all kinds of wizardry. There was a time in my life when I was crazy about COM. I once spent an entire week or so just to figure out how to create and pass real VB6 data structures from C++ to VB6. I'm no where near Olaf's level of knowledge but I had to learn quite a bit about COM for this. COM is huge.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  33. #33
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Niya View Post
    I think you're seriously underestimating how many COM functions are in the Win32 API. It's easy to think it's small when you're mostly concerned with the ones concerning VARIANTS, BSTRS and SAFEARRAYS but COM is a lot and I mean a whole lot more than that. The COM API contains all kinds of wizardry. There was a time in my life when I was crazy about COM. I once spent an entire week or so just to figure out how to create and pass real VB6 data structures from C++ to VB6. I'm no where near Olaf's level of knowledge but I had to learn quite a bit about COM for this. COM is huge.
    I could be underestimating, but I think you are overestimating.
    You can't compare COM with the whole API.
    The whole API I agree, it would be like building a city in the desert.

    And I don't think they would have to recreate all and every feature. DCOM and many things are not needed.

    Still, I agree that recreating COM is not a small task.

    I would do the minimal needed, like StdFont, StdPicture, OLE_COLOR, reference count.
    "COM" in non-Windows OSs would be limited.

  34. #34

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: [RESOLVED] Assuming VB6 goes multi-platform...APIs?

    [Redacted] Let it continue.
    Last edited by yereverluvinuncleber; Dec 23rd, 2021 at 06:36 AM. Reason: Redacted
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  35. #35
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Niya View Post
    Ok I still don't get what you're really saying. Let me see if I can illustrate what I mean.

    Ok lets take this in VB6:-
    Code:
        Dim b() As Byte
        
        ReDim b(0 To 0)
        
        b(0) = 255
    Now I would imagine that VB6 would call SafeArrayCreate to create the array...
    Of course, but what do you think happens under the covers
    (when I implement this "by hand" for the Linux-side with a C-Compiler)? ... right, not much.

    Please look at the current wine-implementation for that yourself:
    https://source.winehq.org/source/dll...32/safearray.c

    All of the VB6/VBA array-handling can be covered with just these 20-25 SafeArray-APIs -
    it's doable in a reasonable amount of time - and with a reasonable amount of directly linked-in code.

    The wine-sources are under LGPL and "compatible with the rest of the opensource-libs" I plan to use anyways.
    (I've not yet decided, what and how much to implement myself - and where to make use of "Wine-source" directly).

    Same goes for CoTaskMemAlloc/realloc/free and the few BSTR-helper-APIs (it's a reasonable amount of functions,
    and basically memalloc-related tasks).

    The only thing with a *bit* more efforts, is the Variant-APIs (where we need nearly the whole set).

    All in all these are the basic necessities (which I guess is only about 1% of the total code, the Wine-project encompasses).
    CoCreateInstance is the registry-based way to instantiate a COM-object - a problem which can be solved much more directly -
    and regfree - via a simple "flat-API-export" which should be part of any COM-Dll such a compiler produces.

    This is all not really rocket-science - entirely within the scope of such a compiler-project.

    Olaf

  36. #36
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: [RESOLVED] Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by yereverluvinuncleber View Post
    Mods please lock this thread before it becomes the usual slanging match.
    If you don't realize that this discussion is OnTopic, then it cannot be helped.

    Olaf

  37. #37
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,995

    Re: [RESOLVED] Assuming VB6 goes multi-platform...APIs?

    yereverluvinuncleber, you already resolved it? We are talking about building cities in a desert, and in Mars, and you already figured all out?

  38. #38
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Schmidt View Post
    Of course, but what do you think happens under the covers
    (when I implement this "by hand" for the Linux-side with a C-Compiler)? ... right, not much.

    Please look at the current wine-implementation for that yourself:
    https://source.winehq.org/source/dll...32/safearray.c


    All of the VB6/VBA array-handling can be covered with just these 20-25 SafeArray-APIs -
    it's doable in a reasonable amount of time - and with a reasonable amount of directly linked-in code.

    The wine-sources are under LGPL and "compatible with the rest of the opensource-libs" I plan to use anyways.
    (I've not yet decided, what and how much to implement myself - and where to make use of "Wine-source" directly).

    Same goes for CoTaskMemAlloc/realloc/free and the few BSTR-helper-APIs (it's a reasonable amount of functions,
    and basically memalloc-related tasks).
    Well this is huge. It hadn't cross my mind to use something like the Wine source code to augment your own compiler efforts. I really didn't consider this at all. There is a lot of pre-written code in there.

    Quote Originally Posted by Schmidt View Post
    All in all these are the basic necessities (which I guess is only about 1% of the total code, the Wine-project encompasses).
    CoCreateInstance is the registry-based way to instantiate a COM-object - a problem which can be solved much more directly -
    and regfree - via a simple "flat-API-export" which should be part of any COM-Dll such a compiler produces.

    This is all not really rocket-science - entirely within the scope of such a compiler-project.
    Ok I see. What you're saying is similar to what Eduardo suggests in that the entire COM infrastructure isn't needed for VB6/VBScript/VBA compatibility.

    Quote Originally Posted by Eduardo- View Post
    I could be underestimating, but I think you are overestimating.
    You can't compare COM with the whole API.
    The whole API I agree, it would be like building a city in the desert.

    And I don't think they would have to recreate all and every feature. DCOM and many things are not needed.

    Still, I agree that recreating COM is not a small task.

    I would do the minimal needed, like StdFont, StdPicture, OLE_COLOR, reference count.
    "COM" in non-Windows OSs would be limited.
    Olaf seems to agree and who am I to argue that. He knows COM way better than I ever will.

    Anyways, his points make sense and he may be right in that it will take a whole lot less work than I believe. It's still a lot of work but with something like the Wine source available, I can see why someone would think it's doable once they have the determination. I guess this will all be put to bed once and for all once Wayne Phillips implements the TwinBASIC cross-platform compiler.

    Well carry on folks......I don't know why some people thought I came here looking for a fight
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  39. #39

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: [RESOLVED] Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Schmidt View Post
    If you don't realize that this discussion is OnTopic, then it cannot be helped.

    Olaf
    I just don't want it to go off topic and degenerate. I want this one to close gracefully before it degrades. They always degrade.
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

  40. #40

    Thread Starter
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: [RESOLVED] Assuming VB6 goes multi-platform...APIs?

    Quote Originally Posted by Eduardo- View Post
    yereverluvinuncleber, you already resolved it? We are talking about building cities in a desert, and in Mars, and you already figured all out?
    The problem is not resolved obviously - but my understanding of it has changed and I think that it will come down to a). Identifying similar APIs (where such exist) and writing platform specific code - or b). Abandoning the Win way of doing things entirely and migrating to cross platform technologies, RC5/6 or similar.

    If the Wine code can be used somewhere in the middle and we can capture our use of Win APIs I will be both amazed and impressed at the same time.

    PS. I have a feeling I will be doing b).
    Last edited by yereverluvinuncleber; Dec 22nd, 2021 at 02:18 PM.
    https://github.com/yereverluvinunclebert

    Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.

    By the power invested in me, all the threads I start are battle free zones - no arguing about the benefits of VB6 over .NET here please. Happiness must reign.

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width