A PowerBASIC roadmap - Continued

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Florent Heyworth
    Member
    • May 1999
    • 614

    A PowerBASIC roadmap - Continued

    I've been following the PowerBASIC roadmap thread which has
    exposed two views:

    1.) The one from those who need info about future version of PowerBASIC
    2.) The one from those who are quite happy to wait in the knowledge
    that PowerBASIC will do "the right thing".

    I'd like to address view 2:

    Firstly I love the compiler - small, fast tight code are the operative
    words - this, I hope will be maintained across future releases.

    PBDLL 6.0 and PBCC 20 were IMO very good releases in terms of speed
    , code size and inline assembler.

    However I consider the introduction of TCP and DDT as a mistake. Don't get me wrong, I think TCP support is
    crucial and DDT a time-saver.

    My gripe is that this functionality would have been better exposed
    as libraries and include files wrapping around functionality which
    is exposed by the operating systems. In the case of TCP having
    comprehensive wrapper functions in include files/modules would have
    made the very large existing code base which is available at large
    easier to grasp and extend.

    Of course, nothing prevents me from doing that, and in fact this is
    what I've done since I like to have more control over the winsock implementation.

    My gripe is that, IMO, PB should concentrate on adding intrinsic
    capability to PowerBASIC instead of wrappers around existing OS
    services in BASIC syntax.

    Instead of new features, I'd like an extension to the language:
    - Structured Exception Handling to replace BASIC's ancient ON
    ERROR GOTO model (okay structured exception handling IS part of
    the OS - the only way to use it gracefully is with an extension
    to PowerBASIC)

    and an extension to the compiler:
    - The possibility to produce LIB files as well as EXEs and DLLs
    - The inclusion of a macro pre-processor OR the ability to flag
    functions as INLINE

    and last but not least
    - PowerBASIC for Linux.

    These are the big four - which, again IMO, would make any upgrade to
    the compiler worth buying. I hope that at least a couple of these
    additions will be included in the next PB upgrade.

    I won't open the pandora's box of OOP which, although I consider it
    as very important, always raises big uproar.

    To finish: PowerBASIC rules, thanks for a great compiler

    Cheers

    Florent Heyworth


    ------------------
  • Chris Boss
    Member
    • Feb 1999
    • 6478

    #2
    The add to the subject:

    Many of us have mentioned the importance of supporting
    Static Libraries in the next version of PB !

    To take it a step further, I think it is important to make
    sure the Library format is NOT proprietary, but is one
    compatible with at least Microsoft languages.

    It would be nice to be able to use Libraries (non-MFC) created
    in MS C with PB and visa versa. It would be nice to be able to
    create Libraries in PB, that can be used with C.

    Hows does this help ?

    (1) For companies that use multiple languages for software
    development, it would allow the use of PB in the mix.

    (2) For companies that develop tools for programming languages,
    it would open up markets currently inaccessable to PB programmers.
    C programmers are more and more shying away from DLLs and prefer
    Static Libraries at times. If PB could make "universal" Static
    Libraries that could be used with C, then "new" markets are opened
    up for PB developers.


    Florent brings up a good point about adding more "functionality"
    to the core PB language, rather than simply add a bunch of
    wrappers to the OS. If Static Libraries were supported then it
    would encourage Third party developers to create all those "wrapper"
    functions, rather than have PowerBasic write them all.

    The Language needs some language constructs, such as Object
    Oriented
    coding. The basic concept of Objects is not that complex.

    An object simply is an advanced UDT that points to both data and
    functions and makes all the data in the UDT available to those
    functions.

    New features need to be added geared towards "Reusability" !

    The more modular the code can become and the more code can be
    reused, the faster development can be.

    The PB IDE needs to move into the RAD direction. While, not
    expecting Visual Design yet, it would be nice to have a
    "Code Generation Wizard" format which the IDE supported, which
    would allow third party developers to "Integrate" Wizard type tools
    directly into the PB IDE. A simple DLL with predfined functions
    by PowerBasic, which could be loaded and called by the PB IDE to
    impliment Wizards.

    If PowerBasic were to add a Wizard Engine to the PB IDE, you would
    likely see dozens of third party Wizards for all sorts of code
    generation within 6 months (or sooner). I wouldn't be surprised
    to see a bunch of Freeware Wizards within weeks.



    ------------------
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment

    • Tom Hanlin
      Member
      • Jun 1999
      • 6482

      #3
      Please describe what you mean by a "wizard engine" in more detail. What would you like it to do? How would you expect to interface to it?


      ------------------
      Tom Hanlin
      PowerBASIC Staff

      Comment

      • Mark Newman
        Member
        • Dec 1999
        • 445

        #4
        Look at how VB implements IDE add-ins. Though not the best-documented
        interface around and a bit weird at times, it works and as a result
        there's quite a number of useful add-ins available.

        VB add-ins have access to pretty much everything in the IDE, from
        code to menus to property settings and more. Just give the same
        access points to PB users and as Chris said, you'll have add-ins
        appearing within weeks!


        ------------------
        Mark Newman
        Mark Newman

        Comment

        • Chris Boss
          Member
          • Feb 1999
          • 6478

          #5
          Tom;

          The purpose of a Wizard engine is to "generate" code automatically
          by simply selecting a few options from a Wizard.

          The PB IDE should be able to search the folder it is located in
          (or a special sub folder) and search for any DLL with a special
          prefix (ie. PBX_ )

          The wizard DLLs (kind of like plugins), would have a set of
          predefined functions (by PowerBasic specs) in them which the
          PB IDE can call. The PB IDE can simply load the DLL when needed using
          LoadLibrary (API), find the function addresses and then call the
          functions when needed using Call DWord .

          Some possible predefined functions could be :

          PBX_MyName$()
          PBX_MyDesc$()
          PBX_MyIcon&()

          ' returns the Wizards name and description

          PBX_Execute(hWndParent&, Instance&, Flags&, RetData$)

          ' starts the wizard up

          The PB IDE would poll the Wizard DLLs for their names and
          description (and even get a handle to a icon) for adding
          them to the menus (or even add a button for the Wizard
          - individual buttons, one for each Wizard)

          The user selects the wizard he wants and the main entrance
          function is executed by the PB IDE.

          The Wizard now takes control and displays a Modal Dialogbox of
          its own and asks all the questions it wants. A Flag with bit values
          is sent to the Wizard to give it status about what the PB IDE
          may expect from it (like options set in its configuration,
          ie. Basic commands in all caps, etc).

          The Wizard will then generate code based on the users selections and
          return the generated code in a string variable. The Flag parameter
          would be used to pass back another set of Flags to tell the PB IDE
          what to do with the generated code.

          This is a simple Wizard concept.

          Advanced features could be added, by having a set of predefined
          Functions in the PB IDE (EXE) which the Wizard DLL could call back
          into the IDE to do things like get info about the current
          source code being editing. There are different ways to impliment
          callbacks, but by using callbacks into the PB IDE, then it could
          poll the IDE for necessary info.

          By creating a Bi-Directional communication between the IDE and the
          Wizards, all sorts of powerful RAD tools could be created.

          All PowerBasic would have to do is create a simple DLL template
          and distribute it with the compiler, so others can start creating
          their own templates.

          Also it would allow PowerBasic to increase its product line, by
          periodically adding new Wizards (sold separately), which could
          be made available long before you release each new version of the
          compiler (for a price of course).

          The Wizard model would allow a variety of Third party developers
          to add RAD tools to PB and they would be "integrated", rather than
          a bunch of "external" tools.

          Imagine having a tool like WinLift that has its own Wizard.
          The WinLift Wizard could ask all sorts of questions and then
          generate the basic skeleton code. It could even be possible to
          have the Wizard generate code for "all" the declared functions
          for a Third party DLL.

          The possibilities are endless.

          This concept would require very little from PowerBasic
          to impliment. You could write the basic code for a Wizard
          engine in a day. Then create one or two useful Wizards to
          ship with PB and then when it is released, others would
          create Wizards in days.

          Your first Wizard, could be a Wizard for "creating Wizards", which
          would generate the code for the skeleton of a Wizard using
          the predefined functions for Wizards. That would be even better
          than a template. PB users would be creating Wizards as soon as
          they install the new compiler. I know I would !

          Imagine Third party tools like WinLift, SiGrid, other custom
          controls and even EZGUI accessable through Wizards ?


          ------------------


          [This message has been edited by Chris Boss (edited September 13, 2000).]
          Chris Boss
          Computer Workshop
          Developer of "EZGUI"
          http://cwsof.com
          http://twitter.com/EZGUIProGuy

          Comment

          • Chris Boss
            Member
            • Feb 1999
            • 6478

            #6
            Just to make the concept of building Wizard more appealing:

            I have already made a Freeware DDT Visual Designer available.
            The Freeware Designer supports an important feature needed for
            building Wizards, which is Layers .

            Not only could this tool be used to create Wizard Dialog code
            quickly, but if a Wizard model was added to PB, I would
            definitely produce a new version of the DDT Designer to produce
            Wizard Dialogs using the Wizard format defined by PowerBasic.

            Imagine a Wizard that allows you to Visually Design other Wizards ?

            Using the Layering technique already generated by the Freeware
            Designer, it would be easy to create Wizards !



            ------------------
            Chris Boss
            Computer Workshop
            Developer of "EZGUI"
            http://cwsof.com
            http://twitter.com/EZGUIProGuy

            Comment

            • Gregery D Engle
              Member
              • Apr 2000
              • 1502

              #7
              Chris,

              That is a nice point. I like your idea.

              ------------------
              -Greg
              -Greg
              [email protected]
              MCP,MCSA,MCSE,MCSD

              Comment

              • Ian Cairns
                Member
                • Oct 1998
                • 823

                #8
                Chris,
                Don't get me wrong, I like the concept. (I'd just like to play "devil's advocate for a moment). But with every idea ther is always a downside. Have you considered that the easier it is to produce something "useful", the sloppier the coding becomes? And there will be a few gems out there, but you are going to have to expend a lot of time sifting through junk.

                Nevertheless, Static Libraries are a must! However, is there a 'standard' Library structure with a "known" format? And if so, is it owned by Bill? and would he let you use it?
                Regards,

                ------------------
                [email protected]
                :) IRC :)

                Comment

                • Wayne Diamond
                  Member
                  • Sep 2000
                  • 3194

                  #9
                  Drag-and-drop controls...
                  click-and-drag control resizing...
                  double-click to modify code...
                  WYSIWYG
                  I certainly dont want PB to "become another VB", but i mean ... is anybody else good at visualising forms in their head? (not me!)
                  If somebody comes out with a decent visual designer for PB, my life would be nearly complete.

                  ------------------
                  -

                  Comment

                  • Michael Mattias
                    Member
                    • Aug 1998
                    • 43447

                    #10
                    Nevertheless, Static Libraries are a must! However, is there a 'standard' Library structure with a "known" format?
                    Yes.

                    It's the Dynamic Link Library.

                    They can be produced by PB/DLL (but not VB, which produces OLE servers with a "dll" extension).

                    End of problem.

                    MCM


                    ------------------
                    Michael Mattias
                    Racine WI USA
                    [email protected]
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment

                    • Guest

                      #11
                      Static libraries don't require extra files to accompany an app as dlls do.
                      Think of a DLL as one of the old compiled BASIC pseudo-exe's which were spawned
                      with a command (it escapes me) and all the exe's (there were sometimes many)
                      had common variables blocks.
                      Libraries are perused by the linker and depending on the granularity of the library,
                      none, little or much extraneous code could be linked directoy into the program.




                      ------------------
                      Ron

                      Comment

                      • George Bleck
                        Member
                        • Nov 1998
                        • 3208

                        #12
                        Not for nothing... but doesn't the simple fact that you can do an INCLUDE that is controlled by some $IF $ENDIF's indicate that we already have static library support?

                        Granted it's not automatic and you would have to set some constant for the $IF statements to work, but it's already in place!

                        ------------------
                        George W. Bleck
                        Senior System Engineer
                        KeySpan Corporation
                        <b>George W. Bleck</b>
                        <img src='http://www.blecktech.com/myemail.gif'>

                        Comment

                        • Chris Boss
                          Member
                          • Feb 1999
                          • 6478

                          #13
                          To make a few points clear:

                          A Static Library is much different than a DLL. It gets embeded
                          into the programs EXE, rather than being a separate file loaded
                          at runtime. This prevents problems with different versions of the
                          same DLL (ie. VB 5.0 has 3 different versions of the runtime
                          - MS calls them Service Pack upgrades).

                          I have read (on the web) that C programmers are moving away from DLLs
                          as well and prefer Staic linking of Libraries.


                          Microsoft has its own Static Library (I think they use the extention LIB)
                          which is Linked into the final EXE.

                          A DLL is not a Static Library !

                          DLLs are Dynamic Linked Libraries meaning they are
                          linked Dynamically (at runtime), rather than at
                          design time.

                          As far as Wizards for the PB IDE, of course the quality depends
                          upon the developer and while some poor quality Wizards may be
                          created by some, most commercial Third party developers would
                          likely be of a high quality.

                          Wizards are a great way to make the PB compiler more of a RAD tool.

                          The old adage Time is money applies to programming and if
                          programmers have access to a variety of RAD tools to make them
                          more productive, they will save crucial time !



                          ------------------
                          Chris Boss
                          Computer Workshop
                          Developer of "EZGUI"
                          http://cwsof.com
                          http://twitter.com/EZGUIProGuy

                          Comment

                          • Steve Hutchesson
                            Member
                            • Oct 1999
                            • 5396

                            #14
                            Static libraries have been around for a very long time and it is normal
                            technology for the linker to resolve dependencies, literally only include
                            the code that is dependent.

                            Static libraries are at their worst when large groups of function are
                            bundled together so you get all of the code in the module by calling any
                            one of the functions in it. This is the problem of granularity and the way
                            around it is to write each function into its own module.

                            Done properly, Static libraries are extremely efficient in terms of code
                            size where dynamic link libraries are not. To get the functionality of one
                            function in a DLL, you have to include the complete DLL.

                            Code generation is no big deal under current capacity with PowerBASIC,
                            where I see a problem with Chris's suggestion, even though I see it as a
                            good idea, is that many do not use the PB IDE. I dont really think it is a
                            good idea to overload the PB IDE with an endless collection of extra bits.
                            It already has to carry the debugger and that is something I would like to
                            see as a seperate EXE file as it was done with the traditional codeview
                            debuggers of the DOS era.

                            This would make it available to more users and would probably make the IDE
                            a lot easier to maintain.

                            While I am less than enamoured with the Microsoft format of "Wizards",
                            code generation falls into many different categories, the couple of
                            freeware ones that I write and use are primarily project starters that are
                            handy for prototyping code. They can also be code ADD-IN types that will
                            insert a selected block of code at the current insertion point, complete
                            function generators that have replacable parameters that would write the
                            function at the end of the current open file and write the prototype in
                            the include file.

                            One of the very useful spin offs of having a normal static library
                            capacity going is the capacity to create complex objects out of component
                            parts. Where DLLs have been used for this over the last few years and
                            carry all the problems of DLL granularity and code duplication, static
                            libraries are free of problems of this type, a number of different objects
                            made of component parts can freely reuse functions in a library without
                            any code duplication whatsoever.

                            I am much of the same view as Florent that a compiler should be a core
                            capacity that is supported by static libraries.

                            Object module format is another area that is not without its problems,
                            while it would be "nice" to be able to swap MASM and PB modules around, I
                            am aware that PowerBASIC does more than ASM/C with its supported data
                            types so it would involve a reduction in capacity for PowerBASIC to
                            maintain object module compatibility with Microsoft languages.

                            I don't think this sacrifice is worth the effort, it would not bother me
                            at all if PowerBASIC produces its own object module format that fully
                            utilised its extra data types. Borland have not embraced COFF format and
                            still use the old OMF object modules so I don't see it as a problem.

                            Regards,

                            [email protected]



                            ------------------
                            hutch at movsd dot com
                            The MASM Forum - SLL Modules and PB Libraries

                            http://www.masm32.com/board/index.php?board=69.0

                            Comment

                            • Patrice Terrier
                              Member
                              • Aug 1998
                              • 4584

                              #15
                              I still have the same request for:

                              1 - Built-in COM support.
                              (Needed for advanced programming and to let us stay in the race)
                              2 - Static librairies.
                              (For the tightest code, nothing better than static libs.)


                              ------------------
                              Patrice Terrier
                              mailto[email protected][email protected]</A>
                              Patrice Terrier
                              www.zapsolution.com
                              www.objreader.com
                              Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).

                              Comment

                              • Trevor Lane
                                Member
                                • Apr 2000
                                • 264

                                #16
                                OOPs.

                                I've said it before, and I'll say it again. I like OOP. As
                                Steve Huchesson said, It doesn't have to support MFC or OWL etc.
                                But please let me use encapsulation at the most basic. Polymorphism
                                is much less important to me. I take it for granted that no-one
                                would produce an OOP compiler without Inheritance.

                                As Chris Boss points out and as I have said before. Speed of
                                development is of the essence. Be a purist if you want to but
                                you'll be out of work if you can't keep up with the boys (and girls)
                                programming in VB and Delphi.

                                I must admit I hadn't thought of it before, but Florent is
                                absolutely right. concentrate on a good functional compiler
                                and let third parties write wrapper routines. Eric does a
                                remarkable job with Perfect-Sync. Give him the tools, libraries
                                and OOP and I think he will provide a lot of excellent add-ons.

                                PB is a better compiler than VB, but I hate to say this, not
                                as good a product. IMHO. Concentrate on the core compiler and let
                                others provide quality wrappers and your product will become
                                phenomenal.

                                Sorry, you can blame Florent for getting me started again.

                                Trevor

                                ------------------

                                Comment

                                • Siamack Yousofi
                                  Member
                                  • Sep 1999
                                  • 216

                                  #17
                                  50 years ago Ferdinand Porsche took a stock standard VW Beetle and
                                  created a 20th century icon the 911.

                                  In the looks department it verges on being an ugly duckling but in
                                  performance, engineering elegance, sheer driving pleasure and quality
                                  of construction has always set the standard for others to follow.

                                  Amazingly the basic design of the 911 has not changed for the past 50 years and
                                  in engineering terms it is a truly timeless design.

                                  Now you and I can buy a 911 and having enjoyed the drive start thinking
                                  along the following lines:

                                  - It needs to seat 5 in comfort so we can take the whole family for an outing.
                                  - Automatic transmission is a must so mother in law can borrow it to go shopping.
                                  - A tow-bar is a must for the boat and in case we ever rent a U-HAUL trailer.
                                  - A bull-bar up front would kill the deer (or kangaroo) quicker without damaging the car.
                                  - Soundproofing is a must so we can listen to Mozart’s Requiem while driving.
                                  - What happened to cup-holders?
                                  - How about a small block V8 (Hutch’s favorite )?
                                  - Four-wheel drive will allow us to go off-road so let us throw it in.
                                  - Who would want a 4WD without a winch?
                                  - With 7 or 8 seats we could car pool and take neighbor’s kids to school as well.
                                  - Roof racks may one day prove useful.
                                  - The horn should play the battle hymn of the republic.
                                  - Fancy hubcaps should be standard not optional.
                                  - How about curtains on the windows for a bit of privacy?
                                  - Synthetic fur for seat covers.
                                  - Throw in a pair of fuzzy dice and we end up looking like Times Square pimps.

                                  Porsche tried to experiment with 928 and some other variants. All failed and
                                  to this date 911 remains unchallenged in engineering elegance.

                                  20 odd years ago Bob Zale took the stock standard BASIC language
                                  and created Turbo Basic. Since then the product has evolved
                                  into the 911 equivalent of compilers. The original design
                                  remains as timeless as ever. We can ask for fancy features and
                                  Powerbasic can try to incorporate them. But 10 years from now
                                  we will be back to the basics much like the 911 has.

                                  To get OOP, COM, VM, JIT, WAP, .NET, Linux, CORBA, SOAP etc. etc.
                                  We are better off buying an EDSEL for everyday driving and keep
                                  the 911 in the garage for special occasions.

                                  Siamack

                                  ------------------




                                  [This message has been edited by Siamack Yousofi (edited September 14, 2000).]

                                  Comment

                                  • Jim Karabatsos
                                    Member
                                    • Jan 1999
                                    • 107

                                    #18
                                    Wow, you get side-tracked for a few days and look what happens
                                    on this forum while you are away!

                                    This huge thread is very interesting. I'd just like to get
                                    my $0.02 in while everyone (and presumably PB) are focussed on
                                    these issues.

                                    It seems that there are two underlying threads -- the provision
                                    of information in advance of product availability and the
                                    feature set of any possible new versions.

                                    I think I side with the group that would like to see 'some'
                                    forecasts made available about upcoming products, but I certainly
                                    understand PB's reluctance to telegraph its punches to the
                                    opposition, so I guess I can (and have to) wait.

                                    On the matter of feature set, I have been giving this a lot of
                                    thought. It is clear that there are at least two groups of
                                    developers using PB -- those who are comfortable doing API-level
                                    development and really want speed and compact executables above
                                    all else, and those (primarily ex-VB types) who are looking for
                                    an alternative that produces better apps but with a coding style
                                    not unlike VB/Delphi.

                                    Having lived on both sides of that river (starting Windows
                                    development a LONG time ago under Windows 2 (!!) in C and
                                    raw API but more recently doing a lot of work in VB and Delphi)
                                    I think I can appreciate both points of view and would like
                                    to offer the following observations.

                                    If PB does not continue to produce svelte, stand-alone apps, then
                                    why would a new customer choose PB over (say) VB or Delphi?

                                    If PB does not support the latest standard system services, then
                                    how can corporate developers get PB in the door?

                                    If PB does not become easier to use, then how can its installed
                                    base grow?

                                    It seems we have some mutually exclusive requirements here, but I
                                    actually don't think that is correct. PB can address all these
                                    issues in a way that will leverage off its strengths.

                                    First, I think that it is important that PB remains focused on what
                                    it does best, and on what only it can do -- it should continue
                                    to improve the compiler. What I would like to see (and what I
                                    think are must-have features if it is going to significantly
                                    grow its market share) are:

                                    -- static libraries (LIB)
                                    -- COM
                                    -- Structured Exception Handling (SEH)

                                    SEH is a sorely missed facility and is probably overdue. I would
                                    still leave the current On Error stuff there because we don't want
                                    to break existing code, but once you have used SEH you really
                                    won't want to go back.

                                    The other two features I have listed are useful in their own right
                                    and really need compiler-level support to be done right. Static
                                    libraries will allow third-party developers to package useful
                                    code that can be included into compiled executables, while
                                    protecting their intellectual property. As long as it supports
                                    module-level linking, then I would be happy. (Of course I would
                                    PREFER it could interoperate with other compilers, but I don't
                                    see that as a must-have feature.)

                                    COM support is one of those issues that immediately raised cries
                                    of 'bloatware' and 'slow' and 'buggy'. This is really unfortunate
                                    and shows a complete lack of understanding. COM is NOT OCX support -- I
                                    personally could not care less about OCXs. COM is the ability to
                                    create and use interfaces for communication between separately-
                                    compiled modules in a standardised, compiler-independent fashion.

                                    Adding COM support to PB will NOT slow the executables down at all,
                                    and if it is not used it should have NO impact on their size
                                    either. After all, no-one would be forced to use it, not by PB
                                    anyway. The reality is that, once available, you WILL use it
                                    because a significant percentage of the Windows services are
                                    only (or much more conveniently) available via COM. MS will
                                    pretty much make it impossible to use the latest and greatest
                                    features of Windows without it. Making usage of COM easy really
                                    requires that it be built into the language with support for
                                    variants and "objects". I'd like inheritance but VB has
                                    demonstrated that it is not absolutely essential in order to
                                    support COM.

                                    Second, I think PB should work with third parties to let them
                                    provide add-ons that cater to different market segments. Invite
                                    them into an agreement that requires secrecy, and give them a
                                    heads-up on what is coming and access to beta releases. Help
                                    them (if necessary by adding facilities to the product) to produce
                                    useful addons like a neat and extensible IDE, an visual forms
                                    designer, a report engine, a database wizard -- whatever these
                                    third-parties perceive a need for. PB should NOT be investing
                                    time in these areas -- they should instead invest time in
                                    making it possible for others to build these things.

                                    And that's another reason why COM and LIB support are required --
                                    these tools should be able to integrate nicely with the core
                                    compiler. In fact, I'd write the compiler as a COM server that
                                    can compile a string or a file, and ship it with a simple
                                    command-line program that instantiates and uses it. THAT'S how
                                    you really allow third-parties to create great IDEs and add-ons.

                                    And make no mistake, PB will not be able to grow its market share
                                    without these things. I am a hacker at heart (in the original
                                    sense of the word) but the reality today is that the vast
                                    majority of developers cannot afford to use a really great
                                    compiler if the supporting tools and environment are not up to
                                    scratch.

                                    But marry PBs great performance with easy access to COM
                                    services (and the ability to write COM servers as well) and you
                                    have out-of-the-box appeal to lots of corporate developers who
                                    are not doing UI stuff but are instead doing serious server-side
                                    development for browser-based or traditional client-server apps.

                                    Make available a third-party IDE with integrated visual forms
                                    designer and you bring all the VB/Delphi developers into the
                                    fold.

                                    And as long as the core compiler still produces small, fast
                                    and stand-alone executables, the existing customer base will
                                    be happy too. And even if they SAY they don't want COM support
                                    now, you can be sure they'll be glad it is there sooner rather
                                    than later.

                                    As for Linux and CE support -- I'd like it if I could get it,
                                    but to me neither of these areas really leverage PBs expertise.

                                    CE in particular has at least 4 different CPUs that need to be
                                    supported, so a lot of PBs expertise (in X86 magic) will not
                                    translate well. The same is true of Linux but it seems to be
                                    acceptable nowadays to say 'Linux' when you really mean
                                    'Linux on X86'. I'd love to see Linux really take off, honestly
                                    I would, but I think anyone who thinks there is a broad market
                                    for commercial Linux development tools at this stage really
                                    needs to do more research.

                                    As I said, just my 2c worth.



                                    ------------------

                                    Comment

                                    • Steve Hutchesson
                                      Member
                                      • Oct 1999
                                      • 5396

                                      #19
                                      Siamack,

                                      I am glad to see you have emerged from the alligator swamp at last (waddya
                                      mean "SMALL block V8 ?").

                                      The model of the classic Porsche is a very good one, when you have the
                                      correct concept, don't mess it up. The PowerBASIC compilers are peculiar
                                      in the programming market in that they are still "can do" compilers and
                                      while there have been pressures to make it conform to the current
                                      generation of visual garbage generators, the loss of unique capacity to do
                                      most things is a price that is not worth paying.

                                      It is not a contest between ancient API grinders, mnemonic munchers and
                                      the new visual age of programming, both approaches need the same low level
                                      capacity to get the job done. COM and other similar current architectures
                                      need low level capacity to get them going, the real difference is between
                                      using someone elses pre-packaged code as against writing your own.

                                      I have always plugged for the capacity to do you own low level work as
                                      almost exclusively, the current fashion is out of date before the compiler
                                      runs out of life. Restricting programmers to the "method" approach is a
                                      formula for them buying someone elses visual garbage generator, where the
                                      capacity to "roll your own" gives the necessary flexibility to approach
                                      most things.

                                      I agree with Jim about the COM interface, it does not mean that the
                                      compiled EXE will suddenly turn into a bloated monster, just be choosy
                                      about what you want to call with it. Low level capacity like MACROs,
                                      LIBRARIES, SEH, COM interface etc... are the things that make higher level
                                      programming efficient, elegant and fast to work with.

                                      The current compiler has the capacity to do many things that some seem to
                                      think needs a new compiler to do it. Passing function parameters to DLLs
                                      in structures is current capacity.
                                      Code:
                                          MyDLL.Par1 = FunctionName
                                          MyDLL.Par2 = hWnd
                                          MyDLL.Par3 = hInstance
                                          MyDLL.Par4 = value1
                                          MyDLL.Par5 = value2
                                        
                                          retval = MyDLLcall(VatPtr(MyDLL))
                                      MyDLLcall in the DLL determines the function to call internally and
                                      despatches the parameters to that function.

                                      At the called function end within the DLL, the parameters are pulled apart
                                      with the existing capacity with PowerBASIC pointers. It certainly looks
                                      different but the capacity is already there.

                                      I have seen a design by James Fuller that is different again where the
                                      address is retrieved either singly or all at once in an array and the DLLs
                                      internal functions are called directly using CALL DWORD value USING etc..

                                      The general drift here is that you don't have to join the MICKEY MOUSE
                                      club and produce visual garbage, grunty low level compilers, well written
                                      libraries and an elegant macro capacity will do it better without the junk
                                      that is around at the moment.

                                      Complete working objects are within this capacity and minor variations
                                      using a different function call reuse any of the common code without
                                      duplication. Forget a gaggle of DLLs unless you want to write them to
                                      share code among your own applications, compiled library modules are far
                                      more efficient in terms of code size and code reuse.

                                      To use Siamack's model, I remember watching one of the Le Mans 24 hour
                                      races some years ago where the Porsche 954 outpaced the helicopter with
                                      the camera down the Mulsanne straight, thats the model I suggest that will
                                      put PowerBASIC programmers further in front, why settle for the baggage
                                      trolley at your local airport

                                      Regards,

                                      [email protected]

                                      ------------------
                                      hutch at movsd dot com
                                      The MASM Forum - SLL Modules and PB Libraries

                                      http://www.masm32.com/board/index.php?board=69.0

                                      Comment

                                      • Lance Edmonds
                                        Member
                                        • Aug 1998
                                        • 10688

                                        #20
                                        This thread is closed due to it's unwielding size... if further discussions are necessary, please open a new thread.

                                        Thanks!

                                        ------------------
                                        Lance
                                        PowerBASIC Support
                                        mailto:[email protected][email protected]</A>
                                        Lance
                                        mailto:[email protected]

                                        Comment

                                        Working...
                                        X