Revision 52484

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Revision 52484

Post by PurpleGurl »

I just tried revision 52484 on real hardware and I was quite frustrated. First, reading that the USB support was removed, I thought I'd skip disabling it. However, the PS/2 mouse didn't work. So I decided to disable the legacy USB support as before, but leave the 2.0 stuff enabled. So the mouse worked and the system worked without hanging. So if the developers removed the USB driver, then why does the legacy USB support still interfere with the PS/2 mouse and possibly keyboard? Anyway, for an improvement, I was able to go to the control panel and adjust the mouse speed. While it wasn't as fast as I could do it in Windows, it was certainly much faster than the last time. From there, the experience went downhill.

Next I went to the explorer and browsed my files. Like earlier releases, I was only able to get into one of my drives. It was FAT32, but it would not recognize my other FAT32 drives. I don't know if it was a size issue or an allocation unit size issue. Yet, it displayed the name of one of my NTFS drives. That was inconsistent, since it later showed the name of another NTFS volume too. I could not get into either of course, and that was expected. But, I was able to get into the one I could before. Also, the drives listed were duplicated into other letters (maybe that is a SATA bug, since I am running a RAID 1 array). So all this behavior was about the same. From there, I went to my emulator games folder. When I tested 51818, I was able to run the Gems emulator. This time, it crashed with a memory error, saying that an address couldn't be read or something. Before, it worked, but I couldn't play the game I loaded into the emulator because the left keyboard arrow button didn't work. This time, the Gems emulator crashed.

From there, I tried installing the AnalogX Capture program, and used the one partition I could get into as the location. I think there was an error or something , but it created a folder and installed there. But without a Program Files and Desktop file structure, I had to launch the capture program from the folder. That was okay, and it worked. So I decided I was going to use it to make screen shots of things, both to remind me of the session and as documenting evidence. But that didn't work out. The files and the new folder were accessible from within Reactos. But not in Windows when I went back. In fact, I had to run Norton Disk Doctor to repair the corruption Reactos caused to the partition by creating that folder, and I used a recovery program to access the files created. Now, the problem was that the bitmaps were only half visible. So not only was the new folder corrupted, so were the files placed in it. But they accessed fine under Reactos. So Reactos is doing something with file I/O outside the standards to where Reactos can access it, but Windows cannot.

I also found that Explorer was kludgy, inconsistent, and unstable. After a point, it go to where I could not go into My Computer and had to use the Task Manager to crash exit Explorer.exe and forcibly reload it. I would have tried the MS version if I could find a copy, but I couldn't since my C volume was NTFS. There were many bugs and kludgy behaviors in the explorer. For instance, if you go to single window interface mode and then go to My Computer, no files come up. But if you change the setting back to multiple folders, it goes back to displaying files. Now, once you open an item from there, it cascades, but the window splits. I mean, the old portion that is still visible still has the old text, but the new window inside also has the same text. And the new window was placed above the old window in both its old and new locations.

There are other things that happened, but I cannot remember and I need to go to bed.

To make this a fair test, I probably should take the advice given in another recent trunk build thread and test the revision right before Fireball's DLL loader rewrite.

Edit: I just remembered that there were no icons for nearly anything. So it was hard navigating, since I couldn't see what was folders and what was files, nor really even what kinds of files.
Last edited by PurpleGurl on Tue Jun 28, 2011 10:35 pm, edited 2 times in total.

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: Revision 52484

Post by vicmarcal »

Hi!
Yup as you said, give a try to the revision before the LDR rewrite. The rewrite has exposed several bugs and maybe it has introduced a couple of them. Now the LDR code is much better. readable and is less buggy than its antecessor.
In the other hand, revisions are not supposed to be stable so I'd recommend to keep them away from the real hardware. If releases are not stable,what can we expect for daily revisions?
Btw, I love this kind of reports, but dont forget to submit this info to bugzilla or it won't be fixed ;)

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

I am not sure what of this to submit to bugzilla.
Everything but old Explorer bugs (non-regressions).
The last time I did that, I got my head chewed off.
Far from that.

User avatar
EmuandCo
Developer
Posts: 4439
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: Revision 52484

Post by EmuandCo »

Your head still seems to Be on its place^^. Well, only duplicates are Not very funny.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

gabrielilardi
Moderator Team
Posts: 873
Joined: Sat Sep 02, 2006 1:30 am
Location: Italy

Re: Revision 52484

Post by gabrielilardi »

The removal of the USB code shows that isn't the only thing causing USB problems. There is bound to be some USB code elsewhere that was left, or I wouldn't have needed to disable the legacy support to get it to let me use my mouse and keyboard properly. If that other code isn't addressed, it may interfere with the new USB 2.x code once it is added.
Afaik, USB legacy support means re-routing USB mouse & keyboard through the BIOS as PS/2 devices, so I guess that what you describe is a normal behavior. You enable USB legacy support when your OS doesn't support USB so you can still use a USB mouse and a USB keyboard with it. It's kind of a contradiction enabling USB legacy support and plugging PS/2 devices. Probably I made some confusion between USB support and Legacy USB support when replying about USB matters in the past, this should clear that up.

PS: PurpleGur: I accidentally deleted your first reply when trying to reply myself, can't get it back sorry.

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

Afaik, USB legacy support means re-routing USB mouse & keyboard through the BIOS as PS/2 devices, so I guess that what you describe is a normal behavior. You enable USB legacy support when your OS doesn't support USB so you can still use a USB mouse and a USB keyboard with it. It's kind of a contradiction enabling USB legacy support and plugging PS/2 devices.
I think it is a bug in ReactOS.

fireball
Developer
Posts: 358
Joined: Tue Nov 30, 2004 10:40 pm
Location: Moscow, Russia
Contact:

Re: Revision 52484

Post by fireball »

I can assure you that all USB related code is (was) in usbdriver.sys
Aleksey Bragin,
ReactOS Project Lead

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Revision 52484

Post by PurpleGurl »

fireball wrote:I can assure you that all USB related code is (was) in usbdriver.sys
Okay, but why must I disable the legacy support in CMOS to get Reactos to use my PS2 devices? That is not Windows behavior. So if there is no buggy USB code left enabled, then why must I still disable USB 1.x in CMOS?

As for the comment about enabling both 1.x support in hardware and using PS/2 devices, Windows has absolutely no problem with it and will happily use both concurrently. I've tried it. It will accept both a HID mouse and a PS2 mouse at the same time and accept input from both, even with ALL USB settings including USB 1.x "legacy mode" enabled in CMOS. (Same applies to keyboards.) However, even now with the USB code removed from trunk, Reactos still requires me to disable USB 1.x support. I can leave all the other settings alone, but if I don't disable that, Reactos won't accept input from PS2 devices. That is clearly not Windows behavior. So if there is no USB support in Reactos, then my USB settings in CMOS should make absolutely no difference.

Of course, at this point, I can leave my 1.x settings disabled, since I don't think I really need that enabled under Windows. So it will make testing more convenient in the future.

I personally think someone ought to double check the entire data path of the mice and keyboards just to make sure some routine isn't getting direct access to USB 1.x stuff or something. Or that would interfere with whatever new stuff that gets added.

Oh, and the "head chewed off" comment is a US colloquialism. That is like getting fussed at vehemently, somewhat similar to insulting, but not quite. That was how it felt when I submitted my first bug report years ago, and I learned not to do it again. Maybe I was oversensitive and mistook directness or terseness with rudeness, and we've all discussed in other threads how that can happen. But I guess if I made a good faith effort to search for whatever in question, it would help. The problem is that not everyone calls everything the same things. I learned that from searching the Microsoft knowledge base. You know what is happening, you look for it, and it isn't there. Then you find your own term on another site used as you meant it, and find others giving the official name, and then you go back to MS and search again and find whatever.

I forgot all I said in the missing post, just that I corrected a point in my original, some reiteration of my first post, and the comments about bug reports. The main regressions I saw were related to icons and memory. And I think I probably should go back pre-LDR rewrite and test there and see if the program I couldn't run will run there. If it does, it could mean the LDR code needs some patching. Then I could move forward a tad to see if that is where it regresses, or back between 51818 and the LDR rewrite if things regressed earlier. The program in question worked fine before, except for not recognizing the left keyboard arrow. The arrow issue could be in the keyboard routines, or it could even be in the disk access (yes, since the key definitions for the game emulator are in a file, and if the file cannot read properly, they could be corrupted). But I say keyboard routines for now, using "Occam's Razor" (start with the simplest explanation) as a guide. But the main concern now is the program no longer working at all.

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

Oh, and the "head chewed off" comment is a US colloquialism. That is like getting fussed at vehemently, somewhat similar to insulting, but not quite. That was how it felt when I submitted my first bug report years ago, and I learned not to do it again. Maybe I was oversensitive and mistook directness or terseness with rudeness, and we've all discussed in other threads how that can happen.
People try to give you advices, but you take it as something insulting.
I personally think someone ought to double check the entire data path of the mice and keyboards just to make sure some routine isn't getting direct access to USB 1.x stuff or something. Or that would interfere with whatever new stuff that gets added.
It will be hard to spot the bug just by inspecting the sources. Somebody should obtain two logs — with enabled and with disabled legacy mode. Maybe a difference between them will shed some light on this problem.

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re:

Post by PurpleGurl »

hto wrote:
People try to give you advices, but you take it as something insulting.

It will be hard to spot the bug just by inspecting the sources. Somebody should obtain two logs — with enabled and with disabled legacy mode. Maybe a difference between them will shed some light on this problem.
A lambasting for reporting a duplicate bug is not "advice," but I now understand the whole story. As a power user, I also have the occasional impatience for newbie types, like back in my BBS hosting days in the 90s. So many times I wanted to tell my users to RTFM (read the [friggin'] manual) back then.

Anyway, thank you for the idea. Maybe I could rig up another machine and try it. I don't promise anything, and I might not have a compatible cable around. I am not even sure I have an OS I can put on the spare PC, but maybe I could put 98 on it, or DOS might do the trick if I have a terminal program. Something like Telix might do the trick. Lets see if I have it right. I just read the debugging wiki a bit. So I would install the specified null modem cable between the ports of the machines, boot the terminal computer with its OS and terminal software, enabling its logging capabilities, and then boot a debug revision of Reactos on the test machine both ways as you suggested? Is that a fair summary, or have I left out any important steps?

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

So I would install the specified null modem cable between the ports of the machines, boot the terminal computer with its OS and terminal software, enabling its logging capabilities, and then boot a debug revision of Reactos on the test machine both ways as you suggested? Is that a fair summary, or have I left out any important steps?
Right, but in this particular case, it should be enough to redirect debug output to a file.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest