Announcement

Collapse
No announcement yet.

OOP, be realistic

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

  • OOP, be realistic

    PowerBasic Inc is most likely working on PB Linux right now.

    Bob Zale said:

    "PowerBASIC for Linux is real. PowerBASIC for Linux is under
    development. We've said it before, but you can consider
    it "set in concrete"."

    Do you see Bob Zale talking about OOP? No. Does Bob Zale
    even like OOP? I do not know.

    What about COM support? All that we know from PB INC, is that
    "if" they do add COM support, they will take their time and
    do it right.

    PowerBasic is a company that boasts of having the worlds fastest
    compiler. Their goal is to blow the doors off of C compilers,
    and they do. They hand craft millions of lines of assemby code
    to make this super small, fast, compiler that fits on a single
    floppy. They do not like, maybe even hate, feature bloat at
    the price of speed, overhead, and size. PowerBasic Inc, would
    not toss that all away to chase the latest insane notion that
    .NET or OOP is the cure-all.

    There are many OOP languages out there to choose from. Pick one
    and OOP away. It is unrealist to expect PB to be turned into
    a clone of Delphi or do everything just like C++.

    Work with the tool you have in your hand right now. If it is
    not the right tool, go find the right one. You can do much
    more now, with existing tools than ones that are just dreamed
    up from vapor.

    Tim



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

  • #2
    Tim,

    I guess I am of much the same disposition as you are in terms my choice of
    the compiler I use and for much the same reason, performance measured in
    terms of both size and speed.

    OOP appears to have many forms of implementation, some good, some bad and
    some that are worse and it is this distinction that I find interesting and
    probably worth pursuing.

    If you added together all of the downside characteristics of the range of
    suggestions that have been made to change PowerBASIC, you would end up
    with an oversized visual garbage generator with uninteligible notation
    that was toothless in its capacity, slow in its execution and required a
    large runtime to make it run.

    This sum total is the antithesis of what PowerBASIC actually is, a high
    performance low level compiler. Now while I can happily keep writing
    procedural based code as it delivers in terms of speed and size, I am not
    directly opposed to the fundamental concept of programming in objects. Its
    something that we in fact all do using the procedural model.

    I have been following the discussion between Florent and Peter with some
    interest as I would like to see what are the necessary requirements for
    programmers to be able to implement an efficient form of OOP in a low
    level compiler like PowerBASIC.

    I am already familiar with both MACRO and LIBRARY capacity and in
    conjunction they can deliver simplified code that is easy to use, powerful
    and at no penalty in performance terms. I have enough stuff written in
    MASM now to be able to drop small toys in a short time using macros and
    libraries. Put this into a language that is as fast and comprehensive as
    PowerBASIC in low level power terms and there will be a corresponding
    improvement in code throughput.

    Where I have the spare time, I sometimes experiment with "other"
    architecture and it is here where I see the advantage of adding low level
    capacity if it allows the programmer to be original and do things in
    different ways.

    The bottom line for me in a compiler is being able to write what I want in
    it and if there is some advantage in being able to construct an
    architecture that will do something useful, I am all for it, I draw the
    line when a compiler restricts me to "method" style programming within
    objects that I can't change and can't fix.

    I don't believe this will ever happen in PowerBASIC as I doubt Bob Zale
    would be willing to throw away so much work to implement such a bad idea
    for so little result. I see the potential for OOP coming from additional
    low level capacity, not from following the same path that has lead to a
    generation of garbage.

    Regards,

    [email protected]

    ------------------
    hutch at movsd dot com
    The MASM Forum

    www.masm32.com

    Comment


    • #3
      That is a fantastic idea. . . Add OOP as an addon to the compiler,
      without breaking / bloating the compiler.

      Maybe, A preprocessor that rewrites the code before sending to to
      the compiler.

      As long as we can keep the small, fast, lean compiler I have
      no problem with your idea for PB OOP.

      Tim


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

      Comment


      • #4
        Tim, that's what we've been saying all along

        Cheers

        Florent

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

        Comment


        • #5
          Just to make it clear where I stand on the oop issue.

          I DO NOT want PB to implement any OOP functionality into the compiler
          other than MACRO's and static libraries. As I have metioned in the past
          I am an encapsulation freak. I enjoy working at the low levels the compiler
          provides so I can implement objects in MY OWN way.

          If OOP is that important to you as a PB programmer do it yourself or use
          one of Philippe Monteil's Jazz Age products.

          James



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

          Comment


          • #6
            The downside with everyone implementing their own objects
            in their own way is that it makes it hard to re-use objects
            written by others...

            Cheers

            Florent

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

            Comment


            • #7

              Implemented maybe in the form of an OOP library (engine) DLL (now) or a static module (maybe in the future), with OOP-Style functions, such as oAssign("MYOBJECT.MYPROPERTY=MYVALUE") or something to that effect.

              Personally, I hate OOP, - It reminds me too much of VB, DELPHI and more importantly BLOAT, in some circumstances this may not be the case, but in most it is.

              Oh, and please Stephane, no more postings!

              Regards,


              ------------------
              Kev G Peel
              KGP Software, Bridgwater, UK.
              www.go.to/kgpsoftware
              kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

              Comment


              • #8
                Well, Visual Basic 5.0 takes Basic code and converts it all
                to C++, then it starts the C++ compiler and makes the EXE.

                There is no reason why you guys can't do the same and make up
                your own version of Basic with OOP that starts a converter that
                converts it all into PowerBasic Code and calls to your Runtime
                package. Then PowerBasic does the rest of the work.

                I guess that is what you guys had in mind already. . .

                Well that sounds fine.

                Tim





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

                Comment


                • #9

                  I use PB because it is a Richer language than VB and it
                  doesn't require a bloated runtime and dozens of OCXs. PB's
                  most significant advantage is also the size of the executables
                  it produces, which rivals even C compilers.

                  PB is rich in features not found in other languages (Basic or
                  non-Basic). Things, like pointers, AsciiZ, array functions,
                  powerful string functions, communications, etc. The name
                  PowerBasic tells it all !

                  Yet, for PowerBasic to compete in the "dog eat dog" world of
                  software development (compiler market), they need to keep
                  "pushing the envelope" in their compiler. This doesn't mean
                  becoming a clone of VB. It means making the language richer
                  in features and offering more "Raw" power to developers.

                  Many suggestions have been made, like adding COM support,
                  OOP, etc. If PowerBasic can impliment some of these features
                  their own way then they continue to make the language
                  richer. I doubt that if PowerBasic decided to add a feature, they
                  would bloat the compiler. If they felt they could impliment a
                  new advanced feature and still keep the code size down and the
                  speed fast, I can't imagine any sound reason to say, NO to such
                  a feature.

                  Microsoft and Borland are not standing still. Neither should
                  PowerBasic. The difference between PowerBasic and other companies
                  is not "whether" they will add new powerful features, but that
                  they only want to "do it right". With that I am in absolute
                  agreement.

                  So rather than "trash" suggestions like COM or OOP, it is better
                  to do what Dave Navaro suggested and that is give constructive
                  suggestions in "how" to impliment these features in a way that
                  works in harmony with PBs own goal of "small", "fast" and "solid".



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

                  Comment


                  • #10
                    Below is a full WinMain and startup code using the MACRO capacity from
                    MASM. This code was cut and pasted out of one of my MASM test pieces and
                    works fine. It demonstrates the lowest level of encapsulation that is
                    possible using text replacement at the pre-processor level. This style of
                    encapsulation involves ZERO loss of size or performance as in its fully
                    expanded form, it is still minimum procedural programming.

                    PowerBASIC is well suited to use this style of encapsulation as it is a
                    high performance low level compiler that can produce the minimum size code
                    necessary to make this style of encapsulation both efficient in speed and
                    size terms.

                    Among the advantages in using MACRO expansion is that you can hide very
                    complicated and messy looking low level code within a single MACRO call.
                    This allows you in turn to optimise the code within the macro with little
                    need to keep it readable as you only need to get it right once.

                    MACRO expansion is also very useful where you ave to handle ugly repetitive
                    coding of the type that is used in system toolbars.

                    This is the toolbar code from my MASM code generator and it uses 2 macros
                    to handle the option of blanks or buttons.

                    Code:
                        TBblank
                        TBbutton  0,  50
                        TBbutton  1,  51
                        TBbutton  2,  52
                        TBblank
                        TBbutton  3,  53
                        TBbutton  4,  54
                        TBbutton  5,  55
                        TBblank
                        TBbutton  6,  56
                        TBbutton  7,  57
                        TBbutton  8,  58
                    This is very simple and fast code to use but it still is minimum API style
                    code below it that has no performance penalty from this style of
                    encapsulation.

                    Regards,

                    [email protected]

                    Code:
                      ; #########################################################################
                      
                          Do_Model .486
                      
                          include abstract.inc     ; local includes for this file
                      
                      ; #########################################################################
                      
                          Do_Init
                      
                      ; #########################################################################
                      
                          Do_WinMain
                      
                          invoke LoadIcon,hInst,500    ; icon ID
                          Do_RetVal hIcon
                      
                          szText szClassName,"Abstract_Class"
                      
                          mov wc.cbSize,         sizeof WNDCLASSEX
                          mov wc.style,          CS_HREDRAW or CS_VREDRAW \
                                                 or CS_BYTEALIGNWINDOW
                          mov wc.lpfnWndProc,    offset WndProc
                          mov wc.cbClsExtra,     NULL
                          mov wc.cbWndExtra,     NULL
                          m2m wc.hInstance,      hInst
                          mov wc.hbrBackground,  COLOR_BTNFACE+1
                          mov wc.lpszMenuName,   NULL
                          mov wc.lpszClassName,  offset szClassName
                          m2m wc.hIcon,          hIcon
                            invoke LoadCursor,NULL,IDC_ARROW
                          mov wc.hCursor,        eax
                          m2m wc.hIconSm,        hIcon
                      
                          invoke RegisterClassEx, ADDR wc
                      
                          Do_CentreWindow 550,400
                      
                          invoke CreateWindowEx,WS_EX_LEFT,
                                                ADDR szClassName,
                                                ADDR szDisplayName,
                                                WS_OVERLAPPEDWINDOW,
                                                Wtx,Wty,Wwd,Wht,
                                                NULL,NULL,
                                                hInst,NULL
                          Do_RetVal hWnd
                      
                          Do_MenuLoad hInstance,hWnd,600
                          Do_WindowDisplay hWnd
                      
                          Do_mlStart msg
                          Do_mlEnd msg
                      
                          Do_EndWinMain
                      
                      ; #########################################################################
                    ------------------
                    hutch at movsd dot com
                    The MASM Forum

                    www.masm32.com

                    Comment


                    • #11
                      My $0.02 on a couple of points:

                      Tim,

                      What about COM support? All that we know from PB INC, is that "if" they do add COM support, they will take their time and do it right.
                      Nobody wants VB in PB. But, the future of COM is definitely not bright. Sorry, but the .NET is the new way to do things in the MS world. Is that the only way? Is that the best way? Of course not. But it is the new way.

                      PowerBasic Inc, would not toss that all away to chase the latest insane notion that .NET or OOP is the cure-all.
                      Why is that "insane?" I have to admit, the comments of OOP being "bloated" and "insane" have to stop unless you're going to back up your statement with some concrete examples.


                      James,

                      I enjoy working at the low levels the compiler provides so I can implement objects in MY OWN way.
                      Please read the first chapter of Box's "Essential COM" book and you'll realize that this rips away at the idea of interoperability. If you do your objects your way and I do them my way, how do the two worlds meet?


                      Kev,

                      Personally, I hate OOP, - It reminds me too much of VB, DELPHI and more importantly BLOAT, in some circumstances this may not be the case, but in most it is.
                      VB isn't OOP. It's COM-based. I would strongly recommend reading as many hardcore COM books as you can, along with some OO books. The differences are there.

                      Again, the word "bloat."


                      Tim,

                      Well, Visual Basic 5.0 takes Basic code and converts it all to C++, then it starts the C++ compiler and makes the EXE.
                      This is news to me. I've watched directories where VB has built my application, and I've never seen .cpp or .h files being created. VB, AFAIK, does not create C++ code. VC++ and VB do share the same compiler, C2.EXE, but VB does not pull a PowerBuilder and create C++ code.


                      To all,

                      I like PB for the ability to create small, tight executable files. There's no doubt in anyone's mind that PB reigns in the Windows compiler world. And, like it or not, if it wants to stay in the Windows world, it will have to consider playing in the .NET world as well.

                      Regards,

                      Jason

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

                      Comment


                      • #12
                        Jason,

                        Like it or not, the term "bloat" is well applied to the current generation
                        of visual garbage, there are clear and objective measures on what a minimum
                        file size is and when it not just a bit bigger but much bigger, ther is
                        something radically wrong with it. Bloat conjures up images of swollen,
                        sick and slow, an image that is well pointed at software that takes more
                        that 100k to do a hello world.

                        Lets look at the track record of Microsoft blunders, did you waste the disk
                        space, time and brainpower on OS2 code back in the early nineties ? What about
                        the be all and and all in DDE for apps that "talked" to each other. Then came
                        the multiport fantasy, "can you port it to a MAC ?".

                        You have already mentioned the Component Object Model, I have a friend in New York
                        who has decyphered the COM interface in assembler and it is an extremely complicated
                        proprietry interface designed to be ported to other platforms, shame no-one in the
                        unix, linux, mac, mips or other hardware platforms were willing to assist Microsoft
                        in migrating there code there.

                        Why will .NET fare any better, Microsoft flopped in the MSN attempt to control the
                        internet and again in the browser war that has lead to them getting into trouble
                        with the US Dept of Justice.

                        I get spammed about every week with the MSDN flash emails from Microsoft so I get
                        to see much of what is floating through the Microsoft camp over time, I am all
                        in favour of good technology but I agree with the idea that following every whim
                        of Microsoft vapourware is a formula for failure.

                        Now related to some of the other coments,

                        I very much agree with the capacity to be original as much that is written will
                        never be pointed anywhere else than where its used,

                        =================================================================================
                        If you do your objects your way and I do them my way, how do the two worlds meet?
                        =================================================================================

                        Who says they have to ?

                        =================================================================================
                        This is news to me. I've watched directories where VB has built my
                        application, and I've never seen .cpp or .h files being created. VB,
                        AFAIK, does not create C++ code. VC++ and VB do share the same compiler,
                        C2.EXE, but VB does not pull a PowerBuilder and create C++ code.
                        =================================================================================

                        Perhaps you have not bothered to look at the Microsoft linker in Visual Basic 5,

                        Microsoft (R) 32-Bit Incremental Linker Version 4.20.6164
                        Copyright (C) Microsoft Corp 1992-1996. All rights reserved.

                        Its a Microsoft COFF generation linker that will build things from VxDs to DLLs
                        to C++ EXE files using standard Microsoft format object files. VB's capacity to
                        build what it calls native code EXE files is based on the same technology as the
                        other Microsoft languages so while there is no need to convert the files to CPP
                        extensions, the technology is the same.

                        =================================================================================
                        Why is that "insane?" I have to admit, the comments of OOP being "bloated"
                        and "insane" have to stop unless you're going to back up your statement
                        with some concrete examples.
                        =================================================================================

                        Would the compile size of PowerBASIC EXE files serve as concrete examples ?
                        I suggest that they do and that the call of "insane" "bloatware" is in fact
                        a fair statement of the difference.

                        Regards,

                        [email protected]

                        ------------------
                        hutch at movsd dot com
                        The MASM Forum

                        www.masm32.com

                        Comment


                        • #13
                          If you compile Visual Basic 5/6 into PCode you get pure Pcode.
                          . . . but if you make a real EXE file it converts the Basic
                          Code into C++ code in temp files that C2.EXE (The C++ compiler)
                          compiles into an EXE.

                          Visual Basic first outputs temp files that are the same as the
                          C++ temp files that are produced by the first pass of the
                          Visual C++ compiler. It is a Basic To C++ first pass temp
                          file conversion. C2.EXE is a second pass C++ compiler.

                          This is very common knowledge among Visual Basic programmers.
                          Here are some web sites you can read about it on:
                          http://www.devx.com/upload/free/feat...199/jc1199.asp
                          http://www.vb-zone.com/upload/free/f...mckinney2a.asp

                          .NET is not something PB should be mixed up in. PB does not
                          need to be held hostage to a massive MS Common Runtime.
                          That is what .NET is, A massive common run time and C#.
                          Great at what it does, but it is a Microsoft thing, it is
                          the Microsoft way, not the PowerBasic way.

                          PB users should be looking at XML and SOAP. These would be
                          nice 3rd party addons for PowerBasic.


                          [This message has been edited by Tim Wisseman (edited September 24, 2000).]

                          Comment


                          • #14
                            OOPS!

                            ------------------
                            mailto:[email protected][email protected]</A>
                            www.basicguru.com/zijlema/

                            Egbert Zijlema, journalist and programmer (zijlema at basicguru dot eu)
                            http://zijlema.basicguru.eu
                            *** Opinions expressed here are not necessarily untrue ***

                            Comment


                            • #15
                              Some thoughts:

                              XML/SOAP: I second Tim's idea of adding support for XML and SOAP
                              to PB. This would allow PB to tie into much of the "new world
                              order", as it were.

                              Bloat: We have to get past the "bloat" monster. A VB/Delphi/VGG
                              (Steve H.'s favorite ) program that weighs in at 250K + a
                              runtime is not necessarily a slow, ponderous beast. I have a
                              couple of ~250K VB6 programs that I ported to PB6 for expected
                              speed improvements. The PB versions were much smaller, but only
                              one was visibly faster.

                              COM: Yes, COM is a complicated machine under the hood and I don't
                              understand all the internals, and I won't mourn it's passing in
                              favor of NET (if and when, but the previews from MS are a lot
                              more than vapor), but it's pretty stable now, relatively easy to
                              use at a high level and makes possible some pretty powerful apps.

                              OOP: I'm not a huge fan of OOP, but there are times when it's very
                              useful and efficient (in development time) and it's nice to have
                              the option available. Will adding it to PB increase the size of
                              compiler and slow it down? Yes! So What! (Blasphemy! )

                              Seriously, I don't care if the PB compiler is 20K or 2MB or 20%
                              slower, as long as it produces the good stuff it always has.


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

                              [This message has been edited by Mark Newman (edited September 25, 2000).]
                              Mark Newman

                              Comment


                              • #16
                                Mark;

                                I have a couple of ~250K VB6 programs that I ported to PB6 for expected
                                speed improvements. The PB versions were much smaller, but only
                                one was visibly faster.
                                When Visual Basic was generating only PCode EXEs (version 4.0 and before)
                                , PowerBasic had a significant advantage in speed and it was
                                10 to 20 times faster.

                                With Visual Basic 5.0 (and beyond), VB is a front end to a C
                                compiler when you generate "Native Code" which makes VB 5.0 (and 6.0)
                                10 to 20 times faster than VB 4.0. This means that PB has lost
                                a major advantage of speed, since VB is catching up to PB in the
                                speed catagory.

                                This means that PBs greatest advantage today is not speed, but size
                                of apps and the "Richness" of the Language (see my comments above).

                                Because Microsoft is "playing catch up" to PB in some areas (like
                                speed), this means PB needs to keep "pushing the envelop" when it
                                comes to features and "raw power".

                                For the same reason that many "commercial" apps are written in C and
                                not VB (small size, more power and control, closer to the API), PB
                                needs to be the alternative for Basic programmers wanting more power.
                                Rather than force Basic programmers to use C, they can use PB instead
                                of VB.

                                This would mean that PB needs to stay on the leading edge when it
                                comes to "accessing" the core of Windows. As Windows relies more
                                on COM, then likely PB should add some COM support. As other
                                technologies are added to the "core" of the Windows operating system,
                                PB needs to give programmers access to those technologies.

                                If you want to compare PB to any language it should be C !

                                PB should continue to offer all the advantages of C, but in a
                                Basic compiler.



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

                                Comment


                                • #17
                                  Steve,

                                  Who says they (objects) have to?
                                  Anybody involved with interoperability issues. If I had to write that layer every time I met up with a developer who decides to implement OO differently, I wouldn't be happy. There is a reason to doing things in a standard way - it makes interop easy. True, some apps are stand-alones, but all it takes is one person to say, "Hey, can we include some of this into our app?"

                                  Would the compile size of PowerBASIC EXE files serve as concrete examples ?
                                  I suggest that they do and that the call of "insane" "bloatware" is in fact
                                  a fair statement of the difference.
                                  I would never say that PB is bloated, nor that other technologies have not address bloat issues as hard as PB has. What I am saying is that OO does not necessarily equal bloat.

                                  Perhaps you have not bothered to look at the Microsoft linker in Visual Basic 5,
                                  I have. I'm not arguing that VC++ and VB share a lot when it comes down to the compiler. I am arguing that VB generates pure C++ code.

                                  Which leads to another issue...


                                  If you compile Visual Basic 5/6 into PCode you get pure Pcode.
                                  . . . but if you make a real EXE file it converts the Basic
                                  Code into C++ code in temp files that C2.EXE (The C++ compiler)
                                  compiles into an EXE.
                                  This isn't true, and the article (DevX's) doesn't say that. Yes, VB creates the necessary files for the C2.EXE. But my contention is that VB doesn't generate C++ files. I have never found anyone who has hooked the compile process and found C++ files.

                                  Take a look (if you really want to ) at what Eiffel or PowerBuilder does. They generate C/C++ files (at least PBuilder 5 did - I know Eiffel does because they flat-out admit it).

                                  AFAIK, the article is about hooking the compile process such that you can inject your own OBJ files created with tools that support other languages. This does not mean that VB creates .cpp files. In fact, there's no reason for VB to create C++ files. Eiffel does it only for portability issues - it can use C++ compilers for any OS to compile its' generated C++ code. VB doesn't have that need; it's far easier for VB to simply generate the OBJ files and let the final pass create the EXE.

                                  If someone can show me where VB creates C++ files (which was the original contention, not that VB and VC++ generate the same file format for the final link.exe, I will be more than happy to recind my statement and cower in a corner for a while .

                                  Regards,

                                  Jason


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

                                  Comment


                                  • #18
                                    I am looking at the temp files that VB 5 is making in my
                                    C:\windows\temp\ directory.
                                    VB061310GL

                                    I see that the code (In plain text) is making calls to:
                                    __vbaFreeStr
                                    __vbaStrMove
                                    __vbaObjSetAddref
                                    __vbaFreeObj
                                    __vbaStrCopy
                                    __vbaFreeStrList
                                    __vbaStrCmp
                                    __vbaLenBstr
                                    __vbaHresultCheckObj

                                    No, it file is not a formated C++ file that you can play with,
                                    it is a mostly non human readible mess of pcode.

                                    It is in the very same format that the first pass of the Visual
                                    C++ compiler produces.

                                    To turn this into an EXE you need a second pass C++ compiler.

                                    A second pass C++ compiler is making the OBJ files for the
                                    linker. If a second pass C++ compiler is making the OBJ files
                                    what do you think that means? Think about it.


                                    [This message has been edited by Tim Wisseman (edited September 25, 2000).]

                                    Comment


                                    • #19
                                      Tim,

                                      All of the __vbaXXX methods you found are calls to the VB run-time DLL, so I'm not suprised that you found them. In fact, you could call them from VB or PB directly if you wanted to, but they are undocumented so that's a fun proposition .

                                      No, it file is not a formated C++ file that you can play with,
                                      it is a mostly non human readible mess of pcode.
                                      So is it a C++ file? That's my real question. All I'm trying to find out is if those files are generated in C++. So far, from what you said it's just a weird form of p-code.

                                      A second pass C++ compiler is making the OBJ files for the
                                      linker. If a second pass C++ compiler is making the OBJ files
                                      what do you think that means? Think about it.
                                      I don't know. All I do know is that the first-pass compiler is generating a file for the second-pass compiler. If it's C code, then that's fine. If it's a file format that is written for the VC++ compilers, that's different to me.

                                      Again, Eiffel creates C files to generate the executable. All I'm asking is for someone to show me the output from a VB compilation process that has semi-colons . If it does, that's news to me and I'll stand corrected.

                                      Thanks,

                                      Jason

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


                                      [This message has been edited by Jason Bock (edited September 25, 2000).]

                                      Comment


                                      • #20
                                        The files are not for human eyes, there are no semi-colons
                                        there are no CPP files. It is code for the second pass C++
                                        compiler. VB does not make OBJ files, the C++ compiler makes
                                        the OBJ files. . . and the linker links them.

                                        The temp files are in something that is called by microsoft
                                        “intermediate language”.

                                        The second pass C++ compiler compiles intermediate language.

                                        "If you are familiar with Visual C++, you know C2.EXE
                                        is the code generator that produces the actual machine code."
                                        --- MSJ
                                        http://www.microsoft.com/msj/default...yer0698top.htm
                                        http://msdn.microsoft.com/library/bo...vb5/Ch08_4.htm


                                        Tim


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

                                        Comment

                                        Working...
                                        X