- Ros-dev - ReactOS.org

Revision 66026 - Directory Listing Modified Sun Jan 11 14:38:26 2015 UTC (3 days, 7 hours ago) by dreimer [RAPPS] Database Update. This fixes the now dead LibreOffice link, too. I completely skipped MirandaIM because they suck by deciding to do the same shit, Filezilla did. SF Malware "optimized" installer!
by Javier Agustìn Fernàndez Arroyo 19 Jan '15

19 Jan '15

Hello Daniel, There are links to filezilla which doesnt lead to the malware installer shit. This link ends with ".../download?nowrap" maybe adding this works for MirandaIM too http://sourceforge.net/projects/filezilla/files/FileZilla_Client/3.10.0.1/F…

3 4

Installing ReactOS to a folder
by João Jerónimo 19 Jan '15

19 Jan '15

Hello, Is there a build command to install ReactOS to a folder. Something equivalent to "make install" of good old RBuild days? I used to install ReactOS on real hardware this way, because it allowed me to have more control over the install process (aka control it completely). Thanks, João Jerónimo

6 8

LDAP going live
by Colin Finck 18 Jan '15

18 Jan '15

Hi all, After finally setting up replication slaves for redundancy, our LDAP setup went live today! BuildBot and all SVN repositories now authenticate against a shared user directory. If everything went well, you shouldn't notice a difference :) Except that you can now change your SVN password yourself at https://lam.reactos.org Keep your credentials safe. We can now easily add more ReactOS developer services like file sharing and Mumble without needing to duplicate all user information. And we will do so! Cheers, Colin

1 0

Could someone take over CORE-7864?
by David Quintana (gigaherz) 15 Jan '15

15 Jan '15

Link, for ease of access: https://jira.reactos.org/browse/CORE-7864 The bug was assigned to me a while ago, but this seems to be primarily win32k issues, which are outside my area of expertise. Someone else may be able to handle it better.

1 0

ReactOS Hybrid-USB Key attempt
by Hermès BÉLUSCA - MAÏTO 15 Jan '15

15 Jan '15

Hi all ! In this video : https://drive.google.com/file/d/0BzFtJhksW7viRDRVMzluTnFjMlU/view?usp=sharin g (with strong French accent, sorry :P, and it was my first attempt at making a video with a camera in one hand while doing the other things with the other hand ^^), I show an attempt to create a hybrid-USB key by configuring freeldr to load either a livecd (shown in the video) or a bootcd in ramdisk. Many remarks are in order: - theres a crash when booting the bootcd image, early in phase 1 boot in Io (can be reproduced locally on vbox for example, with similar freeldr.ini parameters that I show in the video). - the whole story consists in loading a ramdisk, so I avoid all the USB-related storage problems we could (and certainly) encounter if I used the USB key more like as we do for our current livecds, i.e. permanent reads to the removable device. - a ROS livecd that can be removable (in the sense that one can use another cd to test something, while ROS is still running) should be done with some kind of hdd image file instead, that is then loaded in memory (so that we can then read and write to this virtual drive). - something weird happens when freeldr loads the livecd iso in memory: first it takes 7 minutes to just try to open the iso file, and then 7 other minutes to load the iso proper. This problem needs to be investigated. - we still report strange dates when listing files from the livecd (at least when it is mounted as ramdisk), see the video. - finally, when using Standard PC (non-ACPI) HAL, I dont really think we reposition HDD heads into sleep position, because when I switch PC power off with the button I can hear the HDD making the noise of the heads quickly going back to sleep position, whereas I dont think this should happen if the heads were being already in the correct position before I switch power off (when using the shutdown command of FreeDOS, the other OS I have installed in the PC, the noise isnt produced). Cheers, Hermès. PS: I keep the right to remove the video at any time if I notice misuses. And its not an official video (even if I was playing around with Windows Movie Maker with the ReactOS logo during the first seven seconds, and with the website links at the end) !!

4 4

