Can I have commit access to !trunk branches for not forking to Git?
(for reviving the POSIX subsystem with the Newlib C library and adding
pthreads support)
Thanks,
I guess it take a decade to get things done in ReactOS? After a few had
reverted some code and stuff.
Like,
Convert COREINFOHEADER to BITMAPINFOHEADER before passing it to
NtGdiCreateDIBitmapInternal
Yeah~! Very Original!
Those that do not get it, research it! It's all in the mailing list!
James
That doesn't seem to make much sense. Why enumerate from the end? It
should rather enumerate from the start and skip the KdComPort. So far we
used COM1 as debug port on MSVC builds and COM2 as terminal debug port
for both freeldr and KDCOM. Preferably this should configurable. I
really don't like this unintuitive and quite random behaviour.
> +#ifdef KDDEBUG
> + /*
> + * Try to find a free COM port and use it as the KD debugging port.
> + * NOTE: Inspired by reactos/boot/freeldr/freeldr/comm/rs232.c, Rs232PortInitialize(...)
> + */
> + {
> + /*
> + * Start enumerating COM ports from the last one to the first one,
> + * and break when we find a valid port.
> + * If we reach the first element of the list, the invalid COM port,
> + * then it means that no valid port was found.
> + */
> + ULONG ComPort;
> + for (ComPort = MAX_COM_PORTS; ComPort > 0; ComPort--)
> + {
> + /* Check if the port exist; skip the KD port */
> + if ((ComPort != ComPortNumber) && CpDoesPortExist(UlongToPtr(BaseArray[ComPort])))
> + break;
> + }
> + if (ComPort != 0)
> + CpInitialize(&KdDebugComPort, UlongToPtr(BaseArray[ComPort]), DEFAULT_BAUD_RATE);
> + }
> +#endif
> +
> + KDDBGPRINT("KdDebuggerInitialize0\n");
>
>
>
Hi all
I'd like to report a bug, but can't figure out how to do this properly. Jira
requires being a registered user but does not tell how exactly one is
supposed to get that registration. I hope you have some other, more
user-friendly way for reporting bugs by "normal" users - people not so
intimate with the ReactOS development - or that you at least plan to provide
such a way in the near future.
Anyway, here's what I think warrants looking into in more detail: Apparently
there is still something that corrupts fastfat - triggerable from user-mode
programs. The automatic update function of Firefox (as well as other
derivatives like Pale Moon) seems to trigger a particularly nasty instance
of that. I think that if a new ReactOS version is going to be released now,
it will cause a lot of spurious bug reports from users that install Firefox
(it's a popular program after all), and wreck FastFAT during an update in
the background. In fact, many users may not be aware of the connection as
Firefox tends to update itself in a stealthy way and the user does not
really get to see what happens.
Steps to reproduce:
- install Firefox (or Palemoon, any version from the last couple of years,
except of course the latest one)
- open the about dialog in it
- it will start downloading an update
- it will copy the update into a temporary dir in the firefox install dir
- it will prompt the user for a restart
- look into the Firefox install dir, you will find (among other things) an
"update" subdir with temporary files, but so far everything looks OK
- now click restart in prompt
- it will do some filesystem operations for some seconds, quit, but not
restart
- look into the install dir again, now it will be a horrible mess of
unintelligible things with completely broken filenames
- you may not always be able to take that last look as ReactOS may lock-up
when you open the folder in explorer (or when you hit F5 if it was already
opened)
- in any case, ReactOS won't stay very stable for significant time
afterwards, even if it survives the look
- if it does stay stable for a while, you won't be able to delete the
directory nor any items in it, an attempt to delete them will fail, often
causing a lock-up
Affected versions of Firefox
- seemingly all from the recent decade
Affected SVN builds of ReactOS
- everything from recent years as far as I can tell, but see notes below
Additional notes
- I've only tested builds made from SVN with RosBE on Windows - but many
versions
- this bug seems to be always changing when FastFAT is touched in various
ROS SVN builds
- about half a yer ago it was always leading to a hard lock-up and the
filesystem was badly broken, even without opening the folder in Explorer,
the crash would not be far away
- some 3-4 months ago, the "survival" (no-crash) rate rose somewhat, but the
folder still got "filled" with various rubbish
- a month or 2 ago the filesystem at least tended to survive and the Firefox
directory seemed to be "empty" after an update - although it could not be
deleted even though nothing could be "seen" inside it, also a reinstall into
the same folder tended to work without crashing
- in the recent 1-2 weeks one FastFAT update brought back the bad old times,
after the failed update the Firefox directory is again getting filled with
broken items, and the number of those items that end up in there, seems to
have increased by a lot
Regards
Dimitrij Klingbeil
On 2015-12-08 23:54, rnaumann(a)svn.reactos.org wrote:
> --- trunk/reactos/base/shell/explorer/trayprop.cpp [iso-8859-1] (original)
> +++ trunk/reactos/base/shell/explorer/trayprop.cpp [iso-8859-1] Tue Dec 8 22:54:33 2015
> @@ -338,7 +338,7 @@
> VOID
> DisplayTrayProperties(IN HWND hwndOwner)
> {
> - PROPSHEET_INFO propInfo;
> + PROPSHEET_INFO propInfo = {0};
> PROPSHEETHEADER psh;
> PROPSHEETPAGE psp[2];
> WCHAR szCaption[256];
I would find this code much easier to understand if you passed 0 as the
start menu page's lParam, since it's not making use of it anyway.
Having it in both made me worry quite a lot about double frees and such
that would happen if both pages used the same structure.
Hi all,
I'm just digging into kbswitch and have several questions (later).
The major issue: kbswitch affects all windows at once, while it should
change the input language only for the current (focused) window.
I assume that kbswitch must preserve the active window, so that it can
know where to apply changes, and to re-activate that window when done.
As I don't know what's already implemented, I wrote a simple test
program, using
GetForegroundWindow() to determine the active window (hwnd),
GetWindowThreadProcessId() to get the related process handle, and
GetKeyboardLayout() to get the keyboard/language handle (hkl).
Tested on WinXP and ReactOS, the output looks correct. The hkl seems to
be composed of two words (hi: language and low: layout), which are
always the same on ReactOS. On XP a different keyboard layout can be
used for a language, but I cannot decipher the resulting encoding of the
layout. As soon as I try to change the layout for a language on ReactOS,
kbswitch shows the *layout* name, not the *language* name.
Q: Can somebody try to find out how to convert a HKL into language and
layout id's and/or names? (see GetLayoutIDByHkl)
Q: Is kbswitch notified of focus changes, and if so: how?
Then above sequence can be used to identify the related thread's
setting, and update the tray icon and menu accordingly.
Q: Is every process/thread already assigned a *private* hkl?
If not, this feature must be implemented before further updates.
So much for now
DoDi
