Closed Bug 46776 Opened 24 years ago Closed 19 years ago

need .def file for xpcom

Categories

(Core :: XPCOM, defect, P3)

x86
Windows NT
defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: warrensomebody, Unassigned)

References

Details

(Keywords: arch, topembed-, Whiteboard: [nsbeta3-] T2)

Attachments

(1 file)

Need to fix ordinals for NS_NewGenericModule, NS_NewGenericFactory and any other xpcom entry points needed for embedding. If we don't provide this, entry point ordinals will not be reproducible for subsequent releases, and binary compatiblity will be broken.
Keywords: arch, nsbeta3
Whiteboard: [nsbeta3+]
dougt said that there was a possibility that making this change might break our JDK 1.3 support. FYI, any changes to the product between now and RTM must be done in such a way that they don't break the support of Mozilla/N6 for Java through OJI via the JDK 1.3. Anyone who's considering a change that would break Java support--we can't, so contact ekrock@netscape.com if you're considering doing such a thing. That's a regression for which we'd have no fix and Java support is a committed feature for both products.
Translation: Make sure that the ordinals specified in the .def file for the entry points we care about correspond to the ordinals that have incidentally been captured by the jdk. Someone from Sun needs to help us figure out what they are.
Warren, I'm happy to help if you can define what you mean by "ordinals". Is this a catch all term for {class name, method name, macro name, function name}?
This page talks about ordinals and .def files: http://msdn.microsoft.com/library/periodic/period00/hood0500.htm
Rick: How can Ed determine the current ordinals that their jvm plugin is depending on from xpcom? Maybe this: dumpbin /imports jvm.dll (Paste the output in this bug report.)
I hope this is what you're looking for. I don't see any NS strings in the dumpbin output.
Ok, it looks like you're not linking with xpcom.dll at all, so we're free to pick any ordinals we want for our entry points.
Here's the proposed .def file. I need two things to check it in... 1. How do I handle overloaded method names (ones commented out, below)? Do all these symbols need to be defined extern "C"? If so, the overloaded ones are problematic. 2. Please review the list of functions and let me know which ones we can cut. ; -*- Mode: text; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- ; ; The contents of this file are subject to the Netscape Public ; License Version 1.1 (the "License"); you may not use this file ; except in compliance with the License. You may obtain a copy of ; the License at http://www.mozilla.org/NPL/ ; ; Software distributed under the License is distributed on an "AS ; IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or ; implied. See the License for the specific language governing ; rights and limitations under the License. ; ; The Original Code is mozilla.org code. ; ; The Initial Developer of the Original Code is Netscape ; Communications Corporation. Portions created by Netscape are ; Copyright (C) 1998 Netscape Communications Corporation. All ; Rights Reserved. LIBRARY xpcom.dll EXPORTS ; Initialization/Shutdown stuff NS_InitXPCOM NS_InitXPCOM2 NS_ShutdownXPCOM ; Misc stuff NS_ErrorAccordingToNSPR NS_GetWeakReference NS_GetGlobalComponentManager NS_NewGenericFactory NS_NewGenericModule ; Data Structure stuff NS_NewHeapArena NS_NewByteBuffer NS_NewObserverList NS_NewSizeOfHandler NS_NewUnicharBuffer NS_NewObserver ; fputs(const nsCString& aString, FILE* out) ; fputs(const nsString& aString, FILE* out) ; fputs(const nsString& aString, FILE* out) ; Recycle( PRUnichar* aBuffer) ; fputs(const nsCString& aString, FILE* out) ; Recycle( char* aBuffer) ; NS_NewAtom(const char* isolatin1) ; NS_NewAtom(const PRUnichar* unicode) ; NS_NewAtom(const nsAReadableString& aString) NS_GetNumberOfAtoms NS_PurgeAtomTable NS_NewISupportsArray NS_NewISupportsArrayEnumerator NS_NewStringUnicharInputStream NS_NewConverterStream NS_NewByteArrayInputStream NS_NewPipe ; NS_NewThread(nsIThread* *result, ; nsIRunnable* runnable, ; PRUint32 stackSize = 0, ; PRThreadState state = PR_UNJOINABLE_THREAD, ; PRThreadPriority priority = PR_PRIORITY_NORMAL, ; PRThreadScope scope = PR_GLOBAL_THREAD) ; NS_NewThread(nsIThread* *result, ; PRUint32 stackSize = 0, ; PRThreadState state = PR_UNJOINABLE_THREAD, ; PRThreadPriority priority = PR_PRIORITY_NORMAL, ; PRThreadScope scope = PR_GLOBAL_THREAD)
Ed: Can you grep your source for GetProcAddress and see if you're dynamically pulling in symbols from xpcom? Thanks,
I just talked to Rick about this, and if Sun is only using GetProcAddress to pull in xpcom symbols, then assigning ordinals now isn't critical. We can do this later. nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]
Warren: no hits on that string in the java plugin.
I don't understand. Why did we think java depended on anything in xpcom? Are there any headers you're using besides the plugin headers? I'm just curious.
warren: here's the infamous list of all the ns* header files included in Sun's java plugin: #include "nsIBwAdapterPluginStreamListener.h" #include "nsICapsManager.h" #include "nsICertPrincipal.h" #include "nsICertificatePrincipal.h" #include "nsICodebasePrincipal.h" #include "nsICookieStorage.h" #include "nsIEventHandler.h" #include "nsIFactory.h" #include "nsIJVMConsole.h" #include "nsIJVMManager.h" #include "nsIJVMPlugin.h" #include "nsIJVMPluginInstance.h" #include "nsIJVMPrefsPanel.h" #include "nsIJVMPrefsWindow.h" #include "nsILiveconnect.h" #include "nsIOutputStream.h" #include "nsIPlugin.h" #include "nsIPluginInputStream.h" #include "nsIPluginInstance.h" #include "nsIPluginInstancePeer.h" #include "nsIPluginInstancePeer2.h" #include "nsIPluginManager.h" #include "nsIPluginManager2.h" #include "nsIPluginServiceProvider.h" #include "nsIPluginStream.h" #include "nsIPluginStreamInfo.h" #include "nsIPluginStreamListener.h" #include "nsIPluginStreamPeer.h" #include "nsIPluginTagInfo.h" #include "nsIPrincipal.h" #include "nsISecureEnv.h" #include "nsISecureJNI2.h" #include "nsISecureLiveconnect.h" #include "nsISecurityContext.h" #include "nsIServiceManager.h" #include "nsIThreadManager.h"
Ed: And you have an NSGetFactory method (not NSGetModule), right?
Yes, we have NSGetFactory.
QA Contact: leger → kandrot
Warren, what's the status on this?
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: kandrot → scc
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Blocks: 98278
Target Milestone: --- → mozilla1.0
Keywords: mozilla1.0
I do not think that this is required for mozilla 1.0. Rick, correct me if I am wrong, but is seams to me that we can just encourge people to use our "glue" library and have them avoid linking directly to xpcom. It is a nice thing to have, but I do not know if it is required.
Target Milestone: mozilla1.0 → Future
Keywords: topembed
topembed- since we are not aiming for binary compatibility right now.
Keywords: topembedtopembed-
Keeping as topembed-
Whiteboard: [nsbeta3-] → [nsbeta3-] T2
Assignee: dougt → nobody
QA Contact: scc → xpcom
We're not using ordinal exports, rather exports by name. No need for a .def file.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: