Announcement

Collapse
No announcement yet.

For the wish list

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • For the wish list

    For the PBDLL wish list. (PBCC also, where applicable)

    (1) Register optimization for 64-bit floats.
    80-bit works fine, but only if the entire product is PB,
    and doesn't have to meet any precision standards.

    (2) COM

    (3) DEFINES

    That's it for the "serious" list. To shoot for the moon:

    .. RAD forms designer (ala VB/Delphi)
    .. Control encapsulation architecture (COM or custom)
    .. Macros
    .. Inline function expansion
    .. Support for PDB debugger/profiling tools
    .. Compiler optimization (switchable) for P2-3-4
    .. Object architecture at least understandable to a CPP guy

    And stretching it more than a little, a "stripper" version
    that'll generate code for ring zero, with WDM templates.

    Ducking and running,
    Jim Barber


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

  • #2
    Just one wish:
    -static libraries (.lib's )

    ------------------
    E-Mail (home): mailto:[email protected][email protected]</A>
    E-Mail (work): mailto:[email protected][email protected]</A>

    Comment


    • #3
      Originally posted by Jim Barber:
      (2) COM
      Ducking and running,
      Jim Barber
      I'm curious. Why would you want COM support, when it will soon be the "legacy" component architecture?

      Josh

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


      [This message has been edited by Josh Forster (edited June 27, 2001).]

      Comment


      • #4
        Josh,

        >I'm curious. Why would you want COM support, when it
        >will soon be the "legacy" component architecture?

        My uses for COM aren't limited to controls. For example,
        I'm doing more and more DirectSound work for clients, (as
        opposed to using the MMSYSTEM API) and the only reasonable
        choice at the moment is to use C++. I can't say that my clients
        would accept PB binaries, but if PB never supports COM and
        64-bit FP register optimization, we'll never have the
        opportunity to find out, either. Ditto for the remainder
        of DirectX, and it's hard to say (with a straight face) that
        there's no money in game programming. I don't normally write
        code for games, but I have a suspicion that those that do
        won't be doing so in C# or Visual Fred. Unmanaged C++,
        yes, but why not in PB? Not today, but we'll have to see
        what the Mum Floridians have gotten around to by the time
        they get around to it.

        As for COM being a legacy item, well, just about anything
        MS does is "legacy" the instant it suits them. They've
        exposed enough COM in latter-day Windows that I find it
        unlikely it'll go away any time soon.

        My .02 ,
        Jim Barber


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

        Comment


        • #5
          Hmm, well, seeing as i havent put forward anything to the wish list yet and Ive got 2 minutes to kill, I'd love to be able to have preprocessor functions such as #PREPROCESS and #POSTPROCESS which get executed before/after compiling
          eg. sommit like this:
          Code:
          #COMPILE EXE
          #PREPROCESS SHELL "preproc.exe " & SourceBas
          #POSTPROCESS SHELL "postproc.exe " & CompiledExe
          so when you compile it, preproc.exe will be invoked first, when that finishes the compiler does its stuff, an when its all done postproc.exe gets invoked
          I'd also like to use #PREPROCESS to encrypt strings etc in the actual source code before compiling, and #POSTPROCESS to decrypt back to original


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

          Comment


          • #6
            Josh --

            > I'm curious. Why would you want COM support,
            > when it will soon be the "legacy" component
            > architecture?

            Sorry, but IMO that mindset is a direct result of Microsoft hype. And of a basic misunderstanding about .NET, which is based on the next generation of COM. It's easy to get confused by Microsoft's frequent name changes... OLE, OLE2, ActiveX, COM, COM+, DCOM... They are all just different generations of the same technology. And in many cases the differences are minor, more like 1.00 and 1.10 than 1.00 and 2.00!

            COM technology is no more "legacy" architecture than DLLs are! The entire Windows operating system -- every single core API -- is located in a DLL, and will be for many versions to come. Are DLLs "out of date" technology? Or are they just out of style? I have never been one to wear certain clothes because the current "fashion" says that I should, and I don't choose my technology that way either. I use what works for me.

            The same is true for COM. COM is a well-established, widely-used technology, and dismissing it because it isn't "the latest and greatest from Microsoft" is a very serious mistake, IMO.

            That's especially true considering that Microsoft's new paradigm is getting a less than enthusiastic reception, and many programmers are likely to delay implementing it. .NET 1.00 isn't even out of beta yet, and I'll bet that 2.00 will be significantly different. Would you prefer that PB jump directly to a technology that may be significantly changed next year, or the year after that?

            I for one would applaud LOUDLY if PowerBASIC For Windows had native support for COM.

            -- Eric

            ------------------
            Perfect Sync Development Tools
            Perfect Sync Web Site
            Contact Us: mailto:[email protected][email protected]</A>



            [This message has been edited by Eric Pearson (edited June 27, 2001).]
            "Not my circus, not my monkeys."

            Comment


            • #7
              I fully agree with Eric. Not to mention that .NET classes
              are automatically exposed as COM components, and that .NET application
              see COM components as native .NET classes.

              Making PB COM client capable would let PB developers use .NET classes seamlessly.

              A COM server capable PB version would make possible to build components
              directly usable in .NET applications.

              Philippe Monteil
              JAZZAge Software



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

              Comment


              • #8
                I absolutely agree with putting native COM support into PB. I've been using PB since it was released and the lack of native COM support has severely limited it's use in my company. I'm heavily into .NET and I see PB as a very important addition to my toolkit when it supports COM natively. PB COM DLLs would be the 'Unmanaged' high performance components in my .NET applications.

                Brent Eldstrom
                Custom Software Solutions Inc.

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

                Comment


                • #9
                  Ditto to what eric and phillipe said. COM (by whatever name) is becoming more pervasive (like it or not). More APIs are becoming COM based (e.g. directx) instead of straight DLL based with every upgrade.
                  --Don

                  ------------------
                  dickinson.basicguru.com
                  Don Dickinson
                  www.greatwebdivide.com

                  Comment


                  • #10
                    Originally posted by Eric Pearson:
                    Josh --

                    > I'm curious. Why would you want COM support,
                    > when it will soon be the "legacy" component
                    > architecture?

                    Sorry, but IMO that mindset is a direct result of Microsoft hype. And of a basic misunderstanding about .NET, which is based on the next generation of COM. It's easy to get confused by Microsoft's frequent name changes... OLE, OLE2, ActiveX, COM, COM+, DCOM... They are all just different generations of the same technology. And in many cases the differences are minor, more like 1.00 and 1.10 than 1.00 and 2.00!

                    COM technology is no more "legacy" architecture than DLLs are! The entire Windows operating system -- every single core API -- is located in a DLL, and will be for many versions to come. Are DLLs "out of date" technology? Or are they just out of style? I have never been one to wear certain clothes because the current "fashion" says that I should, and I don't choose my technology that way either. I use what works for me.

                    The same is true for COM. COM is a well-established, widely-used technology, and dismissing it because it isn't "the latest and greatest from Microsoft" is a very serious mistake, IMO.

                    That's especially true considering that Microsoft's new paradigm is getting a less than enthusiastic reception, and many programmers are likely to delay implementing it. .NET 1.00 isn't even out of beta yet, and I'll bet that 2.00 will be significantly different. Would you prefer that PB jump directly to a technology that may be significantly changed next year, or the year after that?

                    I for one would applaud LOUDLY if PowerBASIC For Windows had native support for COM.

                    -- Eric
                    No, COM components are more closely related to VCL components than .NET components. Type libaries are
                    history. .NET components store the "header" information as metadata. .NET components are "compiled"
                    into MSIL, not machine code. You can have multiple versions of a particular .NET assembly on one machine.
                    .NET assemblies can be simply copied and used. COM components need to be registered. Does this sound
                    like they are similar to you? It is like saying a Volkswagen Bug and the Porsche 911 are similar because
                    they are "German" cars.

                    My point was why would PowerBASIC put time and money into a technology that is soon to go the way of the
                    VBX? To me, the money and effort would be better spent in other areas. If you want to believe COM is not
                    going away, that is your choice. However, it will. How soon? No one knows.


                    Josh




                    [This message has been edited by Josh Forster (edited June 28, 2001).]

                    Comment


                    • #11
                      Originally posted by Philippe Monteil:
                      I fully agree with Eric. Not to mention that .NET classes
                      are automatically exposed as COM components, and that .NET application
                      see COM components as native .NET classes.

                      Making PB COM client capable would let PB developers use .NET classes seamlessly.

                      A COM server capable PB version would make possible to build components
                      directly usable in .NET applications.

                      Philippe Monteil
                      JAZZAge Software

                      As of Beta 1, .NET classes are NOT automatically exposed as COM components. You must use an export tool or the RegAsm
                      utility to allow it to be used. COM components are NOT automatically "seen" as .NET classes. A wrapper
                      must be created by either an import tool or the TlbImp utility.


                      Josh

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


                      [This message has been edited by Josh Forster (edited June 28, 2001).]

                      Comment


                      • #12
                        COM isn't going away for many years, as Windows and MS's applications are
                        COM through-and-through. I doubt that there will be much new development
                        in COM, but it will be here for a long time.



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

                        Comment


                        • #13
                          Originally posted by Mark Newman:
                          COM isn't going away for many years, as Windows and MS's applications are
                          COM through-and-through. I doubt that there will be much new development
                          in COM, but it will be here for a long time.
                          Yes! My point exactly. The world will not drop COM as .NET is released. Developers will still use COM components. However, the smart business and component vendors will do all new development in .NET. To build NEW COM components makes no sense when the market will demand .NET components. However, this is not an issue if maximizing your ROI is not a priority.

                          Josh



                          [This message has been edited by Josh Forster (edited June 28, 2001).]

                          Comment


                          • #14
                            <<As of Beta 1, .NET classes are NOT automatically exposed as COM components. You must use an export tool or the RegAsm
                            <<utility to allow it to be used. COM components are NOT automatically "seen" as .NET classes. A wrapper
                            <<must be created by either an import tool or the TlbImp utility.
                            But at least those processes are possible and made pretty straightforward,
                            which is more than enough to me.

                            Also, lots of software resources, either exposed by the OS, by widely used commercial
                            products (like the Office suite), by third-party component providers
                            take the form of COM components, therefore fully justifying the need
                            for the best possible COM support by PB.

                            Philippe



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

                            Comment


                            • #15
                              Originally posted by Philippe Monteil:
                              <<As of Beta 1, .NET classes are NOT automatically exposed as COM components. You must use an export tool or the RegAsm
                              <<utility to allow it to be used. COM components are NOT automatically "seen" as .NET classes. A wrapper
                              <<must be created by either an import tool or the TlbImp utility.
                              But at least those processes are possible and made pretty straightforward,
                              which is more than enough to me.

                              Also, lots of software resources, either exposed by the OS, by widely used commercial
                              products (like the Office suite), by third-party component providers
                              take the form of COM components, therefore fully justifying the need
                              for the best possible COM support by PB.

                              Philippe


                              Philippe,

                              PB using COM components would be a useful feature for some developers.
                              I cannot see the business justification for putting time & money into COM
                              component creation. From what I have heard, JAZZAge is great for that.

                              Josh



                              [This message has been edited by Josh Forster (edited June 28, 2001).]

                              Comment


                              • #16
                                Josh,

                                I didn't word my last post too clearly - to be more precise, I don't think
                                that there will be much new COM-platform development by Microsoft.
                                I think that 3rd party COM development will continue for some time, as quite
                                a large developer base is very familiar and comfortable with COM.

                                I think it's too early to make a wholesale jump to .NET; it's only in beta and
                                remember, nothing from MS is any good until it hits Version 3. In the long
                                run, .NET might turn out to be a viable platform to program against, or it might
                                turn out to be another Microsoft Bob.


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

                                [This message has been edited by Mark Newman (edited June 28, 2001).]
                                Mark Newman

                                Comment


                                • #17
                                  It's not necessary to make big efforts to build something like ATL wizard.
                                  I mean that this (external) tool will generate PB source code.
                                  Of course, classic COM is not ActiveX, but it's enough, for example, to build shell extentions.


                                  ------------------
                                  E-MAIL: [email protected]

                                  Comment


                                  • #18
                                    Josh --

                                    You've obviously done a lot of reading about .NET. And you've obviously believed every word. (Sorry, couldn't resist. )

                                    > My point was why would PowerBASIC put time and money
                                    > into a technology that is soon to go the way of the VBX?

                                    Honestly, I think the only place we really disagree is the meaning of the word "soon". I mean, someday "soon" every computer will have a 64-bit processor. Should PowerBASIC give up on 32-bit development because there is no real future in it?

                                    COM isn't going away "soon" just because Microsoft says so. It will fade away when it is no longer useful.

                                    Yes, probably at some point COM will be "legacy" technology and .NET will dominate. But today it is the most widely accepted component architecture.

                                    And most of us need to make a living today, so if PowerBASIC adds support for COM, we will use it. Why should PB ignore a market that they know exists, in favor of betting the farm on a new paradigm that is still in beta?

                                    -- Eric

                                    ------------------
                                    Perfect Sync Development Tools
                                    Perfect Sync Web Site
                                    Contact Us: mailto:[email protected][email protected]</A>



                                    [This message has been edited by Eric Pearson (edited June 28, 2001).]
                                    "Not my circus, not my monkeys."

                                    Comment


                                    • #19
                                      Josh,

                                      <<
                                      PB using COM components would be a useful feature for some developers.
                                      I cannot see the business justification for putting time & money into COM
                                      component creation. From what I have heard, JAZZAge is great for that.
                                      >>
                                      Our products for PB, and most of them were released several years ago,
                                      already cover almost all the aspects of COM programming in PB on both
                                      the client and server sides. So I tend to agree with you that it is
                                      somewhat late to start adding support for COM to PB now... We will
                                      see what the future versions of PB will add to what the JA products
                                      have been offering for sometime now

                                      Philippe



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

                                      Comment

                                      Working...
                                      X