The concept of entry point in COFF is actually different than in ELF.
In COFF, the entry point is actually a "descriptor" (pointer) to the actual
start code. So we patch the entry point address when calling objcopy.
Now my old Performa 5400/180 actually starts the loader correctly \o/
Those return uintNN_t types instead of our own types,
but uint32 for example is long while uint32_t isn't,
giving some trouble with the PRI* macros for example on PPC.
It seems like glibc also has paths.h and m4 fails to bootstrap
without _PATH_BSHELL.
This file really needs some cleanup btw, since most is actually
irrelevant or incorrect for Haiku.
In hrev47355 a logic reversal was introduced as part of a cleanup
commit which caused B_ARGV_RECEIVED to be sent only to apps with the
B_ARGV_ONLY flag set instead of clear.
In addition to that, don't send the B_SILENT_RELAUNCH message for apps
with B_ARGV_ONLY either, as they are not supposed to receive messages
after launch. This is in line with the documentation and what BRoster
does.
* We don't change the data cache (and other) settings.
Interesting to know their state on each platform.
* Not used by default as it needs called after
serial-init in u-boot
The AddOnManager was in the global namespace, clashing with application
classes with the same name.
The input_server has an AddOnManager of its own. When the
shortcut_catcher filter was loaded by said AddOnManager, it in turn
loaded libgame.so, which in turn loaded libmedia.so, where an
AddOnManager was created for the global AddOnManager instance in
libmedia.so. Unfortunately the wrong AddOnManager, the one from the
input_server, was created. This lead to two AddOnManagers being active
in the input_server which very well could be responsible for #11049
and #11280.
This was a regression since the move of the AddOnManager from the
media_server to libmedia.so in hrev47086. This also fits with the two
tickets.
I actually noticed the problem when debugging the shutdown process of
the input_server, where the destruction of the wrong AddOnManager
caused a deadlock with itself.
* Before this commit address bar used:
B_MENU, B_LIST, B_DOCUMENT colors.
With strange results during customization.
* Now the address uses list user colors.
* Partialy fixes#10840.
The model was owned by the info window and is gone at the point where
the AttributeView is destroyed. Since the extra check whether the model
is a symlink isn't really needed at all, I opted to just remove it
instead of destroying the AttributeView sooner or unsetting its model.
The layout item representing the layout of the view to be removed is
owned by the view and must not be deleted. The layout only owns the
item if a new layout item was created when adding the view, i.e. when
it did not have a layout.
Fixes the underlying issue that triggered #11976.
Removing the view from the window and deleting it is fine. This is a
quick fix for #11976. The underlaying issue of how BLayout::RemoveView
should work still needs to be fixed.
François Revol