Closed
Bug 46776
Opened 24 years ago
Closed 19 years ago
need .def file for xpcom
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
RESOLVED
WONTFIX
Future
People
(Reporter: warrensomebody, Unassigned)
References
Details
(Keywords: arch, topembed-, Whiteboard: [nsbeta3-] T2)
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.
Reporter | ||
Updated•24 years ago
|
Reporter | ||
Updated•24 years ago
|
Whiteboard: [nsbeta3+]
Comment 1•24 years ago
|
||
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.
Reporter | ||
Comment 2•24 years ago
|
||
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}?
Reporter | ||
Comment 4•24 years ago
|
||
This page talks about ordinals and .def files:
http://msdn.microsoft.com/library/periodic/period00/hood0500.htm
Reporter | ||
Comment 5•24 years ago
|
||
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.
Reporter | ||
Comment 8•24 years ago
|
||
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.
Reporter | ||
Comment 9•24 years ago
|
||
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)
Reporter | ||
Comment 10•24 years ago
|
||
Ed: Can you grep your source for GetProcAddress and see if you're dynamically
pulling in symbols from xpcom? Thanks,
Reporter | ||
Comment 11•24 years ago
|
||
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-]
Comment 12•24 years ago
|
||
Warren: no hits on that string in the java plugin.
Reporter | ||
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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"
Reporter | ||
Comment 15•24 years ago
|
||
Ed: And you have an NSGetFactory method (not NSGetModule), right?
Comment 16•24 years ago
|
||
Yes, we have NSGetFactory.
Updated•24 years ago
|
QA Contact: leger → kandrot
Comment 17•24 years ago
|
||
Warren, what's the status on this?
Comment 18•23 years ago
|
||
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: kandrot → scc
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Updated•23 years ago
|
Keywords: mozilla1.0
Comment 20•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 21•23 years ago
|
||
topembed- since we are not aiming for binary compatibility right now.
Updated•19 years ago
|
Assignee: dougt → nobody
QA Contact: scc → xpcom
Comment 23•19 years ago
|
||
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.
Description
•