Downtime tomorrow at noon CET
by Pierre Schweitzer 14 Jan '15

14 Jan '15

Dear all, Due to a hard disk dying, we'll attempt to anticipate its total death tomorrow at noon CET to change it before it quits working. It is a disk in one of our hypervisor. The following services will be hit: -> ReactOS main website -> Jira/Fisheye -> Main DNS server -> ReactOS community website Sorry for the caused inconvenience. With my best regards, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

2 1

Bulk ordering USB flash drives for exhibitions - call to action
by Colin Finck 12 Jan '15

12 Jan '15

Hi all, As more and more computers these days come without optical drives, we're thinking about switching from ReactOS CD giveaways to USB flash drive giveaways on exhibitions (like this month's FOSDEM). ReactOS would then come preinstalled in a VM on these drives. When ReactOS' USB support gets better, we may even think about making these drives bootable. Now the prices for 1GB USB drives haven't quite reached the costs of blank CDs yet. Also many countries put a high fee on USB drives, because you will for sure always use them to pirate copyrighted work... For example, we're talking about a fee of 1€/unit here in Germany. Germany is fair enough though to not apply the fee if you're ordering from outside Germany. Maybe this also works the other way round, i.e. we as ReactOS Deutschland e.V. order USB drives from another European country and don't have to pay this fee. Sooo, who of you knows a good supplier in your (European) country for bulk ordering USB drives with the best per-unit price? Even better if your supplier can print a custom logo on these drives. Depending on the price, we're talking about 50-200 drives here. Reply on the forum please: https://reactos.org/forum/viewtopic.php?f=2&t=13917 Thanks for your help in making a great ReactOS presentation at exhibitions! - Colin

6 7

Re: [ros-dev] [ros-diffs] [hbelusca] 66022: [FREELDR]: Commit a temporary "hackfix" for (Pc)GetTime: on VBox when booting with PXE, for some mysterious reason, Int386(0x1A) call with AH = 0x02 (Get CMOS Time) *never ever* r...
by Pierre Schweitzer 10 Jan '15

10 Jan '15

From our investigations (Timo & I), there seems to be a memory corruption when using a PXE boot on VBox. You're committing a hack to workaround this memory corruption (which replaces code which seems correct by some other code which is probably correct), which lets you go a little bit further, where memory corruption seems to strike again. And thus, this doesn't bring PXE boot in better shape. Furthermore, it appears that you're working around a bug which isn't in ReactOS but in VBox. As a reminder, PXE boot works fine with Qemu, with VMware. And when changing the ROM of VBox [1], then PXE boot works on VBox as well. Revert and report to VirtualBox instead. Our code is correct. Thanks to Timo & Hervé for their help on digging into this issue. [1]: https://git.ipxe.org/ipxe.git/blob/HEAD:/src/config/vbox/README On 10/01/2015 01:21, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sat Jan 10 00:21:33 2015 > New Revision: 66022 > > URL: http://svn.reactos.org/svn/reactos?rev=66022&view=rev > Log: > [FREELDR]: Commit a temporary "hackfix" for (Pc)GetTime: on VBox when booting with PXE, for some mysterious reason, Int386(0x1A) call with AH = 0x02 (Get CMOS Time) *never ever* returns!! (however without PXE everything works). So... is it some kind of stack overflow or whatever that makes the Int386 function stack messy? Or something else? So in the meantime we use direct CMOS port reads. Timo, Hervé (and others), can you please review? And in particular why does it happen only with PXE? > > Modified: > trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1] Sat Jan 10 00:21:33 2015 > @@ -20,10 +20,50 @@ > > #define BCD_INT(bcd) (((bcd & 0xf0) >> 4) * 10 + (bcd &0x0f)) > > +#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED > + > +/* CMOS Registers and Ports */ > +#define CMOS_CONTROL_PORT (PUCHAR)0x70 > +#define CMOS_DATA_PORT (PUCHAR)0x71 > + > +#define RTC_REGISTER_A 0x0A > +#define RTC_REG_A_UIP 0x80 > + > +static UCHAR > +HalpReadCmos(IN UCHAR Reg) > +{ > + /* Select the register */ > + WRITE_PORT_UCHAR(CMOS_CONTROL_PORT, Reg); > + > + /* Query the value */ > + return READ_PORT_UCHAR(CMOS_DATA_PORT); > +} > + > +#endif > + > TIMEINFO* > PcGetTime(VOID) > { > static TIMEINFO TimeInfo; > + > +#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED > + > + /* Loop while update is in progress */ > + while ((HalpReadCmos(RTC_REGISTER_A)) & RTC_REG_A_UIP); > + > + /* Set the time data */ > + TimeInfo.Second = BCD_INT(HalpReadCmos(0)); > + TimeInfo.Minute = BCD_INT(HalpReadCmos(2)); > + TimeInfo.Hour = BCD_INT(HalpReadCmos(4)); > + TimeInfo.Day = BCD_INT(HalpReadCmos(7)); > + TimeInfo.Month = BCD_INT(HalpReadCmos(8)); > + TimeInfo.Year = BCD_INT(HalpReadCmos(9)); > + > + /* Compensate for the century field */ > + TimeInfo.Year += (TimeInfo.Year > 80) ? 1900: 2000; > + > +#else > + > REGS Regs; > > for (;;) > @@ -86,6 +126,9 @@ > > break; > } > + > +#endif > + > return &TimeInfo; > } > > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 65997: [SPEC2DEF]: Turn the tab character into its control code. Timo, is this tab really needed for ARM stubs, or not? (in that case maybe removing it would be better?)
by Timo Kreuzer 08 Jan '15

08 Jan '15

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 65982: [FREELDR] - Correctly append a backslash to the BootPath (if needed). - Be able to specify relative boot paths (relative to the current boot device): as a consequence, remove the ...
by Pierre Schweitzer 05 Jan '15

05 Jan '15

On 05/01/2015 00:49, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sun Jan 4 23:49:18 2015 > New Revision: 65982 > > URL: http://svn.reactos.org/svn/reactos?rev=65982&view=rev > Log: > [FREELDR] > - Correctly append a backslash to the BootPath (if needed). > - Be able to specify relative boot paths (relative to the current boot device): as a consequence, remove the "LiveCD" hackish special value that was introduced long long ago. > - Fix BootPath retrieval in ReactOSSetup mode (via the SystemPath optional value), and use a better way to build the temporary txtsetup.sif full file names. > > As a consequence we can now build hybrid cds with the following architecture: > \ > --> loader\ (bootsectors + free/setupldr.sys) > --> myboot\ (contents of what_defaults_to_reactos directory for the bootcd) > --> mylive\ (contents of what_defaults_to_reactos directory for the livecd) > --> <regular_files> > and > freeldr.ini specifying the following values: > > ; The Setup entry > [Setup] > BootType=ReactOSSetup > SystemPath=\myboot > > ; The LiveCD entry > [LiveCD] > BootType=Windows2003 > SystemPath=\mylive > Options=/MININT > > Part 2/2 > CORE-9023 > > Modified: > trunk/reactos/boot/bootdata/livecd.ini > trunk/reactos/boot/freeldr/freeldr/CHANGELOG > trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] Sun Jan 4 23:49:18 2015 > @@ -178,17 +178,40 @@ > HasSection = IniOpenSection(SectionName, &SectionId); > > UiDrawBackdrop(); > - UiDrawProgressBarCenter(1, 100, "Loading NT..."); > + UiDrawProgressBarCenter(1, 100, "Loading ReactOS Setup..."); > > /* Read the system path is set in the .ini file */ > if (!HasSection || > !IniReadSettingByName(SectionId, "SystemPath", BootPath, sizeof(BootPath))) > { > + // MachDiskGetBootPath(BootPath, sizeof(BootPath)); > + // strcpy(BootPath, SectionName); > + } Why? Can you please stop commenting out code without further explanations? Either you comment out (better doing so with #if 0, for the record) and you explain why you do so alongside in the code, for next developers coming into the code, or you don't comment out. So, just don't answer here, just commit an explanation ;-). Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

ReactOS at FOSDEM
by Pierre Schweitzer 04 Jan '15

04 Jan '15

Dear all, ReactOS will be present this year at FOSDEM, in Brussels, on the 31st of Jan & the 1st of Feb. More information at: https://fosdem.org/2015/ We will have a stand so that you can come and meet the people behind ReactOS! We will dispatch more information about the stand & its location when we have them. We're looking forward to seeing you at Brussels! Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [ros-dev] great chance
by Robert Naumann 03 Jan '15

03 Jan '15

Just a friendly reminder. The remaining time to participate becomes lesser and lesser. I still think we have good chances as this is organized by heise and they published much news about ros in the last year, so I think they are really interested. Here an English link: http://developerworld.heise.de/en/call-for-papers/ Am 04.12.2014 09:50 schrieb "Thomas Mueller" <mueller6723(a)twc.com>: > Hey guys, > I previously talked to daniel and colin about this thing and colin told me > to write a mail to this list. > I read about a big chance for the preject to show a presentation at the > CeBIT, the biggest german IT convention. > Sadly, I only have links to german websites but maybe you are satisfied > with google translation. > Here they are: > http://www.golem.de/news/call-for-papers-open-source-forum-sucht-experten-f… > http://www.linux-magazin.de/NEWS/Call-for-Papers-Open-Source-Forum-auf-der-… > This would be a big chance for the project as there are people from all > over the world and a bigger audience than the one of all Linux days > together could learn about the project. > Best Regards > Robert Sounds like a great idea. ReactOS could use the publicity, and it might recruit more developers to ReactOS. I have read about CeBIT on heise online (www.heise.de). Tom _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] Question(s) about FreeLoader
by Rubén Mendoza Luna 02 Jan '15

02 Jan '15

> A final note, too (plus question): since our recent PXE support (that > appears to work! Thanks to Jérôme + Pierre effort, and numerous testers) > somebody oriented me to how this is done in Windows: they have a > STARTROM.0 file that is the bootstrap (downloaded and ran by PXE thing) > which then loads a NTLDR (somewhat). I binary analyzed it and it seems to be > of the same nature as the STPBOOT.BIN file, i.e. 16-bit bootstraper. > Question: does it load (after download) directly the 32-bit OSLOADER? OR > does it load the full NTLDR instead?, i.e. loading the 16-bit NTLDR part > (that then loads the 32-bit part)? StartROM.0 (called startrom.com and startrom.n12 ins the installation media) loads only a 32/64bit PE Setupldr.exe/Osloader.exe image, which is included with every Windows versión based in the NT Kernel, in a compressed form ofc, that's definitive. StartROM.0 is in effect the rought equivalent to STPBOOT.BIN in your example, but enabled for PXE booting. The confusión comes because StartROM expects to find the loader image with the specific NTLDR file name, renaming process which is done by the built-in Windows Server RIS server, when you créate a Windows distribution directory with the provided tools.

1 0

Question(s) about FreeLoader
by Hermès BÉLUSCA - MAÏTO 02 Jan '15

02 Jan '15

