Windows 7 overwrites Haiku partitions!

As my Christmas holiday were really long, I decided to use the occasion to reorganize all my hardware, with the new pieces I got during the last months. I started by putting all together moving RAM here and there, HD's and so on.

Once the candidate final machine was set, it was the time to start installing operating systems.

The first idea was to replace my Haiku development machine with this new one, but this, was to have had 60GB(20+40) so, it was enough space to have all of them: Haiku, Linux, and if all was ok, try a Windows 7. I would not expect that guys from Redmond were going to punish me so much for setting Windows the last in the queue.

So I started with Linux, to get the grub ready, and create within Linux all the partition. Then I went with 2 installations of Haiku: First one, the Alpha release and the second one with a fresh build.

All fine, all so nice with my new desktop, resynced all SVNs did some commits.

Then there was the 40GB HD reserved ONLY for the gigantic OS (even the HD was set as first HD in the IDE bus). After installation I was still happy as Win7 was more or less running smoothly in a moderate machine (Athlon Thunderbird 1,2GHz 768RAM).

All problems came or better said, they showed up trying to set Grub to boot Windows7.

Although I was sure I was pointing to the same partition I keep getting a message "BOOTMGR Missing".

Browsing and browsing I arrived to a really concerning post in the Ubuntu forums:

Quoting Belboz99:

"Just now I realized that Win7 creates at least 2 partitions when you install it, even though you may have only one selected and formatted for it's use."

Ok I thought, no way, I already checked the table and there is no new partition on that disk(40GB windows dedicated one with spare unpartitioned space), Also is impossible to fit another partition on the other disk as it is full with Linux and Haiku.

Checking 2 posts below I can quote from ramzai:

"And what is even worse, Win7 may put its bootloader to other existing FAT or NTFS partitions, even on the other hd, as it was in my case. I installed Win7 to (hd1,2) and then found bootmgr file on the (hd0,2) partition with music and video files."

Oh oh... then I started reviewing carefully all partitions... and there you are, a BFS one, suddenly became a NTFS...

WIN7 installation just went over my disk, even having free unpartitioned space on the same disk it was getting installed it went to the other disk, Found a partition of an unrelevant type (BFS, the first Haiku one), set it to NTFS, FORMATTED IT, and wrote there a bootloader. Win7 just overwrote my Haiku development partition, for just placing its bootloader!!

yeah Microsoft, while fixing all the mess and reinstalling, no opensource was written, you achieved it. I am just really thankful that you did not choose to crash my critical haiku data partition, or the sources one.

Bluetooth Status

There have not been any huge steps forward in the current status of the bluetooth stack, but many small ones which give a bit more visual, and development comfortability:

Little icons for devices list: Jörg Meyer, drew an identifiable icon according to the device class instead of the former empty black square.

Debug information: The bluetooth console opened by the server has improved its debug information, being more clean and formatted.

Close and start server, maybe one of the oldest and most annoying bugs the stack had. The USB pipes of the h2generic driver were not correctly cleaned, therefore at closing the device driver(Quitting the server) compiling the server or the kit and trying to start again the server, to test the changes, the stack was blocked due the usb pipes. The only way to test again was to restart the whole system. Consequences, now you can start the server and quit the server, plug and unplug your dongles. In a user side these are not common operations, but the development is going to be a bit more comfortable.

SetDeviceClass: This is a new method added to the bluetooth kit although it is not in the JSR-82 standard. Once the device class is set, and any remote discovers the Haiku node, it will concretely know if this is a phone, a printer, a GPS, or as we will set by default, a computer. This was an option in preferences, but until now it had no effect.

Here we can see how 2 dongles(BCM2035 and CSR bc-4) in the Haiku node have been discovered by Windows7 as different Device class(handheld, and Laptop).

Deskbar applet: Finally! Michael Weirauch took a day and sent me this patch which adds a deskbar addon, where we will place the most common actions. Currently the ones placed just help the development.

Status, something sleeping in HD

I remember when I was coding the Relauncher_deamon I isolated the component showing the feedback, and placed it in separated application, that must have happened around 2003!
The intention to isolate it, was to show information about the startup process, I placed it in an own LiveCD based on R5. I think it can be useful for scripts.

So after some talks in the Spanish mail-list, I have got the motivation to get that harddisk and recompile the application:

Can be downloaded here or in its bebits page

Important change

In the last week, due a more advanced implementation on how HCI commands are created, I checked the possibility to start using the size value given by the ioctl's(control hook on drivers). On R5 the value was always 0, therefore I was forced to pass in the first 4 bytes of the buffer, its size.

This ioctl's feature works as expected in Haiku, therefore as this new mechanism for bluetooth commands assumes this fact, the R5 behavior, although present in code has been dropped in r29639. Check inclusion for define BT_IOCTLS_PASS_SIZE.

With the new mechanism memory leaks allocating commands are solved, as they are meant to be allocated in stack, and dropping this R5 legacy, we are using 4 less bytes of memory per command (considerable as many bluetooth commands are just 3 bytes).

Bla bla bla, sumarizing the important part:

*** After this revision, be sure you recompiled and are using an updated version of at least: h2generic, bluetooth kit and bluetooth_server. As this change solved many issues but broke many compatibilities ***

For the ones who test often, there are some strings more on the LocalDevice panel information (preferences), there you will be able to check your dongle's bluetooth version, and the company who maufactured.

I use this update to thank Edwin Erik Amsler, who has shipped me some bluetooth devices to test, and a bluetooth 1.2 dongle which was recognized by the stack:



the phone discovered:

The Inquiry Panel

Maybe this is the most visual thing the bluetooth stack can show.

I have 2 bluetooth dongles connected: "CSR - bc4" and "Broadcom BCM2035". The further tests are gonna be pair the one with the other despite they are plugged in the same host. But by this way the input and the output are tested at the same time, as they don't know about each other and there is no such thing as loopback device in bluetooth context.

In the video can be seen how i set to discoverable the CSR one, and leave selected the Broadcom one. This will be used for the inquiry process. After the scanning and the retrieval of names, a phone and the CSR device are listed, and can be added to the Remote Device list.



Again UI suggestions/mockups are Welcome

Whisper BeNet running in Haiku

I have taken some time to comment about this parallel subject. Actually, I needed to check the commit date to know when that happened.

At the end I committed the initial sources of Whisper BeNet. Used Niue as build system for ZETA, and Paladin, for build system for Haiku.

Later on at the end of last December as per revision 13 the code is now running in Haiku. What I can see is that the network part might be working quite well, as it was possible to set a silence conference as can be seen in the screenshot. But the sound recording will be pending...

Some other evolution

This is the current state after some feedback. The information about the Local Device is not taking so much protagonism now, and the first tab the user can see is the list of the current remote devices(not implemented).

The intention is that the settings tab should not be needed for an average user, and the identified needed functions of this tab would be accessible also through a Deskbar applet...

Preference & next steps

In the next months all work is being focused in the codebase of the Phase1(ARCE) of the project. Three main things, fix bugs, clean, and implement features and tools which will make starting the Phase2 with a more comfortable Bluetooth base.

One of the most annoying things is that the bluetooth_server is not recognizing the hotplugged dongles on the system, they must be plugged before starting the server. So basically the management of the device(s) plugged in the Haiku system must be improved.

The second big one is the lack of tools, there are 2,  one informational, and another for discovering, but we cannot yet(in svn) take any action. The actions needed by the tests were taken by the remote device(phone).

In a document I was dropping during these months my UI Wishlist

There is a mockup of the future InquiryPanel which I would like to receive some feedback too, but the intention of the post is to show the current Preference application:

3 tabs, rightmost is pretended for global settings. The middle one, pretends to be a list of all known remote device: reacheable, paired, blocked, connected. And a description of what we know about it or services offered if available.

And the target of the post would be the tab which can be seen in the screenshot. Is the description of the LocalDevice, and the most basic action make it enter the game(discoverable). The good thing of those 2 checkboxes is that they are actually working. The black box is intended to show a laptop or Desktop machine(who know.. a smartphone?) icon depending how are you willing to identify yourself.

The panel is very basic so I thought there are many artists around that might want to give me some ideas with mockups or comments. I would be glad reading them before going on with the code.

BTW: The dongle identified in the screenshot is one donated by Pieter Panman one finally containing a valid bdaddr, thanks!