bzbarsky%mit.edu e4fa0ae687 Make console service init handle out-of-memory. Bug 281093, patch by Daniel de ... Wildt <dewildt@gmail.com>, r+sr=bzbarsky		2005-03-02 16:37:53 +00:00
..
.cvsignore	…
Makefile.in	252189, XPCOM section:	2005-02-25 09:00:45 +00:00
dlldeps.cpp	landing xpcom patch for bug 235499 "re-enable string buffer sharing between C++ and JS in xpconnect" r=dbaron sr=jst	2005-02-02 22:18:37 +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 271630 "XPCOM glue broken on Linux/PPC [monkeypox orange]" r=bsmedberg	2004-11-30 00:28:48 +00:00
nsXPCOM.h	Bug 267767 - Make XPCOM memory management functions frozen exports. r=darin sr=shaver	2004-11-12 19:26:37 +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	bug 280245. WinCE build and support changes. r=darin	2005-01-30 21:33:47 +00:00
nsXPComInit.cpp	Make console service init handle out-of-memory. Bug 281093, patch by Daniel de	2005-03-02 16:37:53 +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