Hi all, Ive some questions/remarks about FreeLoader. But first lets start with some introduction On Windows (up to 2k3, things changed starting Vista), the boot loader is in two flavours, the usual one (NTLDR) used for loading Windows when it is installed, and another one (SETUPLDR) used only for text-mode setup. NTLDR shows the classical OS menu (as we do in ReactOS), whereas SETUPLDR can be seen when you boot with a Windows setup CD: it shows some kind of text-mode blue-screen, displaying in a status bar the status of loading some boot-time drivers, possibly allowing you to press a function key to be able to give additional drivers to be loaded. After that, things are loaded (HAL, kernel) and the text-mode setup program proper is loaded (usetup.exe aka smss.exe in the disc). Whichever bootloader being considered, it is made of two parts (concatenated): - a 16 (real-mode)-to-32 bits part, lets call it STPBOOT.BIN (to follow the convention of http://reboot.pro/topic/5900-make-your-own-nt-os-loader-ntldrsetupldr/ ), - and a 32-bit one. The 16-bit part is some kind of stub which switches the CPU to 32 bit (and may also contain some utility functions to make real-mode callbacks). This stub is the same for both NTLDR and SETUPLDR, whereas the 32-bit part differs. In the Windows CD, in the \I386 directory you have those files, NTLDR and SETUPLDR.BIN. But if you analyze them, and after noticing the (compressed) files OSLOADER.NT_ (that expands to OSLOADER.NTD, but is in fact a native .EXE), and SETUPLDR.EX_ (that expands to SETUPLDR.EXE, also native EXE), you notice that in fact NTLDR == STPBOOT.BIN + OSLOADER.EXE and SETUPLDR.BIN == STPBOOT.BIN + SETUPLDR.EXE . (EDIT: During writing this mail I discovered that http://en.wikipedia.org/wiki/Windows_NT_startup_process#CD-ROM_boot_image_ph ase mentions the same thing in the Boot loader phase paragraph). On ReactOS we do the same: our FREELDR.SYS is made of a 16-bit part FRLDR16.BIN concatenated with FREELDR_PE.DLL (using the names of the generated files when you compile ROS). Also we had two targets, FREELDR and SETUPLDR, the former for generating the usual boot loader whereas the latter was used for the bootcd. However starting revision 65832 (http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=65832> &revision=65832 ) both SETUPLDR and FREELDR became the same. Why? What differed them was the support of the boot loading option ReactOSSetup: SETUPLDR was in fact FREELDR *with* the support of this option (in some revisions ago there was also support for some setup-like blue UI, see revision 57933: http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=57933> &revision=57933 and references within). Starting r65832 the setup support is automatically included in FREELDR. Therefore when we generate the bootcds, we generate a FREELDR and a SETUPLDR but both files are the same binary-wise. Hence the question: Should we still keep the SETUPLDR target, or just directly use FREELDR in all situations?. One may say keep it for compatibility purposes (filename-wise), but then one might just keep only the setupldr.sys file in the bootcd (and remove the freeldr.sys one)? Another question would be: Should we restore a SETUPLDR target (i.e. put setup-oriented code for SETUPLDR only and not in the usual FREELDR) in order to be able, in the future, to implement some sort of on-demand extra driver loading, as Windows SETUPLDR does? A final note, too (plus question): since our recent PXE support (that appears to work! Thanks to Jérôme + Pierre effort, and numerous testers) somebody oriented me to how this is done in Windows: they have a STARTROM.0 file that is the bootstrap (downloaded and ran by PXE thing) which then loads a NTLDR (somewhat). I binary analyzed it and it seems to be of the same nature as the STPBOOT.BIN file, i.e. 16-bit bootstraper. Question: does it load (after download) directly the 32-bit OSLOADER? OR does it load the full NTLDR instead?, i.e. loading the 16-bit NTLDR part (that then loads the 32-bit part)? Answers and comments are highly welcome!! Happy new year to everyone! Hermès.

1 1

Re: [ros-dev] [ros-diffs] [pschweitzer] 65856: [NTOSKRNL] - Implement IopGetDeviceAttachmentBase() which allows getting the base device of the device stack given any device object in it - Implement IopGetDevicePDO() which r...
by Thomas Faber 28 Dec '14

28 Dec '14

On 2014-12-28 11:05, pschweitzer(a)svn.reactos.org wrote: > +extern ERESOURCE IopSecurityResource; This resource is only ever acquired shared, meaning it doesn't provide any mutual exclusion at all. Is that intentional?

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 65449: [KERNEL32][CONSRV] - Remove the USE_CONSOLE_INIT_HANDLES define since now we "support" the console initialization events. - The events in the CONSOLE_START_INFO structure are cons...
by Thomas Faber 28 Dec '14

28 Dec '14

On 2014-11-22 23:13, hbelusca(a)svn.reactos.org wrote: > + Status = NtCreateEvent(&Console->InputBuffer.ActiveEvent, EVENT_ALL_ACCESS, > + &ObjectAttributes, NotificationEvent, FALSE); > + if (!NT_SUCCESS(Status)) > + { > + return STATUS_UNSUCCESSFUL; > + // return Status; > + } This was a while ago, but I'm curious: what's the point of this? Avoiding STATUS_UNSUCCESSFUL is usually a good thing.

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 65815: [NtUser] - Crash while in recursion through hook calls. Move fast calls to api. Placed safe guards for removing message queue structures. Lock threads while calling hooks. Just ad...
by Thomas Faber 23 Dec '14

23 Dec '14

On 2014-12-23 20:05, jimtabor(a)svn.reactos.org wrote: > @@ -732,6 +732,7 @@ > return NULL; > } > > + RtlZeroMemory(Message, sizeof(Message)); > RtlMoveMemory(&Message->Msg, Msg, sizeof(MSG)); > > return Message; You mean sizeof(*Message)

1 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do...
by Alex Ionescu 21 Dec '14

21 Dec '14

Isn't the correct solution to use SxS with an activation context? Best regards, Alex Ionescu On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote: > Author: gadamopoulos > Date: Sat Dec 20 16:49:31 2014 > New Revision: 65766 > > URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev > Log: > [COMCTL32] > * Do not add two additional pixels at the top margin of the toolbar. This > is the behaviour of comctl32 v6 and our explorer depends on that to appear > properly. We don't have a proper solution for these differences in behavior > and since we already opt to use the v6 behavior I think it is fine. > > CORE-5483 #resolve #comment Committed a slightly different version of the > patch, thanks. > > Modified: > trunk/reactos/dll/win32/comctl32/toolbar.c > > Modified: trunk/reactos/dll/win32/comctl32/toolbar.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar… > > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20 > 16:49:31 2014 > @@ -244,7 +244,12 @@ > > static inline int default_top_margin(const TOOLBAR_INFO *infoPtr) > { > +#if 0 > return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER); > +#else > + /* This is the behaviour in comctl32 v6 */ > + return 0; > +#endif > } > > static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle) > > >

3 2

Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do...
by David Quintana 21 Dec '14

21 Dec '14

Ideally, we'd fork comctl32 into two libraries like windows does, but that would probably mean we'd have to fork from wine, moving the maintenance effort to our side. That's why we did not do it yet. Sent from my Windows Phone ------------------------------ From: Alex Ionescu Sent: 21/12/2014 09:05 To: ReactOS Development List Cc: Linda Wang; Filip Subject: Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do... Isn't the correct solution to use SxS with an activation context? Best regards, Alex Ionescu On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote: > Author: gadamopoulos > Date: Sat Dec 20 16:49:31 2014 > New Revision: 65766 > > URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev > Log: > [COMCTL32] > * Do not add two additional pixels at the top margin of the toolbar. This > is the behaviour of comctl32 v6 and our explorer depends on that to appear > properly. We don't have a proper solution for these differences in behavior > and since we already opt to use the v6 behavior I think it is fine. > > CORE-5483 #resolve #comment Committed a slightly different version of the > patch, thanks. > > Modified: > trunk/reactos/dll/win32/comctl32/toolbar.c > > Modified: trunk/reactos/dll/win32/comctl32/toolbar.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar… > > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20 > 16:49:31 2014 > @@ -244,7 +244,12 @@ > > static inline int default_top_margin(const TOOLBAR_INFO *infoPtr) > { > +#if 0 > return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER); > +#else > + /* This is the behaviour in comctl32 v6 */ > + return 0; > +#endif > } > > static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle) > > >

1 0

Status Meeting
by Aleksey Bragin 19 Dec '14

19 Dec '14

Hey, since we skipped the meeting this week, I propose we do make a joint November-December meeting somewhere in the middle of December. (as we did in the previous year too). How about 18th of December? Regards, Aleksey Bragin

5 8

Re: [ros-dev] [ros-diffs] [akhaldi] 65617: [USER32] We're not using any debugging routines here.
by Timo Kreuzer 13 Dec '14

13 Dec '14

Honestly, I don't see any point in these modifications. The next time someone wants to use these debug routines, he will need to add it back. Or he will start using DPRINT stuff again. I'd prefer to have this in all files! Am 12.12.2014 14:23, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Fri Dec 12 13:23:45 2014 > New Revision: 65617 > > URL: http://svn.reactos.org/svn/reactos?rev=65617&view=rev > Log: > [USER32] We're not using any debugging routines here. > > Modified: > trunk/reactos/win32ss/user/user32/misc/rtlstr.c > > Modified: trunk/reactos/win32ss/user/user32/misc/rtlstr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/misc/r… > ============================================================================== > --- trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] Fri Dec 12 13:23:45 2014 > @@ -10,10 +10,6 @@ > /* INCLUDES ******************************************************************/ > > #include <user32.h> > - > -#include <wine/debug.h> > - > -WINE_DEFAULT_DEBUG_CHANNEL(user32); > > /* FUNCTIONS *****************************************************************/ > VOID > > >

2 1

Server downtime tomorrow (Monday)
by Colin Finck 12 Dec '14

12 Dec '14

Hi all, Due to an OS upgrade on one of our VMs, the following services will temporarily be down tomorrow (Monday): * SVN * BuildBot Buildmaster * Git Mirror * Secondary nameserver * File server at svn.reactos.org I'll try to get this done as fast as possible, so that the downtime will be reduced to a minimum. Sorry for the inconveniences! Cheers, Colin

2 4

Re: [ros-dev] [ros-diffs] [pschweitzer] 65596: [NTOSKRNL] THE oneliner.... Properly read the information from the IRP to get the reparse tag. This fixes the handling of reparse mount points in ReactOS. To make it short and ...
by Michael Fritscher 10 Dec '14

10 Dec '14

Hi, congratulations! It's a pity that MS hardcodes the C:\ at more and more places... Original Windows NT 4.0 can boot completely even if the drive-letter changes, WinNT + IE throws an error message but works, on Windows 2000 one is automatically logged out again if it changes, on Windows XP even the login-Screen doesn't appear... Best regards, Michael Fritscher

3 2

Partition size and FAT32 cluster size?
by Thomas Mueller 08 Dec '14

08 Dec '14

What is the biggest partition size compatible with 4096-byte (4 KB) cluster size, cluster size being the minimum amount of space taken by a file however small? I googled some years ago and found it to be about 8 GB, however now I wonder if that was wrong, and I can accommodate a bigger partition. >From what I read years back, minimum cluster size would go to 8 KB when partition size goes above 8 GB, 16 GB when partition size goes above 16 GB, 32 KB when partition size goes above 32 GB, meaning a lot of disk space wasted by small files. I believe the best file system ReactOS can use so far is FAT32, true also for FreeDOS. My first formatting might be done from FreeBSD, NetBSD or Linux, since I don't have ReactOS or MS-Windows installation currently. Tom

3 3

Re: [ros-dev] [ros-diffs] [dreimer] 65574: Rule #1 of today: If you steal from resources... then at least steal from the most fitting one in layout matters... [OSK] Fix german layout by moving the "#" button where it should...
by Thomas Faber 07 Dec '14

07 Dec '14

On 2014-12-06 08:43, dreimer(a)svn.reactos.org wrote: > [OSK] > Fix german layout by moving the "#" button where it should be and adding the "<" button next to "Y" Erm... hard-coding keyboard layouts into OSK is a broken design by the way. It should determine the current layout from the OS and display that. (Point in case: some people *cough cough* use custom keyboard layouts)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev