Friday, March 22, 2013

How to make GDrive synchronize faster?

You are in the  middle of your work and for some reason you need to restart the computer. It restarts fast BUT you cannot start your work (if you are working in team with others) because your Google Drive takes a good long fucking nice nap before it synchronizes all the files.
So you delete some of those 500MB files hoping that it will synchronize faster. But it won't!

I did some research and I have found out that the size of the files you have in drive doesn't matter too much. What matters is the number of files. So, 5000 files of 0.1MB will take way much longer to synchronize than a singe 500MB files even if the total amount of data (5000 * 0.1MB = 500MB) is the same.

So, start compressing the folders that contains LOTS of (small) files if you don't use them right now. If the compression takes too long you can set your compressor to 0 compression (this is called a 'tar ball' or 'compacting'). This will generate a single files, of the same size as the initial uncompressed data. So you don't gain something, space-wise, BUT ITS ONLY ONE, not 5000! And now we know that one big file synchronizes faster than 5000 tiny files!

1. Don't use the 'Compress contents to save disk space' feature located in the Properties windows that appears when you right-click a folder. It won't work.   
2. Don't be a lamer. Use RAR instead of ZIP. Arcive created with RAR are MUCH smaller (better) than the ones created with ZIP. And if you activate the 'Create solid archive' in WinRar the archive will be even smaller!

Enjoy your new GDrive speed. 
Don't forget to leave a comment...


Related posts: Google drive still unreliable

Friday, March 15, 2013

How to solve Windows system crashes

You just experienced a BSOD (Blue Screen Of Death) or other NDE (Near Death Experience)? This is the easy way to find out what is cause the BSOD.

Whenever Windows crashes it generates a Dump (*.dmp) file that contains the log of the crash. All you have to do is to analyze the log to see who is responsible for the crash. In most cases its a driver. To analyze the dump you need a program from Microsoft called WinDebug.
  1. Install WinDebug. It can be downloaded from Microsoft's web site. It's pretty big! 
  2. Install it in a folder like: "c:\Program Files\!system\WinDbg\Symbols" 
  3. Once installed run it and hurry to "File | Symbol File Path" menu and enter this string: SRV*c:\Program Files\!system\WinDbg\Symbols2\*
    and wait... It may take quite a while for the download to finish... up to 10 minutes. The program will look like it it doesn't download anything. But when the download will be ready you will
    finally see a message.
  4. Load the Dump file (menu 'File | Open crash dump'). You can manually search for the DMP file in Windows. However, I recommend you 'W7F Diagnostic Tool.exe' tool to locate/extract the DMP file.
  5. Enter this command to analyze the file: kd> !analyze -v 
    Note: you don't have to write kd>. It is already there.
    The log will say "Bugcheck Analysis" and the command prompt will say "Bussy". It may take a while, then the command prompt will return to 'kd>'.
  6. Analyze the log and find out who is at fault.

The log may look like this. I will highlight interesting parts:

A driver is causing an inconsistent power state.
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 86cc1b58, Physical Device Object of the stack
Arg3: 83172ae0, Functional Device Object of the stack
Arg4: 8957d8a0, The blocked IRP

Debugging Details:
IMAGE_NAME:  pci.sys
FAULTING_MODULE: 84313000 pci

83172a94 83112347 0000009f 00000003 86cc1b58 nt!KeBugCheckEx+0x1e
83172b00 831123c0 83172ba0 00000000 8317f380 nt!PopCheckIrpWatchdog+0x1f5
83172b38 830c4489 8318d6e0 00000000 a47bf74a nt!PopCheckForIdleness+0x73
83172b7c 830c442d 83175d20 83172ca8 00000001 nt!KiProcessTimerDpcTable+0x50
83172c68 830c42ea 83175d20 83172ca8 00000000 nt!KiProcessExpiredTimerList+0x101
83172cdc 830c247e 002c498f 898a6890 8317f380 nt!KiTimerExpiration+0x25c
83172d20 830c22a8 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb
83172d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38

FOLLOWUP_NAME:  MachineOwner
FAILURE_BUCKET_ID:  0x9F_3_rtl8192se_IMAGE_pci.sys
BUCKET_ID:  0x9F_3_rtl8192se_IMAGE_pci.sys

The last line is the MAGIC line that we are interested in. It shows that network's card driver is the one that causes the blue screen!

That a fucking Realtek driver for a Realtek 8192 network card. I updated the driver many times but it continues to be buggy. 

Solution: I will send the network card back and ask for a refund!

W7F Diagnostic Tool.exe

Thursday, March 14, 2013

Delphi XE advanced (text) property editor

Here is a 3rd party text property editor for Delphi XE/Delphi XE2/Delphi XE3 that is way much better than the default one. It can help you to edit text and TCaption fields.

  • It allows you to enter multi-line strings via the object inspector. Such strings can only be assigned at run-time.
  • Allows you to enter very long strings
It adds an ellipsis button to the right hand side of the data entry area in the object inspector that displays a dialog box in which the property's value can be entered. 
F2 or Ctrl+Enter causes the entered text to be assigned to the property.
There are shortcuts that allows you to
  • Select all the text in the editor.
  • Clear all the text from the editor.
  • Overwrite the editor's existing text with text from the clipboard.
  • Copy all the text from the editor to the clipboard.
  • Undo the last edit.

You can download it from here
Original author: Peter Johnson

Related article: How difficult is to write a solid software protection (licensing) scheme?


Wednesday, March 13, 2013

How to prevent Delphi from generating bpl, identcache and local files

Delphi generates a series of annoying and useless files such as *.bpl, *.identcache and *.local. They are totally useless and safe to delete.

Few people know that Delphi Distiller is capable to disable the generation of these files. This is because the panel from where you do this is hidden under an obscure menu called 'Extras'. Just download Delphi Distiller and see for yourself. 

Piece of cake. Right?

Yest another useful features is 'Don't load .Net crap'.

Tuesday, March 12, 2013

The ultimate guide to rechargeable batteries

So, you want to buy some rechargeable batteries and you don't know which is the best? 
Here is a list of rechargeable batteries you can  find on sorted .....drum roll please..... by Euro per Amper.

For day by day use I recommend you batteries of at least 3000mAh. Therefore, batteries show in gray are of low power (below 4000mAh) so I will totally ignore them.

In the end I choose Ansman because it seems to be a German company. 

(Here is the link to the table: batteries)

The table contains only C and D size rechargeable batteries. 
I provided you also with the link to the Amazon page so you can check each item. 

Also you may want to see this article about Battery chargers

Energizer Universal Charger

Today I got an Energizer Universal Charger. Simply it sucks. I though Energizer is a big/good company. Wrong! 
This design of this device is simply shitty. Why? Because I can only charge 2 or 4 batteries at once. If I want to change 3 batteries (and this is what I want to do) I can't.

I have a set of 4 batteries and a toy that uses only 3 batteries. Every time the batteries are depleted and I want to recharge them I have to recharge (or more accurately to OVERCHARGE) and the unused battery.

Also I have notice that in the box there is basically no manual.

If you only want to charge batteries in pairs of 2, this device is ok. If you are in need of flexible/professional battery recharger, go look for something else.

Monday, March 11, 2013

More nasty bugs related to Delphi packages

The problem
My Delphi XE started to act strange lately. I have unit Unit2.pas that uses 'FormatBytes' declared in Unit1.pas. When I try to compile Unit2 Delphi says that it cannot find FormatBytes. But FormatBytes is there, in Unit1 !!

Unit1 belongs to Package1 and Unit2 to Package2 (Package2 depends on Package1).

Even more strange: if I delete Unit1 (pas and dcu) Delphi doesn't complain that it cannot find the unit! Its like Unit1 has been cached somewhere. However, if I try to open Unit1, obviously it cannot be found and Delphi popups a OpenDialog to let me show there Unit1 is located.

I know there is already a bug in the caching system for VCL. I guess this is a similar bug.


Solution: I deleted all files related to all my packages:
  • DCP
  • BPL
  • DCU
  • DSK
  • paths from 'Library'
Then I rebuilt everything. Now everything compiles smoothly without warnings and errors. 
(Note: Initially I tried deleting files specified above except  Dproj and paths and it didn't worked)