46776 - need .def file for xpcom

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P3)

Description

[Warren Harris]

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.

Comment 1

[ekrock's old account (dead)]

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 [e-mail] 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.

Comment 2

[Warren Harris]

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.

Comment 3

[edburns]

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}?

Comment 4

[Warren Harris]

This page talks about ordinals and .def files: 
http://msdn.microsoft.com/library/periodic/period00/hood0500.htm

Comment 5

[Warren Harris]

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.)

Comment 6

[edburns]

Attachment: Output of DUMPBIN.EXE on Java Plugin DLLs for win32.

Comment 7

[edburns]

I hope this is what you're looking for.  I don't see any NS strings in the 
dumpbin output.

Comment 8

[Warren Harris]

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.

Comment 9

[Warren Harris]

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)

Comment 10

[Warren Harris]

Ed: Can you grep your source for GetProcAddress and see if you're dynamically 
pulling in symbols from xpcom? Thanks,

Comment 11

[Warren Harris]

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-

Comment 12

[edburns]

Warren: no hits on that string in the java plugin.

Comment 13

[Warren Harris]

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

[edburns]

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"

Comment 15

[Warren Harris]

Ed: And you have an NSGetFactory method (not NSGetModule), right?

Comment 16

[edburns]

Yes, we have NSGetFactory.

Comment 17

[edburns]

Warren, what's the status on this?

Comment 18

[Asa Dotzler [:asa]]

reasigning warren bugs to default component owners.

Comment 19

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 20

[Doug Turner (:dougt)]

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. 

Comment 21

[Dave Barrowman]

topembed- since we are not aiming for binary compatibility right now.

Comment 22

[Dave Barrowman]

Keeping as topembed-

Comment 23

[Benjamin Smedberg]

We're not using ordinal exports, rather exports by name. No need for a .def file.