Ros-dev July 2008

ros-dev@reactos.org

24 participants
34 discussions

by Alexandru Lovin

Hello everyone, Aleksey suggested that I discuss this here, on the mailing list. First and foremost, these are enhancements to do for later, much later (what I would want for the next release is support for RAID / SCSI controllers). But I know that a developer doesn't actually keep something in his plans unless he's figured out a way to do it. I will paste and add additional comments to each of my suggestions. 1. Compatibility with every version of Windows, from Vista until Windows 3.1/ 3.11 That means applications written for 3.1 should work flawlessly on ReactOS, just like apps written for any other Windows. This is probably not hard, as at least XP does the same thing. However, drivers for Windows 3.1 most probably do not work. If the user actually has hardware that was left unsupported since 3.1, he should be able to use it. The same goes for the combination Vista-only driver / old Windows '95 or Windows 3.1 application. oiaohm said it's not really possible because VxD drivers are not well documented. So, maybe in the distant future, maybe when Linux devs will have reversed VxD's on their own. Just don't forget this. 2. Compatibility with DOS** This will probably not mean DOS drivers, as probably any hardware with DOS drivers also has some sort of Windows drivers. It would only mean application compatibility. However, applications with direct access to hardware will probably have to remain used from within DOS (e.g. BIOS update software). The major thing are games here. The ideal way to run DOS games is: - anything requested by the game is interpreted and passed on to the ROS API - Glide commands are interpreted and passed on to OpenGL or Direct3D, resulting in maybe a better image quality, via the use of features OpenGL has and Glide doesn't. - software rendering requested by games should be interpreted and passed on to OpenGL or Direct3D, again resulting in a better image quality. Of course, this will probably result in a compatibility layer, like you suggested. - redbook audio commands should be passed on to ReactOS, who will read in analog mode or digital mode, depending on what the ROS global settings are for that specific optical drive. My own thing about Descent, quickly: the game tries to access file " 1.midi" but ReactOS plays "1.mp3". I have all the mp3's and will provide them whenever needed in order to make this happen. This will transform the old Descent for DOS in the CD version, that had redbook audio tracks. Such enhancements were also created for Tomb Raider 1, by Paul that created Glidos ( www.glidos.net ). Please see http://www.glidos.net/retext.html?lang=en and http://www.glidos.net/audio.html?lang=en Whenever Tomb Raider 1 asked for certain textures / audio data, it was "hijacked" or "redirected" to the better textures or audio files. Certainly, this DOS compatibility layer would probably need a Glidos-like application to control various specific settings from various DOS applications. Another DOS related thing would be a command prompt (terminal?) in ReactOS that has drag'n'drop, copy and paste functionality. Still oiaohm: for the distant future. Got it, understood it, I just want to convince you to keep it in your plans. oiaohm even said a compatibility layer already exists. 3. Processors as a devices, in Device Manager * * For example, let's say a PC has a Pentium 4 at 3 GHz, with HyperThreading. Windows XP reports this processor as two identical ones in Device Manager. ReactOS should also do that. Apart from Windows, if the user does a right-click on a processor as a device, in the Device Manager tree, and chooses the Properties page of the processor device, that page should also mention the SPEED of the processor. More than that, it would be a blessing to also see the L1, L2 and L3 cache size, FSB and multiplier, like those SiSoft Sandra / Everest applications report. Maybe even further, the instruction sets supported - MMX, 3DNow!, SSE, etc. oiaohm again: can be done, but not right now. Stability and usability beat extra information. Got it, too. Bug 2644. 4. Clustering I discussed this with oiaohm and he said it's doable, as soon as ROS gets Active Directory Server. Only clustered in terms of processing power, the user has more machines in a cluster and he still sees ROS the normal way, it just works faster because there are more processors available. No hard drives in some sort of JBOD, and 3D data is only handled by the "master" machine(otherwise you need about 10 GB/sec between machines), the one the user actually interacts with. This is what he said would be the limitations. I have other details for this, but since it's very far away, it wouldn't make sense to bring them up right now. 5. Driver extraction tool I already got one, DoubleDriver, that backs up the drivers for devices in the device manager. I was thinking about the hardware that only gets drivers from Windows Publisher (like my MSI Starkey 2.0). Users would need one. Again, oiaohm said replicating a freeware tool is not high on the list. I'm fine with that. 6. A Windows Media Center equivalent **WMC doesn't do much. Just lists program schedules, can do scheduled recordings, is able to duplicate streams so that you may record whatever you're watching. It stops suddenly while doing a "record once" capture, when it should have waited for the user to say stop (it happened on Vista Home Premium, on a HP laptop). It has a "touchscreen" kind of interface, that would probably be great on an actual touchscreen, works ok when using a PC remote control, but is kind of stupid when using the mouse. It can record from one channel and let you watch another channel if you have at least two TV tuners in your computer. Naturally, ROS should do this with "n" TV tuners. It doesn't have composite or S-video capturing, like the vast majority of TV tuner software out there. It only captures in Microsoft's special "Microsoft recorded TV Show" format, extension .dvr-ms I think (no AVI capture, no mpg capture). It won't let you specify how the tuner provides sound from the antenna/cable signal to the sound card (PCI audio, internal cable, external cable, and if any of the last two, what sound card channel it is). While watching, it should be easier to find out what channel you're on, and what the time is, via some sort of OSD (on-screen display) that appears when you move the mouse or something, just like in WMC. The recording should not be affected by this (i.e. the OSD shouldn't show up on the recording if you moved the mouse, again just like in WMC). While watching, it's not possible (or at least not easy) to jump directly to a specific channel, it may only be used as a TV (next channel, next channel...). If the user tries to switch channels while recording, he gets "warning, you're recording, if you switch channels it's going to stop, you want that?" It should just stop, or at least let the user specify that he doesn't want to see that message again somehow. It doesn't let the user specify exactly the framerate, video size, video standard...just the country of origin. And, as an example, Romaniaofficially uses the PAL D standard on "air" broadcast, that you can get with an antenna. But cable providers use PAL B, which is the German official standard. So, in WMC a guy with cable from Romania must say he's from Germany or else he won't hear anything! All of these should be properly implemented in ReactOS Media Center. Apart from them, "ROSMC" should have all the deinterlacing options and deinterlacing-method autodetection routines from Dscaler. That program also offers a whole lot of other image improvement things, like a good enough TV station logo killer and image de-noising that actually works. Even better than Dscaler, REMEMBER the settings the next time the user runs the program. Maybe also provide the user with basic video editing functionality, meaning most of the features from VirtualDub (the one I find most important is the ability to edit a film with "direct stream copy", meaning it just copies the video and/or audio stream, it doesn't re-encode it. Edit as in cutting parts of the film. In this scenario, the ability to go frame by frame is also very useful). And since it's the Media Center and not the Media Player, this should be the application that rips audio cd's or audio dvd's. Most of all, it should be "cluster-aware." Regardless of ROS being cluster aware or not, this one should be. oiaohm said this is not your job, but a job for other projects. He pointed me to MediaPortal. I e-mailed all of them (Virtualdub, Dscaler and MediaPortal) but I doubt they'll combine the three projects. Still, that's why John User still buys Windows. Linux is all over the Internet (docs all over forums, drivers all over sites, applications all over sites as well). Instead, Linux has "cool" stuff like "mousespedometa" (measures the speed with which you move the mouse). Some people don't even have Internet to get what they need (X servers, for instance). To be a Windows alternative, it should contain a lot of things Windows has. 7. Running on 16-bit systems like 286/386/486 in a "ReactOS Essentials" (equivalent to a stripped-down XP) mode * * It should be the same operating system, but in 16-bit mode only. That's an ideal scenario and I'm sure it cannot be done no matter how good the programmers are. So, what can someone do on a 286 ? Listen to mp3's ? No way. Listen to audio CD's, yes, and hopefully digital playback, too. Watch TV ? Yes, if the user can find an ISA TV tuner (ATI made such tuners, but they required a PCI ATI video card, and if you have PCI why not get a better tuner?). Record TV shows ? Not on that kind of computer. Browse the internet ? That may be possible, with some really outdated, 16-bit browser, like the Internet Explorer for Windows 3.1. And I don't know how many sites will work on it. Play games ? Yes, either old DOS or Windows 3.1 ones or the ones that come with ReactOS, written in 16-bit especially for this mode. Join a hive as either master or slave ? Hopefully it will be possible, but probably in the year 2015 at least. Use office applications ? Sure, if the user can find that last Microsoft Office or maybe Microsoft Works version compatible with Windows 3.1. Run a web server ? I know a guy who had a server running on a 386 system, on Windows 3.11. So yes, it is possible, only I don't know what software he used to actually serve the data. Act as a router ? Again, hopefully. That is, if the entire network is on 10 megabit, because I don't think there are ISA 100 megabit network cards (ISA bandwith is not enough). 2D graphics ? It was possible in Windows 3.1, why not ? Maybe the first Photoshop versions actually were 16-bit. 3D graphics ? The first 3D Studio Max (that is, 3D Studio) was for DOS only. That probably means 16-bit right from the start, and that should mean yes, you can do it, with the DOS compatibility layer. Web design ? If you can find a 16-bit application, yes. A separate ReactOS for 16-bit only, or just all the 16-bit functionality included in the normal ReactOS ? Things look better when it works out of the box, but it's a waste of space to include applications written for 16-bit only. People that really need the 16-bit version will not mind paying extra attention to actually download this one and not the normal one. Besides that, ReactOS is free. And the presence of such a version would mean a selfless devotion to people. An act of charity for real. Allowing people to use their computers and do as many modern things as possible on them. An open source Windows 3.11 with better compatibility and adherence to standards. Compatible with all the 9x and ME. Has been tried in Free Win 95, oiaohm said "dead and staying that way" about it, but maybe VxD documentation and whatever else you would need will appear (or be reverse engineered by someone). Once a bigger effort will be done, the missing info is probably easier to uncover. Those are my suggestions. They are not for now, they are not easy to do, etc. Just don't discard them, please. Alex

16 years, 8 months

Call for participation: ReactOSDbg

by art yerkes

I've written a shell to use with ReactOS' KDBG that gives a more accurate view of what's going on than other methods available to us (it automatically grabs the module list and loads source files as appropriate, shows locals etc) It's not complete yet, and I'm hoping that others will want to participate in working on it. Therefore, I'm asking those with C# experience on windows who want to get involved to lend a hand in adding the remaining features: - abstract pipe implementation for serial ports and windows named pipes - managing breakpoints - type decoding and struct display using the info available from dbghelp - thread and process listing and focus - a 'watch' window and watchpoints - clipboard interaction - annontated disassembly - general features (bugzilla reporting, automatic interaction with rospaste) To work on this, you don't need to be a wizard, just familiar with windows forms development in C# and willing to learn a thing or two along the way, along with a vm to intstall reactos in and beat up on :-) Some day we'll have everything working with windows style kernel debugging, but until then I feel that a superior stopgap is valuable. -- art yerkes <ayerkes(a)speakeasy.net>

16 years, 10 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 34970: - update KPCR and KIPCR - add KeGetPcr() and update KeGetCurrentProcessorNumber

by Alex Ionescu

Kinda curious why you have "unknowns" in a documented structure. On 30-Jul-08, at 7:17 PM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Wed Jul 30 21:16:59 2008 > New Revision: 34970 > > URL: http://svn.reactos.org/svn/reactos?rev=34970&view=rev > Log: > - update KPCR and KIPCR > - add KeGetPcr() and update KeGetCurrentProcessorNumber > > Modified: > branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > > Modified: branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu… > = > = > = > = > = > = > = > = > ====================================================================== > --- branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > [iso-8859-1] (original) > +++ branches/ros-amd64-bringup/reactos/include/ddk/winddk.h > [iso-8859-1] Wed Jul 30 21:16:59 2008 > @@ -5516,23 +5516,38 @@ > > typedef struct _KPCR > { > - NT_TIB NtTib; > - struct _KPRCB *CurrentPrcb; > - ULONG64 SavedRcx; > - ULONG64 SavedR11; > + union > + { > + NT_TIB NtTib; > + struct > + { > + union _KGDTENTRY64 *GdtBase; > + struct _KTSS64 *TssBase; > + ULONG64 UserRsp; > + struct _KPCR *Self; > + struct _KPRCB *CurrentPrcb; > + PKSPIN_LOCK_QUEUE LockArray; > + PVOID Used_Self; > + }; > + }; > + union _KIDTENTRY64 *IdtBase; > + ULONG64 Unused[2]; > KIRQL Irql; > UCHAR SecondLevelCacheAssociativity; > - UCHAR Number; > + UCHAR ObsoleteNumber; > UCHAR Fill0; > - ULONG Irr; > - ULONG IrrActive; > - ULONG Idr; > + ULONG Unused0[3]; > USHORT MajorVersion; > USHORT MinorVersion; > ULONG StallScaleFactor; > - union _KIDTENTRY64 *IdtBase; > - union _KGDTENTRY64 *GdtBase; > - struct _KTSS64 *TssBase; > + PVOID Unused1[3]; > + ULONG KernelReserved[15]; > + ULONG SecondLevelCacheSize; > + ULONG HalReserved[16]; > + ULONG Unused2; > + PVOID KdVersionBlock; > + PVOID Unused3; > + ULONG PcrAlign1[24]; > } KPCR, *PKPCR; > > typedef struct _KFLOATING_SAVE { > @@ -5552,10 +5567,17 @@ > VOID); > > FORCEINLINE > +PKPCR > +KeGetPcr(VOID) > +{ > + return (PKPCR)__readgsqword(FIELD_OFFSET(KPCR, Self)); > +} > + > +FORCEINLINE > ULONG > KeGetCurrentProcessorNumber(VOID) > { > - return (ULONG)__readgsbyte(FIELD_OFFSET(KPCR, Number)); > + return (ULONG)__readgsword(0x184); > } > > #elif defined(__PowerPC__) > > Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/ > ketypes.h > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu… > = > = > = > = > = > = > = > = > ====================================================================== > --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > [iso-8859-1] (original) > +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h > [iso-8859-1] Wed Jul 30 21:16:59 2008 > @@ -635,41 +635,42 @@ > NT_TIB NtTib; > struct > { > - struct _EXCEPTION_REGISTRATION_RECORD > *Used_ExceptionList; > - PVOID Used_StackBase; > - PVOID PerfGlobalGroupMask; > - PVOID TssCopy; > - ULONG ContextSwitches; > - KAFFINITY SetMemberCopy; > + union _KGDTENTRY64 *GdtBase; > + struct _KTSS64 *TssBase; > + ULONG64 UserRsp; > + struct _KPCR *Self; > + struct _KPRCB *CurrentPrcb; > + PKSPIN_LOCK_QUEUE LockArray; > PVOID Used_Self; > }; > }; > - struct _KPCR *Self; > - struct _KPRCB *Prcb; > + union _KIDTENTRY64 *IdtBase; > + ULONG64 Unused[2]; > KIRQL Irql; > - ULONG IRR; > - ULONG IrrActive; > - ULONG IDR; > - PVOID KdVersionBlock; > - PKIDTENTRY IDT; > - PKGDTENTRY GDT; > - struct _KTSS *TSS; > + UCHAR SecondLevelCacheAssociativity; > + UCHAR ObsoleteNumber; > + UCHAR Fill0; > + ULONG Unused0[3]; > USHORT MajorVersion; > USHORT MinorVersion; > - KAFFINITY SetMember; > ULONG StallScaleFactor; > - UCHAR SparedUnused; > - UCHAR Number; > - UCHAR Reserved; > - UCHAR L2CacheAssociativity; > - ULONG VdmAlert; > - ULONG KernelReserved[14]; > + PVOID Unused1[3]; > + ULONG KernelReserved[15]; > ULONG SecondLevelCacheSize; > ULONG HalReserved[16]; > - ULONG InterruptMode; > - UCHAR Spare1; > - ULONG KernelReserved2[17]; > - KPRCB PrcbData; > + ULONG Unused2; > + ULONG Fill1; > + PVOID KdVersionBlock; // 0x108 > + PVOID Unused3; > + ULONG PcrAlign1[24]; > + > + ULONG Unknown1; // 0x178 > + ULONG Unknown2; > + ULONG Unknown3; > + USHORT CpuNumber; // 0x184 > + // hack: > + ULONG ContextSwitches; > + > } KIPCR, *PKIPCR; > #pragma pack(pop) > > Best regards, Alex Ionescu

16 years, 10 months

Re: [ros-dev] ARM Guy Broke BOOT on Real Hardware

by tamlin＠algonet.se

Alex wrote: >It looks like a guarded mutex is being acquired at DPC level. That's >pretty bad. Well, at least it's redundant and useless. :-) >Pushlocks shouldn't be acquired at DPC level either Indeed. If "you" are at DPC level, you have but one synchronization to care about - SMP (i.e. CPU<->CPU). >, but there's no >ASSERTs in the pushlock code that check for that. An oversight that should be fixed, I'm sure (even if it happened to slow down the system by a whole order of magnitude, which it won't). >MMProbeAndLockPages should never be called for paged pool addreses >while at DPC level, Should MmProbeAndLock ever be called at IRQL above APC level? I mean, what if the probing fails? Should the paging executive somehow preempt this call and page in the missing pages (or should it simply throw a "page not present" exception - not too great to do at DPC level I'd say)? >which means the driver probably called it for a >non-paged pool address. If my previous suspicion is correct, I build on that and suspect this is an error in itself. The ProbeAndLock call should be done at APC level (though I may be completely wrong, but do read my finishing line). >In that case, the whole loop about checking if the page is present and >then faulting it in is irrelevant, and won't happen. Right. Page fault at DPC level == Bad Move(tm). -- Mike

16 years, 10 months

Re: [ros-dev] [ros-diffs] [hpoussin] 34856: Revert r34848 and r34850, and replace them by a real fix (hinted by Colin Finck)

by Alex Ionescu

This breaks compiling on Mac OS X... I haven't been able to build since this patch, because now it tries to include windows.h. On 27-Jul-08, at 12:39 PM, hpoussin(a)svn.reactos.org wrote: > Author: hpoussin > Date: Sun Jul 27 14:39:05 2008 > New Revision: 34856 > > URL: http://svn.reactos.org/svn/reactos?rev=34856&view=rev > Log: > Revert r34848 and r34850, and replace them by a real fix (hinted by > Colin Finck) > > Modified: > trunk/reactos/Makefile > trunk/reactos/tools/sysreg/namedpipe_reader.cpp > trunk/reactos/tools/sysreg/os_support.cpp > trunk/reactos/tools/sysreg/os_support.h > trunk/reactos/tools/sysreg/rosboot_test.cpp > trunk/reactos/tools/sysreg/rosboot_test.h > trunk/reactos/tools/sysreg/user_types.h > > Modified: trunk/reactos/Makefile > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/Makefile?rev=34856&r1=3485… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/Makefile [iso-8859-1] (original) > +++ trunk/reactos/Makefile [iso-8859-1] Sun Jul 27 14:39:05 2008 > @@ -182,8 +182,8 @@ > endif > else > HOST=mingw32-linux > -HOST_CFLAGS+=-fshort-wchar -D__LINUX__ > -HOST_CPPFLAGS+=-fshort-wchar -D__LINUX__ > +HOST_CFLAGS+=-fshort-wchar > +HOST_CPPFLAGS+=-fshort-wchar > endif > endif > > > Modified: trunk/reactos/tools/sysreg/namedpipe_reader.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/sysreg/namedpipe_rea… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/tools/sysreg/namedpipe_reader.cpp [iso-8859-1] > (original) > +++ trunk/reactos/tools/sysreg/namedpipe_reader.cpp [iso-8859-1] Sun > Jul 27 14:39:05 2008 > @@ -14,7 +14,7 @@ > { > #define MIN(a, b) (((a) < (b)) ? (a) : (b)) > > -#ifdef __LINUX__ > +#ifdef __linux__ > const char * NamedPipeReader::s_LineBreak = "\x0A\0"; > #else > const char * NamedPipeReader::s_LineBreak = "\x0D\x0A\0"; > @@ -46,7 +46,7 @@ > cerr << "NamedPipeReader::openPipe> pipe already open" > << endl; > return false; > } > -#ifndef __LINUX__ > +#ifndef __linux__ > h_Pipe = CreateFile(PipeCmd.c_str(), > GENERIC_WRITE | GENERIC_READ, > 0, > @@ -105,7 +105,7 @@ > cerr << "NamedPipeReader::closePipe> pipe is not open" > << endl; > return false; > } > -#ifdef __LINUX__ > +#ifdef __linux__ > close(h_Pipe); > #else > DisconnectNamedPipe(h_Pipe); > @@ -274,7 +274,7 @@ > bool NamedPipeReader::readPipe(char * buffer, int bufferlength, > long & bytesread) > { > > -#ifdef __LINUX__ > +#ifdef __linux__ > long cbRead = read(h_Pipe, > buffer, > (bufferlength-1) * sizeof(char)); > > Modified: trunk/reactos/tools/sysreg/os_support.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/sysreg/os_support.cp… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/tools/sysreg/os_support.cpp [iso-8859-1] (original) > +++ trunk/reactos/tools/sysreg/os_support.cpp [iso-8859-1] Sun Jul > 27 14:39:05 2008 > @@ -38,7 +38,7 @@ > } > } > > -#ifdef __LINUX__ > +#ifdef __linux__ > if (s_Entries.size()) > { > long secs = s_Entries[i]->tm.tv_sec - tm.tv_sec; > @@ -54,7 +54,7 @@ > void OsSupport::cancelAlarms() > { > > -#ifndef __LINUX__ > +#ifndef __linux__ > if (s_hThread) > { > TerminateThread(s_hThread, 0); > @@ -73,7 +73,7 @@ > } > > > -#ifndef __LINUX__ > +#ifndef __linux__ > > HANDLE OsSupport::s_hThread = 0; > static HANDLE hTimer; > > Modified: trunk/reactos/tools/sysreg/os_support.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/sysreg/os_support.h?… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/tools/sysreg/os_support.h [iso-8859-1] (original) > +++ trunk/reactos/tools/sysreg/os_support.h [iso-8859-1] Sun Jul 27 > 14:39:05 2008 > @@ -10,7 +10,7 @@ > * PROGRAMMERS: Johannes Anderwald (johannes.anderwald at sbox > tugraz at) > */ > > -#ifndef __LINUX__ > +#ifndef __linux__ > #include <windows.h> > #else > #include <unistd.h> > @@ -140,7 +140,7 @@ > OsSupport() > {} > > -#ifdef __LINUX__ > +#ifdef __linux__ > static struct sigaction s_sact; > #else > static HANDLE s_hThread; > > Modified: trunk/reactos/tools/sysreg/rosboot_test.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/sysreg/rosboot_test.… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/tools/sysreg/rosboot_test.cpp [iso-8859-1] > (original) > +++ trunk/reactos/tools/sysreg/rosboot_test.cpp [iso-8859-1] Sun Jul > 27 14:39:05 2008 > @@ -46,7 +46,7 @@ > string RosBootTest::XEN_CONFIG_FILE = "XEN_CONFIG_FILE"; > string RosBootTest::XEN_CONFIG_NAME = "XEN_CONFIG_NAME"; > > -#ifdef __LINUX__ > +#ifdef __linux__ > string RosBootTest::ROS_EMU_PATH = "ROS_EMU_PATH_LIN"; > #else > string RosBootTest::ROS_EMU_PATH = "ROS_EMU_PATH_WIN"; > @@ -117,7 +117,7 @@ > img = "output-i386"; > > EnvironmentVariable::getValue("ROS_OUTPUT", img); > -#ifdef __LINUX__ > +#ifdef __linux__ > img += "/ros.hd"; > #else > img += "\\ros.hd"; > @@ -159,7 +159,7 @@ > } > > > -#ifdef __LINUX__ > +#ifdef __linux__ > qemuimgdir += "/qemu-img"; > > #else > @@ -176,7 +176,7 @@ > const char * options[] = {NULL, > "create", > "-f", > -#ifdef __LINUX__ > +#ifdef __linux__ > "raw", > #else > "vmdk", > @@ -241,7 +241,7 @@ > { > string::size_type pos; > > -#ifdef __LINUX__ > +#ifdef __linux__ > pos = m_EmuPath.find_last_of("/"); > #else > pos = m_EmuPath.find_last_of("\\"); > @@ -266,7 +266,7 @@ > m_MaxMem = "64"; > } > > -#ifdef __LINUX__ > +#ifdef __linux__ > > if (mktemp(pipename)) > { > @@ -332,7 +332,7 @@ > return false; > } > > -#ifdef __LINUX__ > +#ifdef __linux__ > /* on linux we need get pid in order to be able > * to terminate the emulator in case of errors > * on windows we can get pid as return of > CreateProcess > @@ -369,7 +369,7 @@ > { > pipe = pipe.substr(0, pos); > } > -#ifdef __LINUX__ > +#ifdef __linux__ > m_Src = pipe; > #else > m_Src = "\\\\.\\pipe\\" + pipe.substr(0, pos); > @@ -577,7 +577,7 @@ > return false; > } > } > -#ifdef __LINUX__ > +#ifdef __linux__ > if (mkfifo(m_Src.c_str(), 400)) > { > /* > @@ -802,7 +802,7 @@ > cleanup(conf_parser); > return false; > } > -#ifdef __LINUX__ > +#ifdef __linux__ > /* > * For linux systems we can only > * check if the emulator runs by > @@ -832,7 +832,7 @@ > } > #endif > OsSupport::cancelAlarms(); > -#ifdef __LINUX__ > +#ifdef __linux__ > // OsSupport::setAlarm (m_MaxTime, m_Pid); > // OsSupport::setAlarm(m_MaxTime, getpid()); > #else > > Modified: trunk/reactos/tools/sysreg/rosboot_test.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/sysreg/rosboot_test.… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/tools/sysreg/rosboot_test.h [iso-8859-1] (original) > +++ trunk/reactos/tools/sysreg/rosboot_test.h [iso-8859-1] Sun Jul > 27 14:39:05 2008 > @@ -30,12 +30,12 @@ > #include <cstdlib> > #include <cstring> > #include <ctime> > -#ifndef __LINUX__ > +#ifndef __linux__ > #include <io.h> > #include <errno.h> > #endif > > -#ifdef __LINUX__ > +#ifdef __linux__ > #include <unistd.h> > #include <sys/types.h> > #if defined(__FreeBSD__) || defined(__APPLE__) > > Modified: trunk/reactos/tools/sysreg/user_types.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/sysreg/user_types.h?… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/tools/sysreg/user_types.h [iso-8859-1] (original) > +++ trunk/reactos/tools/sysreg/user_types.h [iso-8859-1] Sun Jul 27 > 14:39:05 2008 > @@ -13,7 +13,7 @@ > #include <string> > #include <iostream> > > -#ifndef __LINUX__ > +#ifndef __linux__ > #define popen _popen > #define pclose _pclose > #endif > Best regards, Alex Ionescu

16 years, 10 months

ARM Guy Broke BOOT on Real Hardware

by James Tabor

Hi ARMs, Doing a good job BTW~ Thanks, James (ntoskrnl/kd/kdio.c:191) ----------------------------------------------------- (ntoskrnl/kd/kdio.c:192) ReactOS 0.4-SVN (Build 20080728-r34871) (ntoskrnl/kd/kdio.c:193) Command Line: DEBUG DEBUGPORT=COM1 BUADRATE=115200 SOS (ntoskrnl/kd/kdio.c:194) ARC Paths: multi(0)disk(0)rdisk(0)partition(1) \ multi(0)disk(0)rdisk(0)parti tion(1) \ReactOS\ Used memory 1015348Kb (ntoskrnl/mm/mminit.c:295) Start End Type (ntoskrnl/mm/mminit.c:296) 0x80000000 - 0x80800000 Undefined region (ntoskrnl/mm/mminit.c:299) 0x80800000 - 0x80E00000 FreeLDR Kernel mapping region (ntoskrnl/mm/mminit.c:302) 0x80E00000 - 0x815C0000 PFN Database region (ntoskrnl/mm/mminit.c:309) 0x815C0000 - 0x879C0000 Non paged pool region (ntoskrnl/mm/mminit.c:312) 0x879C0000 - 0x8DDC0000 Paged pool region (ntoskrnl/ke/i386/kiinit.c:47) Large Page support detected but not yet taken advantage of! WARNING: KdDebuggerInitialize1 at drivers/base/kdcom/i386/kdbg.c:489 is UNIMPLEMENTED! WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is UNIMPLEMENTED! WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is UNIMPLEMENTED! (ntoskrnl/io/iomgr/driver.c:1356) '\Driver\BUSLOGIC' initialization failed, status (0xc00000c0) (ntoskrnl/io/iomgr/driver.c:1356) '\Driver\Floppy' initialization failed, status (0xc000000e) Assertion 'KeGetCurrentIrql()<=(1)' failed at ntoskrnl/ke/gmutex.c line 201 Entered debugger on embedded INT3 at 0x0008:0x808a8262. kdb:> bt Eip: <NTOSKRNL.EXE:a8263 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:a027 (ntoskrnl/ke/gmutex.c:201 (@KeAcquireGuardedMutex@4))> <NTOSKRNL.EXE:6d3a2 (ntoskrnl/include/internal/mm.h:1556 (MmProbeAndLockPages@12))> <NTOSKRNL.EXE:4f079 (ntoskrnl/io/iomgr/irp.c:694 (IoBuildAsynchronousFsdRequest@24))> <SCSIPORT.SYS:4671 (drivers/storage/scsiport/scsiport.c:3959 (ScsiPortDpcForIsr@16))> <NTOSKRNL.EXE:823a (ntoskrnl/ke/dpc.c:474 (@KiRetireDpcList@4))> <NTOSKRNL.EXE:9fc59 (ntoskrnl/ke/i386/ctxswitch.S:691 (@KiIdleLoop@0))> <00000000> kdb:>

16 years, 10 months

Re: [ros-dev] [ros-diffs] [pschweitzer] 34860: Fixed some kernel exports

by Alex Ionescu

I would've hoped the ARM guys made it painfully clear by now that ARM functions do not have @xx appended to their names... Author: ros-arm-bringup Date: Sun Jul 27 00:37:54 2008 New Revision: 34820 URL: http://svn.reactos.org/svn/reactos?rev=34820&view=rev Log: - Stop adding those damn @ decorations to ARM builds. Among many others... On 27-Jul-08, at 2:19 PM, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Sun Jul 27 16:19:15 2008 > New Revision: 34860 > > URL: http://svn.reactos.org/svn/reactos?rev=34860&view=rev > Log: > Fixed some kernel exports > > Modified: > branches/pierre-fsd/ntoskrnl/ntoskrnl_arm.def > branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def > > Modified: branches/pierre-fsd/ntoskrnl/ntoskrnl_arm.def > URL: http://svn.reactos.org/svn/reactos/branches/pierre-fsd/ntoskrnl/ntoskrnl_ar… > = > = > = > = > = > = > = > = > ====================================================================== > --- branches/pierre-fsd/ntoskrnl/ntoskrnl_arm.def [iso-8859-1] > (original) > +++ branches/pierre-fsd/ntoskrnl/ntoskrnl_arm.def [iso-8859-1] Sun > Jul 27 16:19:15 2008 > @@ -187,10 +187,10 @@ > FsRtlDeleteKeyFromTunnelCache > FsRtlDeleteTunnelCache > FsRtlDeregisterUncProvider > -FsRtlDissectDbcs > -FsRtlDissectName > -FsRtlDoesDbcsContainWildCards > -FsRtlDoesNameContainWildCards > +FsRtlDissectDbcs@16 > +FsRtlDissectName@16 > +FsRtlDoesDbcsContainWildCards@4 > +FsRtlDoesNameContainWildCards@4 > FsRtlFastCheckLockForRead > FsRtlFastCheckLockForWrite > FsRtlFastUnlockAll > > Modified: branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def > URL: http://svn.reactos.org/svn/reactos/branches/pierre-fsd/ntoskrnl/ntoskrnl_i3… > = > = > = > = > = > = > = > = > ====================================================================== > --- branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def [iso-8859-1] > (original) > +++ branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def [iso-8859-1] Sun > Jul 27 16:19:15 2008 > @@ -204,9 +204,9 @@ > FsRtlDeleteKeyFromTunnelCache > FsRtlDeleteTunnelCache > FsRtlDeregisterUncProvider > -FsRtlDissectDbcs > +FsRtlDissectDbcs@16 > FsRtlDissectName@16 > -FsRtlDoesDbcsContainWildCards > +FsRtlDoesDbcsContainWildCards@4 > FsRtlDoesNameContainWildCards@4 > FsRtlFastCheckLockForRead > FsRtlFastCheckLockForWrite > Best regards, Alex Ionescu

16 years, 10 months

[ros-diffs] [jimtabor] 34807: - Attempt to initiate hook set from kernel space.

by James Tabor

Hi, Here is a test program to play with, tell me what is wrong. 8^D James Ref info and download the program: http://www.klenotic.com/pl/null_hhook/ http://www.klenotic.com/pl/null_hhook/HookChainTest100.zip

16 years, 10 months

widl problem importing stdole2.tlb

by Steven Edwards

Hi, I've been attempting to sync some of the Wine dlls, namely the IE support dlls and have run in to a bit of a problem which I think is a bug in ReactOS widl. It seems that the import keyword is not working. When trying to build shdocvw.dll it creates a shdocvw_v1.tlb based on shdocvw_v1.idl which imports exdisp.idl from the SDK which in turn does an import ("stdole2.tlb") As you can see from the output below sedwards@mini-gimli:~/source/reactos$ make shdocvw [WIDL] obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb error: Could not open importlib stdole2.tlb. mingw32-make: *** [obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb] Error 2 Total Build Time: 00:00:02 Notice the . at the end of stdole2.tlb? I've tried just renaming the typelib and putting it in several intermediate folders to no effect. If any WIDL Guru can help please find the attached patch which contains an updated shdocvw.rbuild Thanks Steven -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

16 years, 10 months

kernel32

by gedmurphy

Yesterday I was playing around with the test suite in HEAD when I moved onto kernel32. It was, without wanting to sound too harsh, a bit of a disgrace, with large failures throughout the whole test range. I suggest a hacking day on it using the test suite, a joint effort to bring this core lib back into line. Perhaps with some emphasis on trying to make it fun. Whoever gets the most fixes is crowned 'king ding-a-ling' and holds the title until the next one, opening the road up to days on ntdll, user32, gdi32 and crt? Ged.

16 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev July 2008