Re: [ros-dev] NTFS in ReactOS: heise online article

[Sven Barth]

On 07.11.2014 13:19, Pierre Schweitzer wrote:

On 07/11/2014 12:05, Thomas Mueller wrote:

Dear Thomas,



This source of such article is a post from reboot.pro
(http://reboot.pro/topic/20149-ntfs-now-supported-in-reactos-livecd/)
where I report this progress and ask for help.



On ReactOS website, you don't have such strong report, but the piece of
information exists, spread in various places. People started talking
about it on boards a few days ago. You have a short report about it in
the latest ReactOS developer meeting minutes
(https://www.reactos.org/node/909). And finally, the commits made on
NTFS where kind of explicit about the progresses (coming along with
pictures:
https://git.reactos.org/?p=reactos.git&a=search&h=HEAD&st=commit&s=[NTFS]).



Note that the 0.3.17 release has initial, but not full (release process
was started before everything could be developed) NTFS support. Testing
from trunk is then the preferred method.



Cheers,



Pierre Schweitzer 


Thanks for the link!

I can see why, in a developing OS or application, following trunk would be the 
indicated method.

Problem is I have no hard-drive space (actually I do, but it's GPT-partitioned).


We indeed so far don't support GPT disks. It would require some changes
to be done in our storage stack.
This is somehow on my todo list, but it's kind of huge ;-).


Out of curiosity: why is it so extensive to implement? From my 
understanding (I'm currently working with partition tables at work) GPT 
should be simpler to handle than MBR. Or is this because it needs to be 
implemented in a Windows compatible way? If so what did they change 
there to make implementing GPT such a "problem"?


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Tuesday is a best day for software\pr releases

[Sven Barth]

On 23.10.2014 12:24, Javier Agustìn Fernàndez Arroyo wrote:

question is... Is 0.3.17 ready to be out?



There is always another Tuesday ;)

Regards,
Sven


On Thu, Oct 23, 2014 at 11:19 AM, Alexander Rechitskiy
mailto:art1st...@yandex.ru>> wrote:

Tuesday is a best day for software\pr releases.
This conclusion is based on the analysis of the number of downloads
and visits to the site ReactOS.org
In normal times Tuesday - a day of peak attendance or the day before
the day of peak attendance.
This will help to improve the promotion of information in the media
--
Best regards,
Alexander Rechitskiy

___
Ros-dev mailing list
Ros-dev@reactos.org 
http://www.reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] About hotpatchable dlls on ReactOS

[Sven Barth]

Am 28.02.2014 14:54, schrieb Ged Murphy:


Are you referring to .msp's ?


I think he merely means that some games seem to utilize the hotpatch* 
nature of Windows DLLs to hook in their own code. Not that I'd not like 
to have the full hotpatch functionality in ReactOS... ;)


(*) A nop-like instruction near the beginning of a function which can be 
replaced by a relative jump to a few bytes back where a jump to an 
alternative implementation can be included. Normally used to implement a 
patched version of the function for Windows' hotpatching functionality.


Regards,
Sven
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.

[Sven Barth]

Am 02.12.2013 22:05 schrieb "Steven Edwards" :
>
> Look at how the Core Fonts for the Web are handled. We should have
generic drivers that are 'good enough' to be able get online and download
the Microsoft ones if the user wants to take the risk of violating
Microsofts license.

There is a little problem however: we are talking about the file system
driver which is usually used to install the system. I don't know currently
how Windows manages to update in use boot drivers, but we'd need something
equivalent in place for this.

Regards,
Sven
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.

[Sven Barth]

On 29.11.2013 20:31, Aleksey Bragin wrote:

To give you my position:
1. Current FAT driver in ReactOS needs to die away. I am testing all my
new code with the MS's FASTFAT driver.
2. Lawyers advice is needed whether we can distribute it.


Please excuse my ignorance, but wasn't there the plan to integrate a 
different open source library which can access FAT into a FAT driver? Or 
is the current driver already using this library? (I'm reading the 
ros-diff list weekly, but sometimes I miss some things...)


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-general] Server downtime on Saturday

[Sven Barth]

Am 27.11.2013 06:42 schrieb "Sven Barth" :
>
> On 26.11.2013 14:29, Pierre Schweitzer wrote:
>>
>> We're trying yet another time.
>>
>> This time with a completely new server from Hetzner.
>>
>> All services are green for the moment. There's only an obvious
>> bottleneck with mails.
>
>
> I don't know whether it's just me, but since Sunday (I last tried just
now) I'm getting this error when I try to connect to the forum:

Just in case: today it worked without problems.

Regards,
Sven
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-general] Server downtime on Saturday

[Sven Barth]

On 26.11.2013 14:29, Pierre Schweitzer wrote:

We're trying yet another time.

This time with a completely new server from Hetzner.

All services are green for the moment. There's only an obvious
bottleneck with mails.


I don't know whether it's just me, but since Sunday (I last tried just 
now) I'm getting this error when I try to connect to the forum:


===

SQL ERROR [ mysqli ]

Too many connections [1040]

An sql error occurred while fetching this page. Please contact an 
administrator if this problem persists.


===

or this when I try to connect to the main page:

===

Error
The website encountered an unexpected error. Please try again later.
Error message
PDOException: SQLSTATE[08004] [1040] Too many connections in 
lock_may_be_available() (line 167 of 
/srv/www/www.reactos.org/drupal/includes/lock.inc).


===

Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Building and installing ReactOS on newer computer

[Sven Barth]

Am 24.10.2013 12:39, schrieb Thomas Mueller:

 From what I read, I think ReactOS might not get along with USB 3.0 and GPT,
hence the desire to use a USB stick.


Did you read this already? https://www.reactos.org/wiki/LiveUSB
If ReactOS already correctly recognizes your USB controllers this might 
work as well (maybe you should try the LiveCD to check whether USB 
storage devices are correctly recognized).


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Google Montreal Tech Talk

[Sven Barth]

Am 05.09.2013 21:40 schrieb "Aleksey Bragin" :
>
> On 05.09.2013 23:00, Sven Barth wrote:
>>
>> On 05.09.2013 16:36, Александр wrote:
>>>
>>>   Tell them about http://www.youtube.com/watch?v=BzJTZY54r0I training
>>> course called "operating systems" based on Reactos in Moscow State
>>> Technical University by Aleksey Bragin. Also tell them about 2000 pages
>>>   of Chinese textbook devoted to Reactos 1)
>>> http://yadi.sk/d/yRbwE6-23NqQu 2) http://yadi.sk/d/CxgVpVzS3G-GQ
>>
>>
>> Pity that I understand neither Russian nor Chinese...
>>
>> @Aleksey: If you allow I have two small suggestions regarding your style
of lecture based on the linked video (I don't know whether this already
changed since the time of recording though):
>> - try to look towards your students
>> - please keep your hands out of your pockets
>> As a student I definitely prefer presenters that respect these two
points (and yes, I'm aware that this can be hard)
>>
>> Regards,
>> Sven
>
> Thanks Sven, I improved after watching the first recorded video of the
lecture myself, and tried to "fix" those issues in the next lectures. Next
time to practice would be 2014 spring when I am reading the same course to
the new 2nd year students.

Yes, watching a recording of oneself can be really helpful. And its nice to
see that you take interest in your style of lecture. I know quite a few
lecturers that don't give a thing about it :(

Regards,
Sven
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Google Montreal Tech Talk

[Sven Barth]

On 05.09.2013 16:36, Александр wrote:

  Tell them about http://www.youtube.com/watch?v=BzJTZY54r0I training
course called "operating systems" based on Reactos in Moscow State
Technical University by Aleksey Bragin. Also tell them about 2000 pages
  of Chinese textbook devoted to Reactos 1)
http://yadi.sk/d/yRbwE6-23NqQu 2) http://yadi.sk/d/CxgVpVzS3G-GQ


Pity that I understand neither Russian nor Chinese...

@Aleksey: If you allow I have two small suggestions regarding your style 
of lecture based on the linked video (I don't know whether this already 
changed since the time of recording though):

- try to look towards your students
- please keep your hands out of your pockets
As a student I definitely prefer presenters that respect these two 
points (and yes, I'm aware that this can be hard)


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [akhaldi] 59507: [DBGHELPHOST] * Fix some warnings. Brought to you by Thomas Faber.

[Sven Barth]

On 20.07.2013 12:50, Timo Kreuzer wrote:


At some point, when x64
starts working and mingw-w64 has proper exception handling support (not
sure how far that is), I might have a look at that again though.


According to this thread over on GCC at least 4.8 has quite improved SEH 
support on x64: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html 
(the patch proposed there was declared as commited a few mails later)


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [pschweitzer] 58960: [RTL] Finally reenable RtlAcquirePrivilege

[Sven Barth]

On 06.05.2013 17:48, Jérôme Gardou wrote:

Hey Pierre!

Nice patch series, that takes ReactOS nearer to being secure. A remark though :


  /*
- * enable the SeSystemtimePrivilege privilege
+ * Call SetLocalTime twice to ensure correct results
   */
+Ret = SetLocalTime(&SetupData->SystemTime) &&
+  SetLocalTime(&SetupData->SystemTime);


This is a bit confusing, and the comment doesn't really help. Why would calling 
the function twice ansure correct result ? Also, this is likely to be optimized 
away by the compiler, or at least produce a report in static code analysers.

I know this isn't pure chance. Any hint as to why you wrote it like this ?


Even MSDN states that it might be necessary to call SetLocalTime twice: 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724936%28v=vs.85%29.aspx


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [hbelusca] 58902: [FREELDR] - Fix some function parameter types, so to avoid unuseful casts (from pointers to const strings to pointers to strings in particular). - The big t

[Sven Barth]

Am 02.05.2013 00:30, schrieb Timo Kreuzer:


I have an actual pragmatic argument against one liners:
When you debug code (and I mean with a real debugger aka WinDbg and 
not kdbg) and you step through the source, whenever there is a one 
liner, you just don't see which branch it takes and whether it 
executed the statement or not. So you have to check other things. Look 
at the variables. And when there is stuff like

"if (FOO_MACRO(Value)) GlobalVariable++;" you are simply f***ed.
You'll have to add a watch for GlobalVariable and check the value 
before and after.

I really prefer to see what path the code takes, when stepping over it.

So it's not a question of style or beauty, but a question of 
convenient debugging.
This is also the reason why I don't like to put a statement in the same 
line as a if/while-condition or for-loop-header no matter what 
programming language I'm using.


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Google Summer of Code 2013

[Sven Barth]

Am 02.03.2013 23:01, schrieb Zachary Gorden:
Note that I've already created an ideas page for 2013 here: 
http://reactos.org/wiki/Google_Summer_of_Code_2013_Ideas


That is a nice list. Sadly I'm busy this summer with writing my master 
thesis and after that I'm not a student anymore... Also I'd not be 
experienced enough in C for most of the tasks (except maybe the SSH 
service and the GUI installer...).


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS On ARM/Raspberry Pi

[Sven Barth]

Am 18.01.2013 15:34, schrieb Jérôme Gardou:

Before you put too much hope on it, ReactOS needs a Memory Managing
Unit (basically, virtual memory support), which is present only on
ARMv7. Raspberry Pi has an ARM11 CPU, which only implements
ARMv6. (yeah, don't be confused with all those numberings...)
Ehm... the Raspberry Pi does have a MMU. This can already be seen 
because it runs full scale Linux which requires a MMU as well (unlike 
µLinux). MMU support for ARM was introduced at least with ARM9 (see 
http://en.wikipedia.org/wiki/ARM9E ).


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] NDISwrapper

[Sven Barth]

Am 26.06.2012 16:10 schrieb "Александр" :
>
> Does ReactOS make use of NDISwrapper?
>
http://sourceforge.net/apps/mediawiki/ndiswrapper/index.php?title=Main_Page

The use of NDISWrapper is to provide an environment where a NT (NDIS)
driver can feel enough at home so that it can function. ReactOS already
provides such functionality and if I remember correctly NDISWrapper even
uses code from ReactOS to implement its NT compatible environment (but I'm
not entirely sure about this last point).

Regards,
Sven
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] NDISwrapper

[Sven Barth]

Am 26.06.2012 16:59 schrieb "Riccardo Bestetti" :
>
> Why should it? o.O

Exactly what I had thought when I rrad that mail. :)

Regards,
Sven
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS on ARM, working on the iPhone

[Sven Barth]

On 23.06.2012 06:11, r...@velocitylimitless.org wrote:

Of course. we need to also reinitialize the arm address table
translation register as the mappings created by iBoot will not work for
windows nt.

for the boot chain, I still need to get ramdisks working. this will most
likely involve hooking the iBoot command list and adding our own ramdisk
command to copy the image to some location in memory.

current state of the arm port is that the kernel does boot, however arm3
memory init is missing, so we just hang there.


I definitely wish you good look. If you get ReactOS somehow working on 
the iPhone (and here I'm already happy with "is able to start and run 
smss.exe") this might be the first (and only) reason for me to purchase 
such a device ;)


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS on ARM, working on the iPhone

[Sven Barth]

On 22.06.2012 21:06, Richardo Stallmanu wrote:

Hello everyone!

I just got freeldr working properly (sort of) on the iPhone 4!
Currently, I use Apple's iBSS
(first stage DFU bootloader), with the go command patched to always branch to
0x4100. 0x4100 contains the actual LLB, which is relocated to
0x4200.
The LLB will initialize the ReactOS loader console and ARM loader
block, which is sent
to FreeLoader, just like on Omap3/Zoom2MDK and Versatile/PB.

Time to get ramdisks working. :)

http://goput.it/uc5.jpg <- There's your picture.


The bootloader is only the first step... getting ReactOS itself to boot 
and utilize the iPhone's hardware correctly (and I'm mostly talking 
about the CPU and the memory here) is a rather big part that remains 
(not even mentioning that ROS won't boot that far into user mode at all 
on ARM...)


Regards,
Sven



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Newbie to ReactOS

[Sven Barth]

On 19.06.2012 17:39, Lonnie Cumberland wrote:

As for your experiment. It's quite simple to do. You can build your
own version of ReactOS from trunk (or just download the prebuilt
.iso from our website - the trunk build, not the last release),
install it and then try to "strip" it down as much as you want.
Explorer.exe is specified as a shell in a special registry key, I
could look up the path if you like. Hackish way would be to delete
explorer.exe and rename notepad.exe to explorer.exe. Or, better, use
cmd.exe as a shell, it allows to actually do something with the OS
instead of just typing text in the editor.

After that, it would be needed to look at dependencies and actually
delete all DLLs which are not necessary.
This way you get a really lean ReactOS install.


I actually had thought of using the load up and strip away approach, but
was hoping not to have to go that route and wanted to see if I could
instead opt for the other approach which would be to have the absolute
minimums needed to boot ReactOS and then go with the add-files approach
which would actually make a leaner ReactOS version I would think as only
needed files would be on the system with no extraneous files lurking about.

It also does not have to strictly be notepad.exe, but that was just one
of the simplest ones that I could see possibly using as I would then
like to do the same thing with paint.exe and perhaps one other one for
this set of tests.


You could also use Dependency Walker ( http://www.dependencywalker.com/ 
) and open your favorite application (I'll take notepad.exe for now). If 
you do it on ReactOS (at least if Dependency Walker runs on ReactOS...) 
you will see all the DLLs the application needs and which DLLs those 
DLLs need in turn. Then you'll also at least need the following which 
you won't find through DLL dependencies (though I can indeed be missing 
something ;) ):
* the hive file where the HKEY_CURRENT_USER part of the registry is 
stored in (don't know it's current location in ROS though :( )

* all other hive files in %systempath%/config
* the drivers which are marked as "boot" in the registry (though you can 
try to disable selected ones, like e.g. floopy if you don't need them)
* smss.exe, csrss.exe, win32k.sys (maybe we already also need 
win32csr.dll), winlogon.exe (though you can also change it in the 
registry to a different application; then you don't need to set the 
shell AFAIK; or you can rename your application to winlogon.exe)

* ntoskrnl.exe and hal.dll
* pagefile.sys, freeldr.sys, boot.ini (all located in the system partition)

As I said the list might not be complete, but it will give you a 
starting point.


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Core developer

[Sven Barth]

Am 16.05.2012 08:00, schrieb Александр:

http://en.wikipedia.org/wiki/HX_DOS_Extender
Is it usefull for us?



No, it's not useful. HX DOS basically goes the other way round: 
providing Windows functionality on DOS, but we want to provide DOS (and 
Win3.11) functionality on NT.


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Core developer

[Sven Barth]

Am 15.05.2012 11:56, schrieb Sven Barth:

Am 14.05.2012 17:56, schrieb Andrew Faulds:

Hmm, apparently, Wine does NTVDM using DOSBox. I tried to run a DOS
app recently and it spawned WINE's NTVDM (I'm on Ubuntu), which spawns
DOSBox.

So I guess we could just copy in Wine's NTVDM?



It might not be that trivial. While it's true that it uses DOSBox (and
mounts all Wine drives besides Z) there is also some stuff going on
which is currently hidden behind an external function
"__wine_load_dos_exe" which I yet need to find and which is the one
responsible of loading the binary into DOSBox somehow (and this is the
interesting part!). Also one might need to test whether Win 3.11
applications work in Wine. If so then it might indeed be interesting to
investigate this further.


I've looked a bit more into this and it is so that Wine supports two 
approaches:

* run 16-Bit executable natively (basically the same that Windows does)
* if that fails (e.g. on 64-bit Linux) run the application in DOSBox

So in the first case the application might correctly interact (and 
display) like other non-16-bit applications, but in the second case the 
application will be emulated and thus the application will not integrate 
as nicely as in the first case (especially if it is a graphical Win3.11 
application which also might require that you set up your DOSBox correctly).


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Core developer

[Sven Barth]

Am 14.05.2012 17:56, schrieb Andrew Faulds:

Hmm, apparently, Wine does NTVDM using DOSBox. I tried to run a DOS
app recently and it spawned WINE's NTVDM (I'm on Ubuntu), which spawns
DOSBox.

So I guess we could just copy in Wine's NTVDM?



It might not be that trivial. While it's true that it uses DOSBox (and 
mounts all Wine drives besides Z) there is also some stuff going on 
which is currently hidden behind an external function 
"__wine_load_dos_exe" which I yet need to find and which is the one 
responsible of loading the binary into DOSBox somehow (and this is the 
interesting part!). Also one might need to test whether Win 3.11 
applications work in Wine. If so then it might indeed be interesting to 
investigate this further.


Regards,
Sven


On 14 May 2012 14:27, Samuel Serapión  wrote:

Very nice... but its "just" an x86+dos emulator, just like dosbox.

On Tue, May 8, 2012 at 1:13 PM, Bernd Blaauw  wrote:

Op 8-5-2012 10:02, Javier Agustìn Fernàndez Arroyo schreef:


" It just should be
integrated into ReactOS"

i recently asked about this at IRC and the answer is "not as of now"



What about the following utility? It's kind of a workaround though:
[ http://homepage3.nifty.com/takeda-toshiya/msdos/index.html ]

VDMsound and Dosbox are also reasonably functioning under Windows.


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev







___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Disappeared thread in forum

[Sven Barth]

Hello together!

Is it just me or did the complete thread "Feedback 0.3.14" (or so) on 
the forum by another Sven (I don't remember his full username) disappear 
from yesterday to today? Even in the "my posts" view my two posts that I 
have done in that thread aren't listed. Also it seems that the youngest 
"no working reinstall driver button" thread by naums disappeared as 
well. They don't appear to have been moved (there is no reference to a 
moved thread), but they are simply gone. Is this a known problem? Were 
they somehow hidden?


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Core developer

[Sven Barth]

Am 08.05.2012 11:47, schrieb Andrew Faulds:

Ah, I see. Windows 3.1 was a 32-bit kernel running 16-bit applications, how odd.



Ehm... no. Windows 3.x was a 16-bit system though it needed the 
protected mode to run (to perform 32-bit disk access, etc.).


Only Windows 95 was a (more) true 32-bit system (like Windows NT 3.1 was 
already).


Regards,
Sven


On 8 May 2012 10:37, Sven Barth  wrote:

Am 08.05.2012 11:33, schrieb Andrew Faulds:


Oh, I didn't think of that. Windows 3.x applications run in NTVDM?



Yes as they are basically "DOS applications" as well. Only Windows 95
introduced a difference.


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev







___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Core developer

[Sven Barth]

Am 08.05.2012 11:33, schrieb Andrew Faulds:

Oh, I didn't think of that. Windows 3.x applications run in NTVDM?



Yes as they are basically "DOS applications" as well. Only Windows 95 
introduced a difference.


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Core developer

[Sven Barth]

Am 08.05.2012 10:08, schrieb Andrew Faulds:

Hmm but DOSBox does not integrate well into OS like NTVDM does. You can
just run "app.exe" in some diectory and it will act as if it was native,
can see all files in directory with 8~3 names, can change environment
variables, can be launched like other apps, etc.


The starting of DOS applications could be implemented by starting DOSBox 
from within the CreateProcess call like NTVDM would be started. Other 
more difficual topics are accessing the available drives and perhaps 
interaction of the started application with the surrounding system 
(desktop, IPC, etc.) which is especially important for Windows 3.x 
applications.


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Monthly meeting - April 2012

[Sven Barth]

Am 27.04.2012 12:44, schrieb Andrew Faulds:

Internal affairs? What internal affairs? If this was about legal
issues and thinks that definitely cannot be open to the public, I'd be
okay with it. But this is an open-source project, no? Surely meetings
should be public?



This was already discussed when the idea of private meetings was 
introduced on this list. I don't think this needs to be discussed 
again... (here is a link to that discussion: 
http://www.reactos.org/pipermail/ros-dev/2011-July/014586.html )


Regards,
Sven


On 27 April 2012 11:38, Ged Murphy  wrote:

It's just you, unless you can name a company that has their meetings in
public?

Meetings are for the members of organizations set goals, deal with issues
and discuss behind the scenes information.
Why should non-members have the right to listen in on internal affairs?

Ged.



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Emanuel Rietveld
Sent: 27 April 2012 11:24
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Monthly meeting - April 2012

On 04/26/2012 07:38 PM, Pierre Schweitzer wrote:

Hi,

This meeting will be private. If you do
not have access, you will not be able to attend the meeting.

Regards,



Is it just me, or this a little like spraying contributor repellant on
your project?

Kind Regards,

Emanuel

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev







___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Monthly meeting - April 2012

[Sven Barth]

Am 27.04.2012 12:38, schrieb Ged Murphy:

It's just you, unless you can name a company that has their meetings in
public?

Meetings are for the members of organizations set goals, deal with issues
and discuss behind the scenes information.
Why should non-members have the right to listen in on internal affairs?


Also the meetings are already private since some time (December? 
January? before?)


Regards,
Sven



Ged.



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Emanuel Rietveld
Sent: 27 April 2012 11:24
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Monthly meeting - April 2012

On 04/26/2012 07:38 PM, Pierre Schweitzer wrote:

Hi,

This meeting will be private. If you do
not have access, you will not be able to attend the meeting.

Regards,



Is it just me, or this a little like spraying contributor repellant on
your project?

Kind Regards,

Emanuel

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] February 2012 Meeting Minutes

[Sven Barth]

On 25.02.2012 09:38, Adam wrote:


Yes. Sorry. You're absolutely right. Firefox really is slimmer and
less memory hungry than ever these days. On another note, eating
McDonald's is good for you so you should do this everyday.

Did I mention that I am the King of England?


Ehm... Firefox IS less memory hungry in its current version than before. 
I noticed this on my smaller Windows system, where Firefox used to have 
around 400 MB with around 20 tabs open and now it's down to 200 MB. That 
this is still far from optimal is a different topic ;)


[On Linux it seems to still be the same memory hog as ever...]

Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] HP webOS goes opensource

[Sven Barth]

Am 18.01.2012 16:06, schrieb Aleksey Bragin:

On 18.01.2012 18:14, Jakob Eriksson wrote:

On January 18, 2012 at 2:54 PM Adam wrote:


Although that would require recompiling the kernel just to
install/uninstall drivers. I do understand loadable modules are
supported but I'm not sure this applies to drivers. And if it does, I
doubt it would apply to all drivers.

No recompile. It applies to all drivers for PCI and USB devices and
huge bunch
of other things. Almost everything is loadable, including all routing
tricks.

It's a loadable module, yes, and it loads dynamically indeed. There is
one issue though: the binary driver itself has to be recompiled with
every Linux kernel update. I personally experience this when I patch the
bt8x8 video capture device driver for my 8 ports capturing card, every
time I manually patch source code to include my specific hardware (oh
yes, it's already 5 years old, it's being sold in every hardware shop,
but still it's not in the linux kernel).


P.S. Proper answer from Linux team would be "We accept patches!" :-).


Well... I DID sent in patches to get my video capture device supported 
and since 2.9.38 I can finally use it without manually compiling the 
"standalone variant" provided by the driver's maintainer ;)


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Proposal for FF support drop

[Sven Barth]

You know that we're not talking about FF 2, but newer releases?

Pierre already wrote that he wants to keep FF 2 in his original mail, 
but we're trying to convince him/the rest to allow a newer release as well.


Btw: Mozilla wants to publish "long term support" releases in the next 
time (based either on FF 8 or FF 9) which shall be supported around ~45 
weeks. Maybe this will be a solution?


Regards,
Sven

On 15.01.2012 19:56, Daniel Reimer wrote:

Guys, you know that we already host FF 2 on our SVN Server? Check the
link. It will NEVER become outdated

Am 15.01.2012 19:04, schrieb Andrew Faulds:

Ah yes, good point. I just randomly guessed ftp.mozilla.org - but it
doesn't allow downloads of high-traffic releases.

On 15 January 2012 17:16, Sven Barth wrote:

On 15.01.2012 16:51, Bernd Blaauw wrote:

Op 15-1-2012 16:34, Andrew Faulds schreef:

Why not just drop support for FF entirely from rapps? I'd say better
no browser than a terribly outdated one.

If users want FF they can do this:
C:\ReactOS> ftp
ftp> open ftp.mozilla.org
ftp> cd pub/firefox/releases/8.0/win32/en-GB
ftp> get Firefox Setup 8.0.exe


You're a version behind already ^^
Perhaps they should create a "/current" or "/latest" and offer "FireFox
Setup.exe" there.


At least on their "high bandwidth FTP server" releases.mozilla.org
(see the
message when opening ftp.mozilla.org in a web browser) there is a
"latest"
in their FireFox folder:
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/

Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev






___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Proposal for FF support drop

[Sven Barth]

On 15.01.2012 16:51, Bernd Blaauw wrote:

Op 15-1-2012 16:34, Andrew Faulds schreef:

Why not just drop support for FF entirely from rapps? I'd say better
no browser than a terribly outdated one.

If users want FF they can do this:
C:\ReactOS> ftp
ftp> open ftp.mozilla.org
ftp> cd pub/firefox/releases/8.0/win32/en-GB
ftp> get Firefox Setup 8.0.exe


You're a version behind already ^^
Perhaps they should create a "/current" or "/latest" and offer "FireFox
Setup.exe" there.


At least on their "high bandwidth FTP server" releases.mozilla.org (see 
the message when opening ftp.mozilla.org in a web browser) there is a 
"latest" in their FireFox folder: 
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] November meeting minutes are there.

[Sven Barth]

On 03.12.2011 21:08, Meeting minutes wrote:

Also, Aleksey says he's going to rewrite mm after the release, so it would be a 
waste of resources to work on the existing one.


A curious question regarding this: wasn't mm already rewritten a rather 
short time ago? Or did I understand it wrong what the ARM devs did there?


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] November meeting minutes are there.

[Sven Barth]

On 03.12.2011 21:08, Ged Murphy wrote:

Why were they posted in the forum instead of the mailing list?
They're now attached to this mail.


Thank you for posting them here :)

Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] 1000 EUR for ReactOS - We have made it!

[Sven Barth]

On 15.11.2011 19:35, Ged Murphy wrote:

1000 EUR for 810 place?
What did first place get, a bailout sum equivalent from Germany?


The bank gave out a total of 100 EUR and said that the first 1000 
ones would get 1000 EUR each.


Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] 1000 EUR for ReactOS - We have made it!

[Sven Barth]

On 15.11.2011 19:04, Colin Finck wrote:

Looking at
https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev, we
have scored the 810th place in the tough competition and just won 1000
EUR for the foundation! :-)


Congratulation!

Regards,
Sven


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Would you donate just 3 minutes to the project?

[Sven Barth]

Finally I could put my many mail addresses to use. :D

Voted 5 * 2 (ok, two of the votes still need confirmation, as I don't 
have access to that account from this PC...)


Regards,
Sven

Am 18.10.2011 00:04, schrieb The ReactOS Team:

Dear ReactOS Community Member,

We contact you today, because you have signed up for a myReactOS account
some time ago. And we need your help!

A German bank is currently running a sponsoring campaign for all kinds of
foundations. The 1000 foundations with the most votes receive 1000 EUR each
by the 15th November.

You can easily increase our chances by voting on the following website:

https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev

Here is the complete voting procedure:
* Open the link above
* Click on the orange button "Stimme abgeben" (= Vote)
* Enter your E-Mail address and solve the captcha, then hit the button
"Absenden" (= Send)
* You will receive a confirmation E-Mail where you have to click the first
link. Finally click on "Stimme abgeben" again and you're done.

Note that you can vote UP TO 3 TIMES with a single E-Mail address, and you
can even cast all votes to the same foundation.
You may also share this, so that we can get as many people as possible to
vote for us.

Let's get ReactOS among the top 1000!

Cheers and thanks for your support,

Aleksey Bragin and Colin Finck
in the name of the ReactOS Team and ReactOS Deutschland e.V.


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS

[Sven Barth]

Am 07.04.2011 09:37, schrieb dmex:

It was 2am and I was being 'trolled'/abused for my lack of enthusiasm and
support for Linux, I regret it spilled over in my reply for a completely
different subject.

I'm pacifist and it was by no means supposed to be harsh and should not have
been directed at others about an unrelated subject.



No harm was done.

As said: I didn't even notice it :P

Regards,
Sven


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 3:14 PM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

Am 06.04.2011 23:20, schrieb dmex:

-And that's why I suggested a device driver... so one can add once own
"extensions" without sacrificing compatibility :)

That could work, It could read or write the 'DBWIN_BUFFER' file and
allow a replacement driver to support outputs using other methods.

I also apologize for my last e-mail, It was very harsh, totally
unwarranted and uncalled for.



Seems like your "harshness" didn't come along as you "wanted" it to...
Or perhaps I was to tired to recognize that it was meant in a harsh way...
^^

Regards,
Sven


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org]
On Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 5:10 AM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
call for
syslog(2) analog in ROS

On 06.04.2011 22:53, dmex wrote:

DebugPring/OutputDebugString would be a good place to start learning
how Windows outputs kernel messages ;)
http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-ap
i
-works
/

ReactOS OutputDebugString Source:
http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output
_
8c_a94
90feb381d7062ca6e5a28bdeacd6d2.html



I'll put that on my todo list once I have a few minutes :D


Minas's idea is terrible in my opinion, "Do we need special system
call like Linux, or even more, the whole family of them (sysctl('*'))
as in BSD?" as ReactOS is designed for binary compatibility with
Windows, Not BSD or Linux and it should stay that way.



And that's why I suggested a device driver... so one can add once own
"extensions" without sacrificing compatibility :)


-Original Message-
From: ros-dev-boun...@reactos.org
[mailto:ros-dev-boun...@reactos.org]
On Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 4:05 AM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
call for
syslog(2) analog in ROS

On 06.04.2011 21:26, dmex wrote:

What's wrong with current method of using the memory mapped

'DBWIN_BUFFER'

file for outputting kernel messages?



That I didn't know about it :P


Two or three different kernel implementations for the same thing
seems a bit retarded and breaks compatibility with existing
applications like

Dbgview.




I'm just looking at the source of ReactOS from time to time when I
have the need to check out how a certain function behaves under the
hood (especially while I ported the Free Pascal compiler to the
Native NT API), but I weren't yet aware how those debug outputs work.
As Minas mentioned that he'd like to add a syscall/API function
compareable to syslog I just thought that it would be wiser (from my
restricted point of
view) to write a driver for this that would allow to extend the
system dynamically.

Regards,
Sven


-Original Message-
From: ros-dev-boun...@reactos.org
[mailto:ros-dev-boun...@reactos.org]
On Behalf Of Sven Barth
Sent: Wednesday, 6 April 2011 8:54 PM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
call for
syslog(2) analog in ROS

Am 06.04.2011 02:09, schrieb Minas Abrahamyan:

Hi all,

I'm going to implement dmesg.exe, a ROS application to read
dmesg/kmsg buffer (debug messages in kernel buffer), which is
filled in by appropriate patch 6018
(here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
it's not yet reviewed and not applied!).

So I'm requesting advice on:
What would be the better way for user-mode code to get the contents
of kmsg buffer in kernel-space (kdbg)?

Shortly:
Linux has special system call "syslog" (man 2 syslog) FreeBSD uses
its special sysctl interface to kernel along with 'kern.msgbuf'

parameter.


My questions:
Do we need special system call like Linux, or even more, the whole
family of them (sysctl('*')) as in BSD?
How to implement simple system call for it, now?


I'm not one of the ReactOS devs and also I'm not writing much here,
but what about implementing a (legacy type) device driver that
provides a device object (e.g. \Device\kmsg) that can be read from
(no writing
though) a

Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS

[Sven Barth]

Am 06.04.2011 23:20, schrieb dmex:

-And that's why I suggested a device driver... so one can add once own
"extensions" without sacrificing compatibility :)

That could work, It could read or write the 'DBWIN_BUFFER' file and allow a
replacement driver to support outputs using other methods.

I also apologize for my last e-mail, It was very harsh, totally unwarranted
and uncalled for.



Seems like your "harshness" didn't come along as you "wanted" it to... 
Or perhaps I was to tired to recognize that it was meant in a harsh 
way... ^^


Regards,
Sven


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 5:10 AM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

On 06.04.2011 22:53, dmex wrote:

DebugPring/OutputDebugString would be a good place to start learning
how Windows outputs kernel messages ;)
http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-api
-works
/

ReactOS OutputDebugString Source:
http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output_
8c_a94
90feb381d7062ca6e5a28bdeacd6d2.html



I'll put that on my todo list once I have a few minutes :D


Minas's idea is terrible in my opinion, "Do we need special system
call like Linux, or even more, the whole family of them (sysctl('*'))
as in BSD?" as ReactOS is designed for binary compatibility with
Windows, Not BSD or Linux and it should stay that way.



And that's why I suggested a device driver... so one can add once own
"extensions" without sacrificing compatibility :)


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org]
On Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 4:05 AM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
call for
syslog(2) analog in ROS

On 06.04.2011 21:26, dmex wrote:

What's wrong with current method of using the memory mapped

'DBWIN_BUFFER'

file for outputting kernel messages?



That I didn't know about it :P


Two or three different kernel implementations for the same thing
seems a bit retarded and breaks compatibility with existing
applications like

Dbgview.




I'm just looking at the source of ReactOS from time to time when I
have the need to check out how a certain function behaves under the
hood (especially while I ported the Free Pascal compiler to the Native
NT API), but I weren't yet aware how those debug outputs work.
As Minas mentioned that he'd like to add a syscall/API function
compareable to syslog I just thought that it would be wiser (from my
restricted point of
view) to write a driver for this that would allow to extend the system
dynamically.

Regards,
Sven


-Original Message-
From: ros-dev-boun...@reactos.org
[mailto:ros-dev-boun...@reactos.org]
On Behalf Of Sven Barth
Sent: Wednesday, 6 April 2011 8:54 PM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
call for
syslog(2) analog in ROS

Am 06.04.2011 02:09, schrieb Minas Abrahamyan:

Hi all,

I'm going to implement dmesg.exe, a ROS application to read
dmesg/kmsg buffer (debug messages in kernel buffer), which is filled
in by appropriate patch 6018
(here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
it's not yet reviewed and not applied!).

So I'm requesting advice on:
What would be the better way for user-mode code to get the contents
of kmsg buffer in kernel-space (kdbg)?

Shortly:
Linux has special system call "syslog" (man 2 syslog) FreeBSD uses
its special sysctl interface to kernel along with 'kern.msgbuf'

parameter.


My questions:
Do we need special system call like Linux, or even more, the whole
family of them (sysctl('*')) as in BSD?
How to implement simple system call for it, now?


I'm not one of the ReactOS devs and also I'm not writing much here,
but what about implementing a (legacy type) device driver that
provides a device object (e.g. \Device\kmsg) that can be read from
(no writing
though) and some code for DeviceIOControl to clear/config the buffer?

Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-

Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS

[Sven Barth]

On 06.04.2011 22:53, dmex wrote:

DebugPring/OutputDebugString would be a good place to start learning how
Windows outputs kernel messages ;)
http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-api-works
/

ReactOS OutputDebugString Source:
http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output_8c_a94
90feb381d7062ca6e5a28bdeacd6d2.html



I'll put that on my todo list once I have a few minutes :D


Minas's idea is terrible in my opinion, "Do we need special system call like
Linux, or even more, the whole family of them (sysctl('*')) as in BSD?" as
ReactOS is designed for binary compatibility with Windows, Not BSD or Linux
and it should stay that way.



And that's why I suggested a device driver... so one can add once own 
"extensions" without sacrificing compatibility :)



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 4:05 AM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

On 06.04.2011 21:26, dmex wrote:

What's wrong with current method of using the memory mapped 'DBWIN_BUFFER'
file for outputting kernel messages?



That I didn't know about it :P


Two or three different kernel implementations for the same thing seems
a bit retarded and breaks compatibility with existing applications like

Dbgview.




I'm just looking at the source of ReactOS from time to time when I have the
need to check out how a certain function behaves under the hood (especially
while I ported the Free Pascal compiler to the Native NT API), but I weren't
yet aware how those debug outputs work.
As Minas mentioned that he'd like to add a syscall/API function compareable
to syslog I just thought that it would be wiser (from my restricted point of
view) to write a driver for this that would allow to extend the system
dynamically.

Regards,
Sven


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org]
On Behalf Of Sven Barth
Sent: Wednesday, 6 April 2011 8:54 PM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode
call for
syslog(2) analog in ROS

Am 06.04.2011 02:09, schrieb Minas Abrahamyan:

Hi all,

I'm going to implement dmesg.exe, a ROS application to read
dmesg/kmsg buffer (debug messages in kernel buffer), which is filled
in by appropriate patch 6018
(here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
it's not yet reviewed and not applied!).

So I'm requesting advice on:
What would be the better way for user-mode code to get the contents
of kmsg buffer in kernel-space (kdbg)?

Shortly:
Linux has special system call "syslog" (man 2 syslog) FreeBSD uses
its special sysctl interface to kernel along with 'kern.msgbuf'

parameter.


My questions:
Do we need special system call like Linux, or even more, the whole
family of them (sysctl('*')) as in BSD?
How to implement simple system call for it, now?


I'm not one of the ReactOS devs and also I'm not writing much here,
but what about implementing a (legacy type) device driver that
provides a device object (e.g. \Device\kmsg) that can be read from (no
writing
though) and some code for DeviceIOControl to clear/config the buffer?

Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS

[Sven Barth]

On 06.04.2011 21:26, dmex wrote:

What's wrong with current method of using the memory mapped 'DBWIN_BUFFER'
file for outputting kernel messages?



That I didn't know about it :P


Two or three different kernel implementations for the same thing seems a bit
retarded and breaks compatibility with existing applications like Dbgview.



I'm just looking at the source of ReactOS from time to time when I have 
the need to check out how a certain function behaves under the hood 
(especially while I ported the Free Pascal compiler to the Native NT 
API), but I weren't yet aware how those debug outputs work.
As Minas mentioned that he'd like to add a syscall/API function 
compareable to syslog I just thought that it would be wiser (from my 
restricted point of view) to write a driver for this that would allow to 
extend the system dynamically.


Regards,
Sven


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Sven Barth
Sent: Wednesday, 6 April 2011 8:54 PM
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

Am 06.04.2011 02:09, schrieb Minas Abrahamyan:

Hi all,

I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg
buffer (debug messages in kernel buffer), which is filled in by
appropriate patch 6018
(here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
it's not yet reviewed and not applied!).

So I'm requesting advice on:
What would be the better way for user-mode code to get the contents of
kmsg buffer in kernel-space (kdbg)?

Shortly:
Linux has special system call "syslog" (man 2 syslog) FreeBSD uses its
special sysctl interface to kernel along with 'kern.msgbuf' parameter.

My questions:
Do we need special system call like Linux, or even more, the whole
family of them (sysctl('*')) as in BSD?
How to implement simple system call for it, now?


I'm not one of the ReactOS devs and also I'm not writing much here, but what
about implementing a (legacy type) device driver that provides a device
object (e.g. \Device\kmsg) that can be read from (no writing
though) and some code for DeviceIOControl to clear/config the buffer?

Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS

[Sven Barth]

Am 06.04.2011 02:09, schrieb Minas Abrahamyan:

Hi all,

I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg
buffer (debug messages in kernel buffer),
which is filled in by appropriate patch 6018
(here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
it's not yet reviewed and not applied!).

So I'm requesting advice on:
What would be the better way for user-mode code to get the contents of
kmsg buffer in kernel-space (kdbg)?

Shortly:
Linux has special system call "syslog" (man 2 syslog)
FreeBSD uses its special sysctl interface to kernel along with
'kern.msgbuf' parameter.

My questions:
Do we need special system call like Linux, or even more, the whole
family of them (sysctl('*')) as in BSD?
How to implement simple system call for it, now?


I'm not one of the ReactOS devs and also I'm not writing much here, but 
what about implementing a (legacy type) device driver that provides a 
device object (e.g. \Device\kmsg) that can be read from (no writing 
though) and some code for DeviceIOControl to clear/config the buffer?


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Video of ReactOS Booting on ARM

[Sven Barth]

Am 23.11.2010 09:27, schrieb Javier Agustìn Fernàndez Arroyo:

errr... "ROSPP"??



From the context I'd guess ReactOS PowerPC

Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Question regarding declaration of RTL_DRIVE_LETTER_CURDIR in include\ndk\rtltypes.h

[Sven Barth]

On 13.11.2010 19:44, Colin Finck wrote:

Sven Barth  wrote:

Regarding the anonymous structure: wouldn't this break compatibility
with gcc? (I don't know what features gcc supports ^^)


Anonymous structures are fully supported by GCC when using the flag
-fms-extensions. We have it enabled throughout the whole codebase.


Ok, thanks again :)

Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Question regarding declaration of RTL_DRIVE_LETTER_CURDIR in include\ndk\rtltypes.h

[Sven Barth]

On 13.11.2010 19:22, Colin Finck wrote:

Sven Barth  wrote:

Shouldn't it be "_RTL_DRIVE_LETTER_CURDIR" instead of
"RTL_DRIVE_LETTER_CURDIR"?


It doesn't matter if you just define a variable using this structure
like "RTL_DRIVE_LETTER_CURDIR MyVariable;".

It just matters if you somewhere declare it as "struct
RTL_DRIVE_LETTER_CURDIR MyVariable;".
If this isn't done anywhere, we could even create an anonymous structure
(Microsoft extension to the C language) by defining the structure as
"typedef struct {...} RTL_DRIVE_LETTER_CURDIR, *PRTL_DRIVE_LETTER_CURDIR;"

But as all headers out there seem to define it as "typedef struct
RTL_DRIVE_LETTER_CURDIR", we should do as well to ensure compatibility
with all applications using the structure :-)


It just caught my eye cause every other struct definition in the ReactOS 
headers (that I've seen so far) is named with a leading underscore...


But thank you for your explanation why this isn't a problem.

Regarding the anonymous structure: wouldn't this break compatibility 
with gcc? (I don't know what features gcc supports ^^)


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Question regarding declaration of RTL_DRIVE_LETTER_CURDIR in include\ndk\rtltypes.h

[Sven Barth]

Hello together!

I'm currently poking around in the NDK headers very much and I noted a 
small inconsistency in the declaration of one type.


The declaration is the following in include\ndk\rtltypes.h:

 source begin 

typedef struct RTL_DRIVE_LETTER_CURDIR
{
USHORT Flags;
USHORT Length;
ULONG TimeStamp;
UNICODE_STRING DosPath;
} RTL_DRIVE_LETTER_CURDIR, *PRTL_DRIVE_LETTER_CURDIR;

 source end 

Shouldn't it be "_RTL_DRIVE_LETTER_CURDIR" instead of 
"RTL_DRIVE_LETTER_CURDIR"?


I don't know what influences this missing underscore has on compilation 
and such, cause I can read C without big problems and write a bit as 
well, but I don't understand every single bit a C compiler does ^^


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Truncating ros-diffs subject lines

[Sven Barth]

On 07.08.2010 14:24, Colin Finck wrote:

Hi everybody,

Looking at
http://www.reactos.org/pipermail/ros-diffs/2010-August/038197.html and
the same message in Thunderbird, I now see a need to automatically
truncate all subject lines in ros-diffs' mails to 200 characters. I
don't think that anybody reads the full commit messages through subject
lines, so 200 characters should be enough to identify a commit easily.

If there are no objections, I'll try to change this in the next few days.

Cheers,

Colin


Oh... I didn't see that someone already raised that topic :D

I'd appreciate it, because I weren't able to view the message Timo wrote 
without clicking "reply" so that I could see the quoted message.


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [sir_richard] 48475: (huge bunch of text)

[Sven Barth]

Hi!

Just a little question regarding commit-mails: Does the subject NEED to 
be the complete svn log message? This mail's subject line was that long 
that I'm not able to view the message itself in Thunderbird without 
writing a reply so that I can see the quoted message body.


Couldn't the component/system/process that converts the commits into 
mails for the diffs mailing list truncate the subject line? As far as I 
see it the log message is put into the mail's body as well and it's also 
nicer to view there because of line breaks. :)


Regards,
Sven

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev