darin%meer.net 3683299737 fix windows build bustage		2005-05-16 23:34:11 +00:00
..
.cvsignore	…
Makefile.in	Bug 288626 - Begin switch from MOZILLA_STRICT_API to MOZILLA_INTERNAL_API rs=darin for the Makefile var additions. Should not affect the build yet, until we flip a few switches at the end.	2005-04-01 18:22:57 +00:00
dlldeps.cpp	fix windows build bustage	2005-05-16 23:34:11 +00:00
malloc.c	Split private xpcom defines into separate header.	2003-07-03 20:55:23 +00:00
nsOS2VACLegacy.cpp	Reduce do_GetService code bloat further by adding specialized assignment to nsCOMPtr and providing a version with no error pointer. Also make CallGetService work the same way as CallGetComponent does, as far as using frozen/non-frozen interface to service manager. Bug 264456, r=darin.	2004-11-24 22:48:45 +00:00
nsStringAPI.cpp	fixes bug 288786 "Add BeginWriting equivalent to frozen string API" r=biesi sr=dbaron a=asa	2005-04-27 01:38:35 +00:00
nsXPCOM.h	Bug 288626 - Switch the strict API from opt-in (MOZILLA_STRICT_API) to opt-out (MOZILLA_INTERNAL_API) r=darin	2005-04-06 03:35:24 +00:00
nsXPCOMCID.h	b=266085, nsIWritablePropertyBag interface and hashtable component implementation; r=darin,sr=shaver	2004-11-24 23:21:14 +00:00
nsXPCOMPrivate.h	fixes bug 288786 "Add BeginWriting equivalent to frozen string API" r=biesi sr=dbaron a=asa	2005-04-27 01:38:35 +00:00
nsXPComInit.cpp	Fixing WinCE Bustage. r=darin	2005-05-16 21:33:33 +00:00
win32.order	Bugzilla Bug 107823 change nsIFile	2001-11-26 08:05:05 +00:00
xpcom-tests.pkg	Beginning to land the PACKAGING_20030906_BRANCH for bug 20640. Not part of the build, yet.	2004-01-07 01:22:31 +00:00
xpcom.pkg	Bug 251078 Remove xpcom's rebase utility	2004-11-23 20:00:26 +00:00
xpcom_alpha.def	bug 54471. Increase the xptcall stubs entry point count to almost 256. This increases the number of methods that can be implmented on a JS object via xpconnect, or on an xpcom/proxy object, or via PyXPCOM. There are platform limitations that would need to worked out to go higher. Also higher counts start getting into a zone where we should be wisely weighing the memory cost. r=markh@activestate.com sr=shaver@mozilla.org	2001-05-19 00:03:01 +00:00