BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  DLL versus Lib if you want to link into single exe image          BorlandTalk.com Forum Index -> C++ Builder (IDE) View previous topic :: View next topic   Author Message Randall Parker Guest Posted: Tue Jul 05, 2005 8:02 pm    Post subject: DLL versus Lib if you want to link into single exe image Using BCB v6 sp4. One can link a dlll right into the executable image, right? What is the advantage of linking to a lib file versus a dll file if the intent is to link everything statically into a single exe? Also, I'm looking at some of my BCB projects and I see in the Project | Options | Directories/Conditionals | Library Path that none of the library paths call out specific lib or dll files. Is it not allowed to specify an exact lib file name as part of a library path entry? If one wants to use a dll then its path belongs on the library path? With or without the file name? Back to top Bruce Salzman Guest Posted: Tue Jul 05, 2005 8:28 pm    Post subject: Re: DLL versus Lib if you want to link into single exe image "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in message news:42cae740$1 (AT) newsgroups (DOT) borland.com... Quote: Using BCB v6 sp4. One can link a dlll right into the executable image, right? Nope. Quote: What is the advantage of linking to a lib file versus a dll file if the intent is to link everything statically into a single exe? A static library is really a bunch of obj files packaged together and linked into your exe. A dynamic library (DLL) is loaded by Windows. The DLL's lib file tells the linker how your exe will link to it on the fly. Quote: Also, I'm looking at some of my BCB projects and I see in the Project | Options | Directories/Conditionals | Library Path that none of the library paths call out specific lib or dll files. Is it not allowed to specify an exact lib file name as part of a library path entry? They are paths (folders) where the linker looks when doing its job. Quote: If one wants to use a dll then its path belongs on the library path? With or without the file name? DLLs are loaded by Windows. Look at the LoadLibrary function in the SDK to see where is will search for a DLL. HTH, Bruce Back to top Dennis Jones Guest Posted: Tue Jul 05, 2005 8:52 pm    Post subject: Re: DLL versus Lib if you want to link into single exe image "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in message news:42cae740$1 (AT) newsgroups (DOT) borland.com... Quote: Using BCB v6 sp4. One can link a dlll right into the executable image, right? What is the advantage of linking to a lib file versus a dll file if the intent is to link everything statically into a single exe? Randall, I think you are mis-using terminology here. A DLL is never "linked" into an EXE. Linking a DLL happens dynamically (hence the name!) at runtime and is performed by the operating system. If your goal is to avoid shipping a separate DLL file with your EXE, your choices are: 1) Link in a static LIB instead of using a DLL (which still requires linking in an import LIB), or 2) Embed the DLL in the EXE as a Windows resource, then use special code to extract it for use by the EXE. (tricky, but do-able) The advantages to linking with a static LIB are: 1) It is not necessary to ship an extra file with your app. Some would probably argue that it is actually more advantageous to use a DLL instead of a static LIB because a DLL can be shared by multiple applications, thereby potentially reducing memory usage. Others prefer static linking to avoid "DLL Hell". 2) When you link to a static library, only the functions your EXE actually needs are linked into your EXE (as opposed to an entire DLL getting loaded into memory, when you may only need one function from the DLL). 3) You never have to worry if the version of the DLL matches that which is required by your EXE. Quote: Also, I'm looking at some of my BCB projects and I see in the Project | Options | Directories/Conditionals | Library Path that none of the library paths call out specific lib or dll files. Is it not allowed to specify an exact lib file name as part of a library path entry? The library path specifies where the linker should look for library files (static LIB's, import LIB's, and in some cases OBJ files) at link time. It is not used to specify file names. Quote: If one wants to use a dll then its path belongs on the library path? No. If you want to use a DLL, the path to its *import LIB* must be specified in the library path (which is used by the linker at link-time). When the application executes, then the DLL must be found somewhere in the system path (at run-time). Quote: With or without the file name? The path to the import library is just a location specification, not a file name. The file name is given when you add the import library to your project. Strangely, even though you specify a full path to a library file when you add it to your project, the IDE doesn't seem to be able to find it unless its location is specified in the library path. Pretty dumb if you asked me. - Dennis Back to top Randall Parker Guest Posted: Tue Jul 05, 2005 9:24 pm    Post subject: Re: DLL versus Lib if you want to link into single exe image Dennis, Thanks for all the useful info. It is clearer now. Well, it looks like the Apache Xerces XML project builds a DLL and the import LIB. What I want instead is the static lib. So: 1) Can I make a static lib from a combination of the import lib and the DLL? or 2) Do I need to create a project that makes the static lib? If so then: A) Can I convert their DLL project into a LIB project or B) Do I need to create a new LIB project that uses the same source files? Dennis Jones wrote: Quote: Randall, I think you are mis-using terminology here. A DLL is never "linked" into an EXE. Linking a DLL happens dynamically (hence the name!) at runtime and is performed by the operating system. If your goal is to avoid shipping a separate DLL file with your EXE, your choices are: 1) Link in a static LIB instead of using a DLL (which still requires linking in an import LIB), or 2) Embed the DLL in the EXE as a Windows resource, then use special code to extract it for use by the EXE. (tricky, but do-able) The advantages to linking with a static LIB are: 1) It is not necessary to ship an extra file with your app. Some would probably argue that it is actually more advantageous to use a DLL instead of a static LIB because a DLL can be shared by multiple applications, thereby potentially reducing memory usage. Others prefer static linking to avoid "DLL Hell". 2) When you link to a static library, only the functions your EXE actually needs are linked into your EXE (as opposed to an entire DLL getting loaded into memory, when you may only need one function from the DLL). 3) You never have to worry if the version of the DLL matches that which is required by your EXE. Back to top Remy Lebeau (TeamB) Guest Posted: Tue Jul 05, 2005 9:52 pm    Post subject: Re: DLL versus Lib if you want to link into single exe image "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in message news:42cae740$1 (AT) newsgroups (DOT) borland.com... Quote: One can link a dlll right into the executable image, right? No. The whole point of a DLL is that it is its own external file. What you are looking for is a static library, not a DLL. Quote: What is the advantage of linking to a lib file versus a dll file if the intent is to link everything statically into a single exe? If the intent is to make a standalone executable, then you do not use any DLLs at all. Quote: Also, I'm looking at some of my BCB projects and I see in the Project | Options | Directories/Conditionals | Library Path that none of the library paths call out specific lib or dll files. They are not supposed to. The path is the location of the folder(s) that contains the files, not the location of the individual files themselves. Quote: Is it not allowed to specify an exact lib file name as part of a library path entry? No. That is not how you add a .lib file to the project. Quote: If one wants to use a dll then its path belongs on the library path? No. Gambit Back to top Dennis Jones Guest Posted: Wed Jul 06, 2005 5:57 am    Post subject: Re: DLL versus Lib if you want to link into single exe image "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in message news:42cafa9a$1 (AT) newsgroups (DOT) borland.com... Quote: Dennis, Thanks for all the useful info. It is clearer now. Well, it looks like the Apache Xerces XML project builds a DLL and the import LIB. Ha! That's funny, I saw that thread too and downloaded Xerces just today and also noticed that it is a DLL. Quote: What I want instead is the static lib. Me too. However, as I mentioned in my previous post, you _could_ include the DLL in your EXE as a binary resource, extract it immediately upon executing your program (thereby making it available for the EXE to load implicitly), and delete it when the program exits. There was an article on how to do this in Windows Developer's Journal, June 2002, if you have that issue. The utility to do this was called DLLPack. Doing this effectively gives the illusion (at least from the user's perspective) that the program is self-contained. Quote: 1) Can I make a static lib from a combination of the import lib and the DLL? Unfortunately, no. Quote: 2) Do I need to create a project that makes the static lib? If so then: [Too bad the Apache guys didn't create a package -- if they had, we would already have a static lib! Also, there are a couple of minor problems with the BPR file which prevent it from compiling from the command line. They should have fixed those, but I suspect the Apache guys aren't too hip on BCB.] Quote: A) Can I convert their DLL project into a LIB project No -- at least not very easily. Quote: B) Do I need to create a new LIB project that uses the same source files? Yes, that is probably what you would have to do. However, I was thinking that an easier way might be to simply take the OBJ's that are generated when building the DLL and just put them into a static library using the TLIB utility. I don't know what caveats might exist when doing this though. Perhaps someone familiar with Xerces could jump in here. I just tried the above exersize and ended up with a 46MB static library (versus a 4MB DLL!). However, without a project to use the Xerces library, I have no way of knowing if the static library is usable as-is. - Dennis Back to top Randall Parker Guest Posted: Thu Jul 07, 2005 4:00 am    Post subject: Re: DLL versus Lib if you want to link into single exe image Dennis Jones wrote: Quote: "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in message news:42cafa9a$1 (AT) newsgroups (DOT) borland.com... Dennis, Thanks for all the useful info. It is clearer now. Well, it looks like the Apache Xerces XML project builds a DLL and the import LIB. Ha! That's funny, I saw that thread too and downloaded Xerces just today and also noticed that it is a DLL. I posted on the Xerces C++ developer list describing what I understand about their layering of make files and asking for help making a static lib. So far I haven't gotten a reply a day later. See at the bottom for my post to that list. Quote: B) Do I need to create a new LIB project that uses the same source files? Yes, that is probably what you would have to do. However, I was thinking that an easier way might be to simply take the OBJ's that are generated when building the DLL and just put them into a static library using the TLIB utility. I don't know what caveats might exist when doing this though. Perhaps someone familiar with Xerces could jump in here. Yes, I was wondering if there was some way to do that. Quote: I just tried the above exersize and ended up with a 46MB static library (versus a 4MB DLL!). However, without a project to use the Xerces library, I have no way of knowing if the static library is usable as-is. That 46Megs doesn't seem right to me. Maybe all the symbols are there rather than just the symbols that are exposed at the DLL interface. I am working on my own app that will use Xerces XML and will want to try the static lib. But as you point out, need an app to try it against. Here's what i said to the Xerces folks: I want to build a static version of Xerces v2.6.0 for Borland v6 sp4. I would just as soon avoid using the Borland IDE to do the build as that brings in additional complexity. Can anyone provide any hints for how to make a modified version of the existing mak file? Or how else to easily get it done? Maybe run a lib utility on the directory of obj files that the build of the dynamic link library creates? Since the static lib is of course NOT a dll I want to avoid linking in DllMain. I see DllMain in two files: File srcxercesccomxml4com.cpp: BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved) if (!PrxDllMain(hInstance, dwReason, lpReserved)) File srcxercescutilMsgLoadersWin32Win32MsgLoader.cpp: BOOL APIENTRY DllMain(HINSTANCE hModule, BOOL APIENTRY DllMain(HINSTANCE hModule, After running both the command line make file for making the dll and the Borland project for making the dll I see that Win32MsgLoader does not have an obj file in the output directories generated by the builds. Also, xml4com does not have an obj file. I also see DllEntryPoint in XercesLib.cpp here: xerces-c-src_2_6_0ProjectsWin32BCC.551Xerces-allXercesLibXercesLib.cpp and that directory also has the XercesLib.mak that Xerces-all.mak includes. That is where the DllEntryPoint is coming from, correct? If so, can I just make a different XercesLib.mak? Would I have to remove the XercesLib.cpp and .obj from it? Here are parts of XercesLib.mak which has the big list of objs and the XercesLib.cpp for the DllEntryPoint. Xerces-all.mak includes XercesLib.mak: # --------------------------------------------------------------------------- !if !$d(BCB) BCB = $(MAKEDIR).. !endif # --------------------------------------------------------------------------- TARGETPATH=..........BuildWin32BCC.551 PROJECT = $(TARGETPATH)xerces-bor_$(XERCESVER).dll !if $d(WITHDEPRDOM) DEPRDOM_PATH=..........srcxercescdomdeprecated DEPRDOM_DEFINE=;PROJ_DEPRECATED_DOM DEPRDOM_OBJFILES = $(TARGETPATH)objAttrImpl.obj ..... .... !endif OBJFILES = $(TARGETPATH)objXercesLib.obj $(TARGETPATH)objWin32PlatformUtils.obj ..... MAINSOURCE = XercesLib.cpp Note the line above with the MAINSOURCE. Well, I don't really want one of those I think. Then it also shows up in the OBJFILES list. Plus there is the "PROJECT = " line that specifies the dll. Can I just shift that to .lib and get a lib file out? I don't normally muck around at this level and so I don't know my way around Borland make syntax or all the stuff specific to Xerces. Here is the first part of the Xerces-all.mak file. Can I leave it unchanged if I just change my copy of XercesLib.mak? #------------------------------------------------------------------------------ !ifndef ROOT ROOT = $(MAKEDIR).. !endif #------------------------------------------------------------------------------ MAKE = $(ROOT)binmake.exe -$(MAKEFLAGS) -f$** DCC = $(ROOT)bindcc32.exe $** BRCC = $(ROOT)binbrcc32.exe $** #------------------------------------------------------------------------------ default: all #------------------------------------------------------------------------------ # Rules for building from command prompt MakeBuildDirs: MakeBuildDirs.bat call $** MAKEN = $(ROOT)binmake.exe -$(MAKEFLAGS) -f PROJECTNAMES = XercesLib DOMCount DOMPrint SAXCount SAXPrint SAX2Count SAX2Print DOMTest DOMMemTest DOMRangeTest DOMTraversal EncodingTest InitTermTest ThreadTest MemHandlerTest XSerializerTest PSVIWriter SCMPrint MemParse Redirect StdInParse PParse EnumVal SEnumVal CreateDOMDocument XSValueTest DeprecatedDOMCount DOMTypeInfoTest !include ........version.incl XERCESVER=$(VER) buildall: clearall $(PROJECTNAMES) all: $(PROJECTNAMES) clearall: del /q ........BuildWin32BCC.551*.* ........BuildWin32BCC.551obj*.* XercesLib: XercesLibXercesLib.mak cd $< $(MAKEN) $<.mak -DXERCESVER=$(XERCESVER) -DWITHDEPRDOM=$(WITHDEPRDOM) -DWITHASM=$(WITHASM) cd .. DOMPrint: DOMPrintDOMPrint.mak cd $< $(MAKEN) $<.mak -DXERCESVER=$(XERCESVER) cd .. Back to top Dennis Jones Guest Posted: Thu Jul 07, 2005 4:30 am    Post subject: Re: DLL versus Lib if you want to link into single exe image "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in message news:42cca8ca$1 (AT) newsgroups (DOT) borland.com... Quote: That 46Megs doesn't seem right to me. Maybe all the symbols are there rather than just the symbols that are exposed at the DLL interface. You're probably right. Quote: I am working on my own app that will use Xerces XML and will want to try the static lib. But as you point out, need an app to try it against. I can give you the command line and the listing file that I used to create the static lib if you are interested. I did in fact remove XercesLib.obj from that list, so it is not included in my LIB. However, it is not strictly necessary that it be removed, because the linker will not bring it in unless the application references the DllMain function. Quote: Here's what i said to the Xerces folks: <snip> Because you are asking very Borland-specific questions, I doubt you'll get much help from the Xerces folks -- but I guess it was worth a try! - Dennis Back to top Jonathan Benedicto Guest Posted: Thu Jul 07, 2005 5:05 am    Post subject: Re: DLL versus Lib if you want to link into single exe image I hope that I'm not being stupid and re-doing what you've already done, but I've been watching this thread, and I've built a static library project in BCB4. I tried to compile in BCB4, but came up with resource compiler errors, but I think that this might be because I'm using BCB4. I have posted it to the attachments group. Just extract into the XercesLib dir under the BCB6 projects dir in Xerces. HTH Jonathan Back to top Randall Parker Guest Posted: Thu Jul 07, 2005 8:59 pm    Post subject: Re: DLL versus Lib if you want to link into single exe image Dennis Jones wrote: Quote: "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in I can give you the command line and the listing file that I used to create the static lib if you are interested. I did in fact remove XercesLib.obj from that list, so it is not included in my LIB. However, it is not strictly necessary that it be removed, because the linker will not bring it in unless the application references the DllMain function. Yes, I'd like to see the command line and listing file. Either post them here or take the letters in caps out of my email address to send them to me. I might try to contact the Xerces guys who did the Borland build stuff. One of their email addresses shows up in a readme file. But I want to first wait a week to see if I get a response from their developer list. Back to top Dennis Jones Guest Posted: Thu Jul 07, 2005 11:08 pm    Post subject: Re: DLL versus Lib if you want to link into single exe image "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in message news:42cd97b6$1 (AT) newsgroups (DOT) borland.com... Quote: Dennis Jones wrote: "Randall Parker" <STOPtechiepundit (AT) EVILfuturePOXpunditSPAM (DOT) com> wrote in I can give you the command line and the listing file that I used to create the static lib if you are interested. I did in fact remove XercesLib.obj from that list, so it is not included in my LIB. However, it is not strictly necessary that it be removed, because the linker will not bring it in unless the application references the DllMain function. Yes, I'd like to see the command line and listing file. Either post them here or take the letters in caps out of my email address to send them to me. Randall, The command line is: tlib /P1024 XercesStatic.lib @objs.lst Copy the "objs.lst" file (listed below) to the "obj" folder where the object files reside. Then execute the command line from the same folder. The content of the "objs.lst" file is as follows (note that the last line does not include a '&'): +abstractdomparser.obj & +abstractnumericfacetvalidator.obj & +abstractnumericvalidator.obj & +abstractstringvalidator.obj & +allcontentmodel.obj & +anysimpletypedatatypevalidator.obj & +anyuridatatypevalidator.obj & +asciirangefactory.obj & +attrimpl.obj & +attrmapimpl.obj & +attrnsimpl.obj & +base64.obj & +base64binarydatatypevalidator.obj & +binfileinputstream.obj & +binfileoutputstream.obj & +binhttpurlinputstream.obj & +bininputstream.obj & +binmeminputstream.obj & +binmemoutputstream.obj & +binoutputstream.obj & +bitset.obj & +blockrangefactory.obj & +bmpattern.obj & +booleandatatypevalidator.obj & +cdatasectionimpl.obj & +characterdataimpl.obj & +chartoken.obj & +childnode.obj & +closuretoken.obj & +cmany.obj & +cmbinaryop.obj & +cmunaryop.obj & +commentimpl.obj & +complextypeinfo.obj & +concattoken.obj & +conditiontoken.obj & +contentleafnametypevector.obj & +contentspecnode.obj & +datatypevalidator.obj & +datatypevalidatorfactory.obj & +datedatatypevalidator.obj & +datetimedatatypevalidator.obj & +datetimevalidator.obj & +daydatatypevalidator.obj & +decimaldatatypevalidator.obj & +deepnodelistimpl.obj & +defaultpanichandler.obj & +dfacontentmodel.obj & +dgxmlscanner.obj & +documentfragmentimpl.obj & +documentimpl.obj & +documenttypeimpl.obj & +domattrimpl.obj & +domattrmapimpl.obj & +domattrnsimpl.obj & +dombuilderimpl.obj & +domcdatasectionimpl.obj & +domcharacterdataimpl.obj & +domchildnode.obj & +domcommentimpl.obj & +domconfigurationimpl.obj & +domdeepnodelistimpl.obj & +domdocumentfragmentimpl.obj & +domdocumentimpl.obj & +domdocumenttypeimpl.obj & +domelementimpl.obj & +domelementnsimpl.obj & +domentityimpl.obj & +domentityreferenceimpl.obj & +domerrorimpl.obj & +domexception.obj & +domimplementationimpl.obj & +domimplementationregistry.obj & +domlocatorimpl.obj & +dommemdebug.obj & +domnamednodemapimpl.obj & +domnodeidmap.obj & +domnodeimpl.obj & +domnodeiteratorimpl.obj & +domnodelistimpl.obj & +domnodevector.obj & +domnormalizer.obj & +domnotationimpl.obj & +domparentnode.obj & +domparser.obj & +domprocessinginstructionimpl.obj & +domrangeexception.obj & +domrangeimpl.obj & +domstring.obj & +domstringpool.obj & +domtextimpl.obj & +domtreewalkerimpl.obj & +domtypeinfoimpl.obj & +domwriterimpl.obj & +domxpathexception.obj & +dom_attr.obj & +dom_cdatasection.obj & +dom_characterdata.obj & +dom_comment.obj & +dom_document.obj & +dom_documentfragment.obj & +dom_documenttype.obj & +dom_domexception.obj & +dom_domimplementation.obj & +dom_element.obj & +dom_entity.obj & +dom_entityreference.obj & +dom_namednodemap.obj & +dom_node.obj & +dom_nodefilter.obj & +dom_nodeiterator.obj & +dom_nodelist.obj & +dom_notation.obj & +dom_processinginstruction.obj & +dom_range.obj & +dom_rangeexception.obj & +dom_text.obj & +dom_treewalker.obj & +dom_xmldecl.obj & +doubledatatypevalidator.obj & +dstringpool.obj & +dtdattdef.obj & +dtdattdeflist.obj & +dtdelementdecl.obj & +dtdentitydecl.obj & +dtdgrammar.obj & +dtdscanner.obj & +dtdvalidator.obj & +dummy.obj & +durationdatatypevalidator.obj & +elementdefinitionimpl.obj & +elementimpl.obj & +elementnsimpl.obj & +elemstack.obj & +encodingvalidator.obj & +entitydatatypevalidator.obj & +entityimpl.obj & +entityreferenceimpl.obj & +fieldactivator.obj & +fieldvaluemap.obj & +floatdatatypevalidator.obj & +generalattributecheck.obj & +grammar.obj & +grammarresolver.obj & +hashptr.obj & +hashxmlch.obj & +headerdummy.obj & +hexbin.obj & +hexbinarydatatypevalidator.obj & +ic_field.obj & +ic_key.obj & +ic_keyref.obj & +ic_selector.obj & +ic_unique.obj & +iddatatypevalidator.obj & +identityconstraint.obj & +identityconstrainthandler.obj & +idrefdatatypevalidator.obj & +igxmlscanner.obj & +igxmlscanner2.obj & +inmemmsgloader.obj & +inputsource.obj & +kvstringpair.obj & +listdatatypevalidator.obj & +localfileformattarget.obj & +localfileinputsource.obj & +match.obj & +membufformattarget.obj & +membufinputsource.obj & +memorymanagerarrayimpl.obj & +memorymanagerimpl.obj & +mixedcontentmodel.obj & +modifiertoken.obj & +monthdatatypevalidator.obj & +monthdaydatatypevalidator.obj & +mutexes.obj & +namedatatypevalidator.obj & +namednodemapimpl.obj & +namespacescope.obj & +ncnamedatatypevalidator.obj & +nodeidmap.obj & +nodeimpl.obj & +nodeiteratorimpl.obj & +nodelistimpl.obj & +nodevector.obj & +notationdatatypevalidator.obj & +notationimpl.obj & +op.obj & +opfactory.obj & +panichandler.obj & +parentnode.obj & +parentoken.obj & +parserforxmlschema.obj & +platformutils.obj & +processinginstructionimpl.obj & +psviattribute.obj & +psviattributelist.obj & +psvielement.obj & +psviitem.obj & +qname.obj & +qnamedatatypevalidator.obj & +rangefactory.obj & +rangeimpl.obj & +rangetoken.obj & +rangetokenmap.obj & +readermgr.obj & +refcountedimpl.obj & +regularexpression.obj & +regxparser.obj & +regxutil.obj & +sax2dummy.obj & +sax2xmlreaderimpl.obj & +saxexception.obj & +saxparseexception.obj & +saxparser.obj & +schemaattdef.obj & +schemaattdeflist.obj & +schemaelementdecl.obj & +schemagrammar.obj & +schemainfo.obj & +schemasymbols.obj & +schemavalidator.obj & +sgxmlscanner.obj & +simplecontentmodel.obj & +stdininputsource.obj & +stdoutformattarget.obj & +stringdatatypevalidator.obj & +stringpool.obj & +stringtoken.obj & +substitutiongroupcomparator.obj & +synchronizedstringpool.obj & +textimpl.obj & +timedatatypevalidator.obj & +token.obj & +tokenfactory.obj & +transservice.obj & +traverseschema.obj & +treewalkerimpl.obj & +unicoderangefactory.obj & +uniondatatypevalidator.obj & +uniontoken.obj & +urlinputsource.obj & +validationcontextimpl.obj & +valuestore.obj & +valuestorecache.obj & +vecattributesimpl.obj & +vecattrlistimpl.obj & +wfxmlscanner.obj & +win32platformutils.obj & +win32transservice.obj & +winsocknetaccessor.obj & +wrapper4dominputsource.obj & +wrapper4inputsource.obj & +xercesattgroupinfo.obj & +xercesdomparser.obj & +xerceselementwildcard.obj & +xercesgroupinfo.obj & +xercesxpath.obj & +xmemory.obj & +xml256tabletranscoder.obj & +xml88591transcoder.obj & +xmlabstractdoublefloat.obj & +xmlasciitranscoder.obj & +xmlattdef.obj & +xmlattdeflist.obj & +xmlattr.obj & +xmlbigdecimal.obj & +xmlbiginteger.obj & +xmlbuffer.obj & +xmlbuffermgr.obj & +xmlcanrepgroup.obj & +xmlchar.obj & +xmlchtranscoder.obj & +xmlcontentmodel.obj & +xmldatetime.obj & +xmldeclimpl.obj & +xmldouble.obj & +xmldtddescription.obj & +xmldtddescriptionimpl.obj & +xmlebcdictranscoder.obj & +xmlelementdecl.obj & +xmlentitydecl.obj & +xmlexception.obj & +xmlfloat.obj & +xmlformatter.obj & +xmlgrammardescription.obj & +xmlgrammarpoolimpl.obj & +xmlibm1047transcoder.obj & +xmlibm1140transcoder.obj & +xmlmsgloader.obj & +xmlnotationdecl.obj & +xmlnumber.obj & +xmlrangefactory.obj & +xmlreader.obj & +xmlrecognizer.obj & +xmlrefinfo.obj & +xmlregistercleanup.obj & +xmlscanner.obj & +xmlscannerresolver.obj & +xmlschemadescription.obj & +xmlschemadescriptionimpl.obj & +xmlstring.obj & +xmlstringtokenizer.obj & +xmlucstranscoder.obj & +xmluni.obj & +xmlunicharacter.obj & +xmluri.obj & +xmlurl.obj & +xmlutf16transcoder.obj & +xmlutf8transcoder.obj & +xmlvalidator.obj & +xmlwin1252transcoder.obj & +xobjectcomparator.obj & +xpathmatcher.obj & +xpathmatcherstack.obj & +xpathsymbols.obj & +xprototype.obj & +xsannotation.obj & +xsattributedeclaration.obj & +xsattributegroupdefinition.obj & +xsattributeuse.obj & +xsaxmlscanner.obj & +xscomplextypedefinition.obj & +xsddomparser.obj & +xsdelementnsimpl.obj & +xsderrorreporter.obj & +xsdlocator.obj & +xselementdeclaration.obj & +xserializeengine.obj & +xsfacet.obj & +xsidcdefinition.obj & +xsmodel.obj & +xsmodelgroup.obj & +xsmodelgroupdefinition.obj & +xsmultivaluefacet.obj & +xsnamespaceitem.obj & +xsnotationdeclaration.obj & +xsobject.obj & +xsobjectfactory.obj & +xsparticle.obj & +xssimpletypedefinition.obj & +xstypedefinition.obj & +xsvalue.obj & +xswildcard.obj & +xtemplatecomparator.obj & +xtemplateserializer.obj & +xutil.obj & +yeardatatypevalidator.obj & +yearmonthdatatypevalidator.obj - Dennis Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> C++ Builder (IDE) All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.