Fix of the Week

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: Fix of the Week

Post by Webunny » Fri Nov 29, 2013 6:28 pm

What would earn the 'fix of the week' title with me, is a fix to the driver re-install problem. I've already talked about it in the hardware-test post, but I'll post it here as well:

In ROS 3.15 it STILL does not seem possible to reinstall a driver. When I go to 'system', 'device manager', etc. in Windows, you have the possibility to reinstall... but not in ROS. You can't even delete it, and then do a successful search for new hardware, as one can in Windows. I've noted this before, and I repeat this is a seriously annoying thing for any 'real hardware'-testing. And it only needs a trivial (for a coder) amount in recoding for this; one just has to provide a button that re-enacts the code with the window you get when first installing ROS, where it DOES ask for (to search for) a driver. So it doesn't need some grand recoding, just something that relaunches that particular code (which already exists in ROS). Can't a developer *please* look at this? Pretty please?

Anyway, it seems that, until this is fixed, everyone testing ROS on real hardware (VM-testers have less trouble with it, of course) who wants a network-connection (and everything else that needs a driver), *still* has to do it the long and tedious way of reinstalling ROS, and then search for the right driver burned on a disc or whatever, when ROS starts up for the first time. It's *really* annoying to have to do a complete reinstall everytime you want to test out a driver on real HW!! Therefore, anyone able to fix this, would rightfully earn the 'fix of the week' title!





Edit2:re-installed ROS, manually selected the driver from my CD, reinstalled FF3.6, and... it worked! Have networkconnection. Installed old version of standalone flash (otherwise, FF didn't perform all to well when visualising things) Started up FF again, and am currently downloading Ur-Quan masters (though this time the HD version), to redo the exact things I tested with 3.14.

gonzoMD
Posts: 1020
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: Fix of the Week

Post by gonzoMD » Thu Dec 19, 2013 2:04 pm

ladies and Gentleman, here we present you the fix of an almost 5 years old bug, and the winner is: Frontier!!!
AmineKhaldi wrote:akhaldi committed changeset 61293 to the Core ReactOS project
[SHELL32] * Make the Recycle Bin icon reflect whether the bin is empty or not. Brought to you by Huw Campbell. CORE-3712 #resolve #comment Committed in r61293. Cheers ;)

manuel
Posts: 404
Joined: Thu Jan 28, 2010 11:20 pm
Location: México
Contact:

Re: Fix of the Week

Post by manuel » Thu Dec 19, 2013 9:07 pm

gonzoMD wrote:ladies and Gentleman, here we present you the fix of an almost 5 years old bug
wow, 5 years old :)

gonzoMD
Posts: 1020
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: Fix of the Week

Post by gonzoMD » Fri Dec 20, 2013 7:27 am

manuel wrote:
gonzoMD wrote:ladies and Gentleman, here we present you the fix of an almost 5 years old bug
wow, 5 years old :)
probably older, but 4 years and 11 months ago, the Bugreport was done.

Frontier
Posts: 70
Joined: Fri Sep 20, 2013 10:29 am

Re: Fix of the Week

Post by Frontier » Fri Dec 20, 2013 1:34 pm

gonzoMD wrote:ladies and Gentleman, here we present you the fix of an almost 5 years old bug, and the winner is: Frontier!!!
AmineKhaldi wrote:akhaldi committed changeset 61293 to the Core ReactOS project
[SHELL32] * Make the Recycle Bin icon reflect whether the bin is empty or not. Brought to you by Huw Campbell. CORE-3712 #resolve #comment Committed in r61293. Cheers ;)
Haha, you've made my day.

gonzoMD
Posts: 1020
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: Fix of the Week

Post by gonzoMD » Sun Jan 05, 2014 10:03 pm

Eric Kohl wrote:[LSASRV][MSV1_0] - Add all groups, of which the user is a member, to the token group list. - Remove the hard-coded administrators group and users group from the token group list. This patch enables us to create ordinary user accounts which are not members of the administrator group and which do not have administrator privileges. Now we can start to test and fix the security components!

cruonit
Posts: 250
Joined: Mon Jun 29, 2009 12:57 am

Re: Fix of the Week

Post by cruonit » Sun Jan 05, 2014 11:24 pm

[SHELL32]
* Move shell file operations to background threads to prevent the shell from hanging during long copies, deletes, and moves.
* Improve drag and drop functionality.
* Add a partial drop handler to the recycle bin.
* Brought to you by Huw Campbell.
CORE-3760

cruonit
Posts: 250
Joined: Mon Jun 29, 2009 12:57 am

Re: Fix of the Week

Post by cruonit » Tue Jan 14, 2014 9:29 pm

[CMLIB]
Pay back the US National Debt.
... well not entirely, but at least remove the "hack similar in magnitude to the US's National Debt"! As a nice side effect we can now load Windows 2003 hive files.

ConductiveDielectric
Posts: 32
Joined: Thu Aug 01, 2013 6:39 am

Re: Fix of the Week

Post by ConductiveDielectric » Fri Feb 21, 2014 11:00 pm

r62283 - https://code.reactos.org/changelog/reactos?cs=62283

The longest commit message ever.
Hermes Belusca-Maito wrote:** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !

oswetto
Posts: 109
Joined: Mon Oct 26, 2009 10:43 pm

Re: Fix of the Week

Post by oswetto » Sun Mar 02, 2014 2:52 am

Fix very old bug https://jira.reactos.org/browse/CORE-7354 We have this bug since revision 12776
[FTP] Fix download with ftp.exe, the problem was that we didn't switch download mode to binary when needed, because of idiotic defines used that where pointless here. We have this bug since revision 12776... Patch by Alexander Varnin, see CORE-3682 for details. CORE-3682 #resolve #comment Committed in revision, cheers ;)

hbelusca
Developer
Posts: 1128
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Fix of the Week

Post by hbelusca » Mon Mar 03, 2014 4:55 pm

oswetto wrote:Fix very old bug https://jira.reactos.org/browse/CORE-7354 We have this bug since revision 12776
[FTP] Fix download with ftp.exe, the problem was that we didn't switch download mode to binary when needed, because of idiotic defines used that where pointless here. We have this bug since revision 12776... Patch by Alexander Varnin, see CORE-3682 for details. CORE-3682 #resolve #comment Committed in revision, cheers ;)
Well for this bug, I still need one or two testers for double-checking the fix :) :)

gonzoMD
Posts: 1020
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: Fix of the Week

Post by gonzoMD » Wed Mar 05, 2014 7:59 pm

not really a FOTW but I love the commit message :D
[EXPLORER-NEW] * I don't know what this may fix, but it was wrong. On the upside, now there's less spam in the log.

gonzoMD
Posts: 1020
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: Fix of the Week

Post by gonzoMD » Thu Mar 13, 2014 4:31 pm

shell32 go, go, go!!!
David Quintana resolved CORE-7879 - Implement CMenuSite as 'Fixed'
The class is feature-complete, as far as I can tell. I believe this task has been achieved.

Jedi-to-be
Posts: 698
Joined: Sun Mar 16, 2008 11:26 am
Location: Russia, Stavropol
Contact:

Re: Fix of the Week

Post by Jedi-to-be » Thu Mar 13, 2014 11:43 pm

https://code.reactos.org/changelog/reactos?cs=62493
[uniata] update uniata to 45a3 fixes installation on ATI IXP700 SATA controller

http://code.reactos.org/changelog/reactos?cs=62482
[NTOSKRNL]
Fix a bug in MmGetPhysicalAddress, that resulted in unwanted sign extension of physical addresses > 2GB. Will hopefully fix some uniata related issues.

DOSGuy
Posts: 582
Joined: Wed Sep 14, 2011 5:55 pm
Contact:

Re: Fix of the Week

Post by DOSGuy » Mon Mar 17, 2014 10:42 pm

It makes CORE-6774 even worse, so whether this is a good fix or not depends on your perspective.
Today entirely the maniac there is no excuse with the article. Get free DOS, Windows and OS/2 games at RGB Classic Games.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests